home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / ibmpc / 6172 < prev    next >
Encoding:
Text File  |  1992-11-09  |  3.3 KB  |  73 lines
  1. Newsgroups: comp.protocols.tcp-ip.ibmpc
  2. Path: sparky!uunet!utcsri!torn!watserv2.uwaterloo.ca!watserv1!demorgan.uwaterloo.ca!erick
  3. From: erick@demorgan.uwaterloo.ca (Erick Engelke)
  4. Subject: Re: Fragmented IP packets: any PD implementations?
  5. Message-ID: <BxGtps.BHM@watserv1.uwaterloo.ca>
  6. Keywords: IP fragments TCP/IP
  7. Sender: news@watserv1.uwaterloo.ca
  8. Organization: University of Waterloo
  9. References: <1992Nov8.203621.6902@mnemosyne.cs.du.edu>
  10. Date: Mon, 9 Nov 1992 20:17:51 GMT
  11. Lines: 60
  12.  
  13. > dpayne@nyx.cs.du.edu (Dirk Payne) writes:
  14. >I have reviewed WATTCP, PCIP, and both CUTCP and NCSA's versions of telnet
  15. >but none of these implemetations handle IP fragments. In order to be a "real"
  16. >TCP/IP package (connected to the "real" world) fragments cannot be ejected
  17. >out of hand.
  18.  
  19. The question I have is why you are needing frags.  There are only a 
  20. few situations which should generate fragments in a user's PC, large 
  21. UDP packets and incorrectly configured TCP systems.  (Frags in 
  22. gateways are quite a different story.)
  23.  
  24. First, let's dispell the TCP case.  Your user's PCs are located on
  25. an Ethernet, Arcnet, TR, slip line, or whatever.  Setting the correct
  26. tcp segment size for your hardware will guarentee that you and your
  27. TCP peers will never attempt to send a packet larger than that segment
  28. size and so there will be no fragments.  And systems like WATTCP 
  29. and CUTCP use Van Jacobson's adaptive window, so they will offer
  30. fast bulky TCP transfers without requiring frags.
  31.  
  32. A common misconception is that we will get fragmented packets from
  33. outside our LAN, such as gateways through slower media.  But it is
  34. the gateway's responsibility to reassemble the frags before putting
  35. the data onto the LAN at the other end.  That's why people using
  36. all these freeware TCPs didn't know they didn't have frag support.
  37.  
  38. Some TCPs, like FTP's PC/TCP, actually determine the largest segment
  39. size which will not fragment along the path.  It's coverred in
  40. the RFC's and quite a clever idea worth reading.
  41.  
  42. The remaining use of fragments is for UDP based services such as
  43. NFS/RPC/UDP or possibly SNMP.  I have always been critical of the
  44. use of fragmented RPC's and wished people would migrate over to TCP
  45. as they are starting to do now for NFS. 
  46.  
  47. Here's my frustration, fragments rely on 100% delivery and are 
  48. costly in gateways.  And when you encounter problems on your LAN,
  49. large UDP packets clog it in a needless and futile manner whereas 
  50. TCP adapts.
  51.  
  52. I might be convinced to add frag support, but would appreciate 
  53. opinion if it is a good idea, in particular, which applications
  54. could use it.  NFS is not a great answer since it would be useful
  55. even with 1K packet sizes, the problem there is the lack of an
  56. implementation.  I know the Host Requirements RFC tells us what
  57. to do, but I would prefer to see an application which needs it.
  58.  
  59.  
  60. >Has anyone implemented IP fragment handling in any of the above mentioned
  61. >products? My personal favorite is WATTCP, but I would be willing to entertain
  62. >any PD implementation that handles frags. My only alternative is to roll my
  63. >own :-(.
  64.  
  65. Like I said, gateways are a different matter. Phil Karn's NOS does 
  66. frags/reassembly, but it isn't PD.
  67.  
  68. Erick
  69. -- 
  70. ----------------------------------------------------------------------------
  71. Erick Engelke                                 WATTCP Architect
  72. erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI
  73.