[e2e] New Reno

[Craig Partridge]

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