> can anybody explain why equation (3) in RFC 2581 is
>   ssthresh = max (FlightSize / 2, 2*SMSS)
> and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used.
> 
> In some postings, I found that FlightSize is usually equal to
> min(rwnd, cwnd) - but not always. According to the RFC, flightsize is
> "the amount of data that has been sent but not yet acknowledged".

One hopes that FlightSize == cwnd.  However, we introduced the
FlightSize notion in RFC2581 because this is not always the case.  Some
stacks let cwnd be changed regardless of how much of the window is
actually used.  So, as an example say cwnd grows to 50 segments, but
only 25 segments per RTT are being injected.  In this case, upon a loss
if cwnd and ssthresh were simply cut in half there would be no change in
the load placed on the network.  But, since everything is keyed off
FlightSize, it would be 30 / 2 or half of the imposed load.  Really it
is trying to get at the fact that the load imposed needs to be cut in
half.

> Let's assume that 10 packets have been sent. If all 10 get lost, flightsize
> is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and no
> more packets are to be sent), flightsize is 4 and ssthresh will be set to 2.
> This seems counterproductive to me since the network is propably more
> congested in the first case than in the second. Therefore, ssthresh should
> be set to a lower value if more packets get lost, i.e. when flightsize is
> larger. For example:
>   ssthresh = max( (min(rwnd, cwnd) - FlightSize) / 2, 2 * SMSS)
> 
> Or did I miss the point?

This is the (a?) case where FlightSize doesn't lead to the right
outcome.  It's not just counterproductive, but actually wrong.  In both
the cases you sketched it was 10 packets per RTT that caused the
congestion.  However, in the second case we start from the notion that
there are only 4 segments in the network.  This is wrong.  If there were
only 4 segments in the network there probably wouldn't have been loss
(just a good guess based on the fact that the first 6 segments made it
through).

However,

  + This situation is conservative.  The flip side (described above) is
    aggressive.  So, if we're going to err, this is the way to err.

  + While I agree that this situation does show a flaw in the notion,
    it's not so clear to me how big of a flaw this really is.  If you
    cannot send new segments as the first six segments in the example
    are ACKed then I guess what is not clear is how much the application
    is really trying for high performance.

  + It's not clear to me how often such a situation really crops up and
    so how much of an impact this imperfection really causes.

I hope that helps!

allman