mike@BRL.ARPA (Mike Muuss) (03/11/88)
Greg - Good work on the detailed sleuthing. Phil here at BRL experienced the same problems when using 3 different TCPs here, which definitely points the finger at the TCP on poor <expo>. I'm the original proponent of the tcp_mss code, and moving it to 1024 will actually cause you significantly more trouble than the 512 setting, as it will case the packets to be fragmented as they enter the IMP-based networks (ARPANET, MILNET). If you are trying to squeeze a few more data bytes per packet from the network, be certain that this relationship holds: tcp_mss <= Network_MTU - Max_Header_Size In the case of IMPs, the MTU is 1006. The max header (TCP+IP) isn't huge, perhaps 42 bytes :-). Therefore, your tcp_mss should not exceed 964 bytes. If you want to be really conservative, a number like 920 or 930 would allow lots of room for IP Options (which are rare, but not unheard of). Even at 920 that would give you a 1.8x performance advantage. HOWEVER, note that no system is REQUIRED to accept a packet with more than 512 data bytes, so by implementing this change you may reduce your interoperability. No UNIX system is likely to mind, but some non-UNIX systems (esp. some MULTICS machines) are unhappy with larger MSS settings. If you induce IP fragmentation through the core network system, you will do very much worse than with the current setting. The problem is that if one fragment of a multi-fragment IP datagram is dropped, then the whole transmission (all fragments) are not useful, and have to be re-sent. If each TCP transmission fits in a single IP datagram, then TCP has the opportunity to be more sensible with it's retransmission strategy. At BRL, we run SUNOS 3.4, with the "Van" TCP code replacing the Sun code. I believe he offers the fixes in both source and Sun-binary-patch form. It's a real winner, consult the archives of the <TCP-IP> list for details. Best, -Mike