From: erick@demorgan.uwaterloo.ca (Erick Engelke)
Subject: Re: Fragmented IP packets: any PD implementations?
Keywords: IP fragments TCP/IP
Organization: University of Waterloo
Date: Thu, 12 Nov 1992 17:27:28 GMT

In response to Don Provan (donp@novell.com):

Don, thanks for your input and comments based on your wealth of experience.
I am replying through the newsgroup because there appears to be sufficient
interest concerning this topic and because most of the replies I got from
knowledgeable people were also based on misconceptions much like my own.
The numerous references are for readers who wish to get more details.

First, some background.  As you may have known, I initially wrote much of
my TCP without a real network around, just my PC, Karn's NOS as it's peer,
and a scatterred collection of RFCs on the living room floor.  There is no
big compatibility lab, no collection of hardware for inhouse testing, nothing
much at all.  The mere fact that my code interoperates is a credit to the
RFCs, the simple design of the protocols, and attempted adherance to the
Internet golden rule by all involved parties.

So thanks for not slamming the limitations inherent in a one man project.  For
anyone who has not taken on such an enormous programming task single-handedly,
let me point out that there is no one local with whom I can argue out design
criteria - and that means an increased chance of flaws making it past the
design stage.  For these reasons, I insist on having co-workers for my
professional projects!

Back to WATTCP specifics, there were some initial limitations in the
design which still exist today, sometimes unnoticed and they are not
fixed because they have not caused any problems.  It appears that the
fragment issue fit into this category until this week.

Reassembly was originally omitted because I didn't know how to
create a situation that would generate them so I could test the code!
Now I am a little wiser, particularly since the night of Don's post when
I gave myself a crash course on the subject to avoid making a second
blooper post in a row.

For those interested, a good way to easily and reliably receive a fragment
for testing your code is to send a MTU sized ICMP echo request, the reply
will have to be fragmented if it bounces off of a properly implemented system.
Once you know your reassembly code works, you can use the UDP ECHO protocol
to test generating and receiving larger than MTU sized datagrams.

>In the commercial IP world, the overhead in both space
>and development effort is insignificant when compared to the effort of
>marketing an incomplete IP implementation and then supporting it when
>something that should work doesn't.  Free IP implementations have a
>little more flexibility in this regard.

Yes, a frag-less IP fails to meet the Host Requirements MUST clause in
RFC 1122 3.2.1.4, this is bad for any implementation and would be very
unacceptable for a commercial implementation - that's not to say they
have all supported reassembly all along...

>Although i understand how strapped for space you are in a PC, i don't
>really see that implementing fragmentation and reassembly is that much
>of a burden.

Yes space was a concern.  For example, in KERMIT Joe and I achieved
TCP/IP+DNS+TELNET in a very respectable 30 K.  Right from the beginning,
I wanted to use my same kernel code for both server functionality
(eg. my multi-session SMTPSERV program) and TSR functionality (eg. my
freeware TELNETD).

Later I added programmer installable options, such as large buffer
queue support for UDP based servers and a setvbuf() function for TCP
which lets one use window sizes of up to 32K.

I will be adding reassembly fragment support.  Reassembly of TCP packets
won't require any additional space except for a few lines of code since
they will never exceed WATTCP's MSS.  But supporting larger than MSS-size
packets will be difficult.  Perhaps large packet support will be added as
a programmer installable option too.

A very common oversight from practically everyone who answerred was the
assumption that using 576 byte packets is the answer.

A 576 byte packet is not necessarily atomic.  A good description is
found in RFC 879.  And obviously, you (Don Provan) know 576 is not always
atomic.  (Anyone who wonders why might like to read the first couple
of paragraphs of Don's first RFC, RFC1201 and consider what it solves as
compared to the earlier RFC on the subject.)

>>... it is the gateway's responsibility to reassemble the frags before putting
>>the data onto the LAN at the other end.
>
>I don't know where you picked this up, but it's wrong.  In fact, routers
>are *forbidden* from doing IP reassembly for packets they are forwarding.


Sorry, I got it confused with a proprietary protocol from a few years ago.
I believe that the RFCs recommend against router reassembly, however it is
never listed as verboten, just impractical.  The only statement I can find
is in RFC 1009:

    The Internet model requires that a gateway be able to fragment
    datagrams...          ...but reassembly of fragmented datagrams
    is generally left to the destination hosts.  Therefore a gateway
    will not perform reassembly on datagrams it forwards.

Several people have commented that they have some routers which do re-assembly,
I don't have any proof either way.  But I caution people to not assume the
router does re-assembly just because you think a few simple tests pass.  My
next paragraph explains why...

>>That's why people using
>>all these freeware TCPs didn't know they didn't have frag support.
>
>No, i think your other point -- that freeware TCP applications don't
>generate fragments -- is a better explanation of why this deficiency
>is overlooked.

In retrospect, I think it is the golden rule which fools us.  Most PC
freeware is used to call into larger systems, and those larger systems
either use the 576 byte MSS or the RFC 1101 Path MTU discovery to reply.
So they may receive gateway-fragmented packets from freeware, but tend
to reply with reasonably small packets that the freeware can accept.  

Again, thanks for the enlightenment.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI
Newsgroups: comp.protocols.tcp-ip.ibmpc