Kevin_Crowston@XV.MIT.EDU (12/02/87)
I seem to be having a problem with TCP fragments. I'm running Koto on an 1108. The date on the TCP file is 18-Dec-86 17:39:57; it's the same as the one currently on {SUMEX-AIM.Stanford.EDU}<LISPUSERS>KOTO>.
A host is sending me large packets that are getting broken up along the way across the internet. When I get them there are two fragments (identified by the MIT PC/IP netwatch program as TCP Fragments), one of 1004 bytes and one of 516 bytes. This makes me think that the originating host is sitting on an ethernet pumping out 1.5K packets. I'm not sure what exactly happens, but the Dandelion doesn't seem to be able to reassemble the packets and after getting a few repeats it sends back some TTL Exceeded I
CMP packets, first one to a bogus host (with an address like 111.113.22.22) and then two to the originating host. After this, I think the connection dies. (I'm a little vague on the details since I'm not using the Dandelion, only watching the packets go by on the network and seeing the final result of the connection, which is a mail message with no contents.)
Anyway, is this a known bug? I suspect the originator shouldn't really be sending such large packets, but I also suspect the dandelion should be doing a better job of catching them. Is there a fix?
Kevin Crowston
MIT Sloan School of ManagementSCHMIDT@SUMEX-AIM.STANFORD.EDU (Christopher Schmidt) (12/03/87)
A host is sending me large packets that are getting broken up along
the way across the internet. When I get them there are two fragments
[...], one of 1004 bytes and one of 516 bytes. This makes me think
that the originating host is sitting on an ethernet pumping out 1.5K
packets. I'm not sure what exactly happens, but the Dandelion doesn't
seem to be able to reassemble the packets [...]
Anyway, is this a known bug? I suspect the originator shouldn't really
be sending such large packets, but I also suspect the dandelion should
be doing a better job of catching them. Is there a fix?
The problem is not one of fragmentation, but of packet size.
The ethernet software on the d-machine limits datagrams to 576 bytes
[coincidentally the maximum length of an NS datagram], which is all the IP
spec requires. Moreover, 576 bytes is the longest datagram that correspondents
may send you in the absence of "assurance that the destination is prepared to
accept the larger datagrams" (RFC791, page 13). Your correspondent is in
error and should be fixed not to send such large packets by default.
Also: RFC793 defines the "maximum segment size" option for TCP that limits
the size of TCP datagrams. Xerox TCP sends this option, but in the second
packet of the connection rather than the first. This is a failure to meet
one of the conditions of using this option imposed at the top of page 19.
Maybe if you fixed the Xerox code to send this option in the proper packet,
you could get shorter packets out of the problem host. Maybe Xerox will fix
this and/or issue a patch?
--Christopher
-------