home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / ibmpc / 6177 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.9 KB  |  60 lines
  1. Newsgroups: comp.protocols.tcp-ip.ibmpc
  2. Path: sparky!uunet!ukma!darwin.sura.net!sgiblab!newsun!donp
  3. From: donp@novell.com (don provan)
  4. Subject: Re: Fragmented IP packets: any PD implementations?
  5. Message-ID: <1992Nov9.230848.7810@novell.com>
  6. Keywords: IP fragments TCP/IP
  7. Sender: news@novell.com (The Netnews Manager)
  8. Nntp-Posting-Host: na.sjf.novell.com
  9. Organization: Novell, Inc., San Jose, California
  10. References: <1992Nov8.203621.6902@mnemosyne.cs.du.edu> <BxGtps.BHM@watserv1.uwaterloo.ca>
  11. Date: Mon, 9 Nov 1992 23:08:48 GMT
  12. Lines: 46
  13.  
  14. In article <BxGtps.BHM@watserv1.uwaterloo.ca> erick@demorgan.uwaterloo.ca (Erick Engelke) writes:
  15. >A common misconception is that we will get fragmented packets from
  16. >outside our LAN, such as gateways through slower media.  But it is
  17. >the gateway's responsibility to reassemble the frags before putting
  18. >the data onto the LAN at the other end.
  19.  
  20. I don't know where you picked this up, but it's wrong.  In fact, routers
  21. are *forbidden* from doing IP reassembly for packets they are forwarding.
  22. Just as well, since reassembly at an intermediate node can be quite
  23. expensive, even compared to reassembly at the destination.
  24.  
  25. >That's why people using
  26. >all these freeware TCPs didn't know they didn't have frag support.
  27.  
  28. No, i think your other point -- that freeware TCP applications don't
  29. generate fragments -- is a better explanation of why this deficiency
  30. is overlooked.
  31.  
  32. >Here's my frustration, fragments rely on 100% delivery and are 
  33. >costly in gateways.  And when you encounter problems on your LAN,
  34. >large UDP packets clog it in a needless and futile manner whereas 
  35. >TCP adapts.
  36.  
  37. While these are fine arguments, they only argue against *applications*
  38. which depend fragmentation, and in that context i support your
  39. position entirely.  Unfortunately, the question here is whether any
  40. given *IP implementation* should support fragmentation and reassembly.
  41. If it doesn't, it can't support applications, environments, or peer
  42. implementations which, for whatever reasons, require that facility.
  43.  
  44. >I might be convinced to add frag support, but would appreciate 
  45. >opinion if it is a good idea, in particular, which applications
  46. >could use it.  NFS is not a great answer since it would be useful
  47. >even with 1K packet sizes, the problem there is the lack of an
  48. >implementation.  I know the Host Requirements RFC tells us what
  49. >to do, but I would prefer to see an application which needs it.
  50.  
  51. Although i understand how strapped for space you are in a PC, i don't
  52. really see that implementing fragmentation and reassembly is that much
  53. of a burden.  In the commercial IP world, the overhead in both space
  54. and development effort is insignificant when compared to the effort of
  55. marketing an incomplete IP implementation and then supporting it when
  56. something that should work doesn't.  Free IP implementations have a
  57. little more flexibility in this regard.
  58.                         don provan
  59.                         donp@novell.com
  60.