Re: expo ftp bug?

Mike Muuss (mike@BRL.ARPA)
Thu, 10 Mar 88 23:39:50 EST

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

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


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:31 GMT