[e2e] New Reno

Craig Partridge craig at aland.bbn.com
Mon Jul 11 08:22:32 PDT 2005


In message <BAY13-F27C93A486BCC227CC7A537B5DC0 at phx.gbl>, "F. Bouy" writes:

>>"recover" gets set in step 1A to the highest sequence number transmitted,
>>which may be well past the current ACK value.  The algorithm ensures
>>that cleaning up the segments between the current cumulative ack
>>and the highest value sent doesn't cause you to (re)enter frast
>>retransmit/fast recovery.
>
>I thought so in the first place, but step 1 states that the checking is only 
>done for the case when we are not in Fast Recovery.

This isn't my particular expertise, but I assume (because there are a
number of situations in which this would be a useful mechanism) that it
is possible to exit Fast Recovery without having retransmitted all the
lost data (e.g., several losses on retransmissions), right?

And then you presumably don't want to re-enter.

If we're going to go further down this path, you probably need to sketch
out a proof of the TCP conditions and the value of recover that proves
that 1B is a situation that can never happen.

Craig


More information about the end2end-interest mailing list