tcp-ip@ucbvax.ARPA (06/05/85)
From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA> What will it take to define some protocol for establishing reasonable segment lengths? Comments that appear every month or so seem to cry out for some IP/ICMP do-dah by which two hosts can get a good guess of the fragmentation situation in between each other. For a start, any TCP/IP where TCP can't ask for the hardware MTU of the most likely routing to a given address should be taken out and shot. After that, perhaps some sort of IP option could be added to which any gateway involved would add its hardware MTU. An exchange of these at the beginning of a connection would improve the picture no end.
tcp-ip@ucbvax.ARPA (06/05/85)
From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> A solution that I used in the later BBN 4.1 TCP/IP implementation was for the IP layer to pass to TCP the size of the largest fragment which went to make up the current IP packet. TCP then unilaterally restricted its segment size to twice the fragment size (less an appropriate fudge factor). This produces no tinygrams, although interfaces that can't handle back-to-back packets are still in trouble. Yes, it's a hack that violates level separation rules, but it made a big difference in practice. A useful facility that the SATNET folks have been good enough to provide are the IP echo hosts on the far side of satellite connections (goonhilly-echo for example). These switch the IP source and destination addresses and ship the packet out again. Since SATNET has the smallest MTU, the longest delay, and a penchant for dropping packets (this is not SATNET's fault; the speed mismatch between the ARPAnet and SATNET is ferocious and the gateway clogs), it's handy for testing TCP/IP implementations. It has been known to crash insufficiently bulletproofed software. Dennis Rockwell CSNET Technical Staff