jas@MONK.PROTEON.COM (John A. Shriver) (05/26/87)
The reason to send packets larger than 576 bytes is simple. If you don't have congestion on the media, doubling packet size almost doubles end-to-end performance. This particularly helps in groups of LANs. (While the ARPANET can handle larger packets, I'm not sure that the PSN software gives you more speed for them.) Both TCP implementations and routers like to see packets stay large. I like the concept of using the Don't Fragment bit. The ICMP message will give us the IP header of the offending packet, so we can identify the TCP connection and the offending IP length. Moreover, the ICMP message lands at the originator. It even copes with asymetric paths. Rather than keep timers down at the data link level, it might be easier to just send a TCP segment with the full MSS offered by the other end every minute (with Don't Fragment), and see if it gets through in one piece. My comment on ARPANET brings up an interesting point. It may not always be the case that larger IP packets are faster. You may have some VC link that suffers resource starvation when you do this. Or you might have a problem like SATNET, where one reason for small packets is to dodge the bit error rate. Just so folks know, what Sun does about deciding how big NFS packets should be is to have an argument in the mount table specifying the UDP packet size to use. If none is specified, it's 8KB, which requires routers to reliably pass 4 nearly back-to-back Ethernet packets. Generally, you tweak the size to fit in one (maybe 2) LAN packet(s) if you're NFS mounting across a router. (You also have to do this if a Multibus Sun-2 with a 3Com board is NFS-ing with a Sun-3, since the 3Com board is slow.) This all has to do with the IP unique-ID problem in reassembling IP packets.