Re: [tcpm] rfc2581bis-01 and RFC 2861

> > RFC 2581 bases the reduction of cwnd on FlightSize (amount of
> > outstanding data) not cwnd.  So, the CBR over TCP will be reduced by
> > half.  I.e., if you have 10 packets outstanding, a cwnd of 100000
> > packets and take a loss your new cwnd should be 5 packets.  The
> > notion of FlightSize was introduced into the spec. to accommodate
> > cases whereby the cwnd does not accurately reflect the load being
> > placed on the path.  (As has been discussed on this list before,
> > this is not an ideal fix because it causes issues in another case.)
> 
> One may in fact question whether this is even the right thing.

Certainly one could ask that question in general.  But, in the context
of the current discussion I don't know why one would.

My scenario above is: 10 packets outstanding + cwnd=100000 packets + one
  packet loss, which yields a cwnd of 5 packets (per RFC 2581)

Salman's note suggests: 10 packets outstanding + cwnd=10 packets
  (because of CWV) + one packet loss, which yields a cwnd of 5 packets
  (per RFC 2581)

I.e., both these cases yield the same thing---an appropriate reduction
of cwnd in the face inferred congestion.

I don't see how to really solve this problem you note in an endpoint
transport protocol without help from the congested point in the network.
One would hope that some smart AQM could drop in proportion to the
capacity a particular flow is using.

allman