[e2e] New Reno

[F. Bouy]

> >>"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.

You are right about it. After re-reading the document again, I picked up 
points I had missed earlier.

Thank you.

_________________________________________________________________
Find just what you are after with the more precise, more powerful new MSN 
Search. http://search.msn.com.my/ Try it now.