home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / ibmpc / 6242 < prev    next >
Encoding:
Text File  |  1992-11-11  |  2.6 KB  |  61 lines
  1. Newsgroups: comp.protocols.tcp-ip.ibmpc
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!swrinde!news.dell.com!natinst.com!cs.utexas.edu!sun-barr!ames!eos!ssmith
  3. From: ssmith@eos.arc.nasa.gov (Stephen Smith)
  4. Subject: Re: Fragmented IP packets: any PD implementations?
  5. Message-ID: <1992Nov11.215152.20095@eos.arc.nasa.gov>
  6. Keywords: IP fragments TCP/IP
  7. Organization: NASA Ames Research Center
  8. References: <1992Nov8.203621.6902@mnemosyne.cs.du.edu> <BxGtps.BHM@watserv1.uwaterloo.ca>
  9. Distribution: usa
  10. Date: Wed, 11 Nov 1992 21:51:52 GMT
  11. Lines: 48
  12.  
  13. erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
  14.  
  15. >> dpayne@nyx.cs.du.edu (Dirk Payne) writes:
  16. >>I have reviewed WATTCP, PCIP, and both CUTCP and NCSA's versions of telnet
  17. >>but none of these implemetations handle IP fragments. In order to be a "real"
  18. >>TCP/IP package (connected to the "real" world) fragments cannot be ejected
  19. >>out of hand.
  20.  
  21. >The question I have is why you are needing frags.  There are only a 
  22. >few situations which should generate fragments in a user's PC, large 
  23. >UDP packets and incorrectly configured TCP systems. 
  24. The "few situations" may be important to the user(s), despite what I
  25. think. Nor is it fair to assume any system which generates them is 
  26. "incorrectly configured" or uses large UDP packets (e.g., slip over a 
  27. noisy line).
  28.  
  29. I don't think "needing frags" is the point, its a matter of
  30. co-existence w/ systems with frags-- regardless of how they are
  31. generated. 
  32.  
  33. [... dispell stuff deleted]
  34.  
  35. >I might be convinced to add frag support, but would appreciate 
  36. >opinion if it is a good idea, in particular, which applications
  37. >could use it.  NFS is not a great answer since it would be useful
  38. How about ftp, nntp, smtp, telnet --- i.e. all the WKS. The apps will
  39. follow once the foundation is built. Several of these exist in NOS.
  40. >even with 1K packet sizes, the problem there is the lack of an
  41. >implementation.  I know the Host Requirements RFC tells us what
  42. >to do, but I would prefer to see an application which needs it.
  43.  
  44. From my end, the problem is various PC tcp/ip implementations that
  45. don't supporting fragment reassembly trying to co-exist with systems
  46. that do support reassembly. No one person has control over every
  47. system, and tcp/ip is the primary protocol stack and pre-dates PC's
  48. altogether. 
  49.  
  50. My only question are commercial apps and Phil Karn's NOS to be the only
  51. answer?  Given the clammoring for SLIP, the answer is getting more
  52. important every day.
  53.  
  54.  
  55. -Steve
  56. -- 
  57. ==================================================================
  58. Stephen Smith                         MS 262-6
  59. (415) 604-1381                        NASA Ames Research Center
  60. ssmith@eos.arc.nasa.gov               Moffett Field, Ca. 94035
  61.