Re: revision RFC 2001 (draft-ietf-tcpimpl-cong-control-00.txt)

[Andi Kleen <[e-mail]>]

In article <[e-mail]>,
David Borman <[e-mail]> writes:
> Matt,
>> MSS is better described as a sender state variable, which may or may
>> not agree with the other end of the connection.
>> 
>> As a consequence, algorithms that require the receiver to know the
>> senders segment size can not, in general, be implemented correctly.
>> 
>> In the draft, the sentence "Specifically, an ACK MUST be generated for
>> every second full-sized segment.", is not sufficient to assure correct
>> operation because the receiver can not identify segments which the
>> sender considers to be full sized.

> Yes you can.  In the receiver, you implement a local state variable that
> keeps track of the largest packet ever received from the peer, and use
> that in determining how many full size packets you have received, instead
> of the sending MSS.  I implemented this in UNICOS years ago, and it worked
> fine for most cases.

What happens when the routing changes and path mtu discovery on the sender
lowers the MSS effectively? Then after the routing shift this variable will
contain a too big value and the receiver will not send enough acks.

In Linux 2.1 this problem came up and got fixed with the following
algorithm:

Initialize rcv_mss with the mss the other end announced.

If a packet arrives with len > rcv_mss set rcv_mss to len.
If two packets with SS >= 536 arrive in a row set rcv_mss to this length.

Send an ack at least for every rcv_mss*2 data bytes.

The reason of the 536 rule is to make sure that delayed acks still work
with interactive traffic. For paths with MTUs < 576 [some packet radio links]
it will break, but it is assumed that those fragment/defragment at a lower 
layer.

So far this algorithm seems to work well to adapt to changing MSS. The 
original reason for its implementation was the fact that a well-known 
workstation OS announces 64k MSS on a HIPPI interface, but effectively
only sends 48k packets - the result was that Linux already got into
delayed ack mode and the data transfer was very slow.

So far this algorithm seems to work well, but I would be interested in a
discussion about any shortcommings it may have.

-Andi