home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / ibmpc / 6261 < prev    next >
Encoding:
Text File  |  1992-11-12  |  6.4 KB  |  134 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: <BxM5tu.Jws@watserv1.uwaterloo.ca>
  6. Keywords: IP fragments TCP/IP
  7. Sender: news@watserv1.uwaterloo.ca
  8. Organization: University of Waterloo
  9. Date: Thu, 12 Nov 1992 17:27:28 GMT
  10. Lines: 122
  11.  
  12. In response to Don Provan (donp@novell.com):
  13.  
  14. Don, thanks for your input and comments based on your wealth of experience.
  15. I am replying through the newsgroup because there appears to be sufficient
  16. interest concerning this topic and because most of the replies I got from
  17. knowledgeable people were also based on misconceptions much like my own.
  18. The numerous references are for readers who wish to get more details.
  19.  
  20. First, some background.  As you may have known, I initially wrote much of
  21. my TCP without a real network around, just my PC, Karn's NOS as it's peer,
  22. and a scatterred collection of RFCs on the living room floor.  There is no
  23. big compatibility lab, no collection of hardware for inhouse testing, nothing
  24. much at all.  The mere fact that my code interoperates is a credit to the
  25. RFCs, the simple design of the protocols, and attempted adherance to the
  26. Internet golden rule by all involved parties.
  27.  
  28. So thanks for not slamming the limitations inherent in a one man project.  For
  29. anyone who has not taken on such an enormous programming task single-handedly,
  30. let me point out that there is no one local with whom I can argue out design
  31. criteria - and that means an increased chance of flaws making it past the
  32. design stage.  For these reasons, I insist on having co-workers for my
  33. professional projects!
  34.  
  35. Back to WATTCP specifics, there were some initial limitations in the
  36. design which still exist today, sometimes unnoticed and they are not
  37. fixed because they have not caused any problems.  It appears that the
  38. fragment issue fit into this category until this week.
  39.  
  40. Reassembly was originally omitted because I didn't know how to
  41. create a situation that would generate them so I could test the code!
  42. Now I am a little wiser, particularly since the night of Don's post when
  43. I gave myself a crash course on the subject to avoid making a second
  44. blooper post in a row.
  45.  
  46. For those interested, a good way to easily and reliably receive a fragment
  47. for testing your code is to send a MTU sized ICMP echo request, the reply
  48. will have to be fragmented if it bounces off of a properly implemented system.
  49. Once you know your reassembly code works, you can use the UDP ECHO protocol
  50. to test generating and receiving larger than MTU sized datagrams.
  51.  
  52. >In the commercial IP world, the overhead in both space
  53. >and development effort is insignificant when compared to the effort of
  54. >marketing an incomplete IP implementation and then supporting it when
  55. >something that should work doesn't.  Free IP implementations have a
  56. >little more flexibility in this regard.
  57.  
  58. Yes, a frag-less IP fails to meet the Host Requirements MUST clause in
  59. RFC 1122 3.2.1.4, this is bad for any implementation and would be very
  60. unacceptable for a commercial implementation - that's not to say they
  61. have all supported reassembly all along...
  62.  
  63. >Although i understand how strapped for space you are in a PC, i don't
  64. >really see that implementing fragmentation and reassembly is that much
  65. >of a burden.
  66.  
  67. Yes space was a concern.  For example, in KERMIT Joe and I achieved
  68. TCP/IP+DNS+TELNET in a very respectable 30 K.  Right from the beginning,
  69. I wanted to use my same kernel code for both server functionality
  70. (eg. my multi-session SMTPSERV program) and TSR functionality (eg. my
  71. freeware TELNETD).
  72.  
  73. Later I added programmer installable options, such as large buffer
  74. queue support for UDP based servers and a setvbuf() function for TCP
  75. which lets one use window sizes of up to 32K.
  76.  
  77. I will be adding reassembly fragment support.  Reassembly of TCP packets
  78. won't require any additional space except for a few lines of code since
  79. they will never exceed WATTCP's MSS.  But supporting larger than MSS-size
  80. packets will be difficult.  Perhaps large packet support will be added as
  81. a programmer installable option too.
  82.  
  83. A very common oversight from practically everyone who answerred was the
  84. assumption that using 576 byte packets is the answer.
  85.  
  86. A 576 byte packet is not necessarily atomic.  A good description is
  87. found in RFC 879.  And obviously, you (Don Provan) know 576 is not always
  88. atomic.  (Anyone who wonders why might like to read the first couple
  89. of paragraphs of Don's first RFC, RFC1201 and consider what it solves as
  90. compared to the earlier RFC on the subject.)
  91.  
  92. >>... it is the gateway's responsibility to reassemble the frags before putting
  93. >>the data onto the LAN at the other end.
  94. >
  95. >I don't know where you picked this up, but it's wrong.  In fact, routers
  96. >are *forbidden* from doing IP reassembly for packets they are forwarding.
  97.  
  98.  
  99. Sorry, I got it confused with a proprietary protocol from a few years ago.
  100. I believe that the RFCs recommend against router reassembly, however it is
  101. never listed as verboten, just impractical.  The only statement I can find
  102. is in RFC 1009:
  103.  
  104.     The Internet model requires that a gateway be able to fragment
  105.     datagrams...          ...but reassembly of fragmented datagrams
  106.     is generally left to the destination hosts.  Therefore a gateway
  107.     will not perform reassembly on datagrams it forwards.
  108.  
  109. Several people have commented that they have some routers which do re-assembly,
  110. I don't have any proof either way.  But I caution people to not assume the
  111. router does re-assembly just because you think a few simple tests pass.  My
  112. next paragraph explains why...
  113.  
  114. >>That's why people using
  115. >>all these freeware TCPs didn't know they didn't have frag support.
  116. >
  117. >No, i think your other point -- that freeware TCP applications don't
  118. >generate fragments -- is a better explanation of why this deficiency
  119. >is overlooked.
  120.  
  121. In retrospect, I think it is the golden rule which fools us.  Most PC
  122. freeware is used to call into larger systems, and those larger systems
  123. either use the 576 byte MSS or the RFC 1101 Path MTU discovery to reply.
  124. So they may receive gateway-fragmented packets from freeware, but tend
  125. to reply with reasonably small packets that the freeware can accept.  
  126.  
  127. Again, thanks for the enlightenment.
  128.  
  129. Erick
  130. -- 
  131. ----------------------------------------------------------------------------
  132. Erick Engelke                                 WATTCP Architect
  133. erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI
  134.