Re: [tcpm] rfc2581bis [2]: limiting cwnd inflation

> Assume 40 segments sent out (f = 40), 1st segment got dropped. [same
> example as above]
> We get, lets say, 11 acks which fills the hole, which makes cwnd = 31
> (20+11), f = 29(40 -11), after we still have remaining 28 acks, which
> can slide the window one segment at a time [I am assuming that the
> fast-retransmitted segment "overtook" the 28 segments . Of course I am
> assuming some genuine networking scenarios like load balancing
> scenarios/network conditions which causes some irregular ACK pattern
> which can cause more than needed segments to be sent out. [ "needed
> segments" = f/2 = 20 when we entered fast recovery]

I don't understand this.  As soon as the window slides we are out of
fast recovery, the cwnd collapses back down and we go to congestion
avoidance to govern sending instead of the fast recovery rules.  How
does the above lead us to sending inappropriately.

> Also it is not just mis-behaving receivers, another reason which I can
> think of is some intermittent packet duplication can cause this as
> well.

Yep.  And, I willing to add a parenthetical or something about this
point.  But, for this to be a problem you'd have to have a *lot* of
duplication (which runs against all the evidence about that phenomenon
that I have seen).  I.e., I am not worried about a couple extra dupacks
throwing us off a little.  The concern here is that mis-behavior can
cause many times more segments than appropriate to be sent.

> > Regardless of the value of cwnd, I don't think there is a case
> > whereby you'll be actually putting an inappropriate number of
> > segments into the network when things are working properly.
> 
> Hmm.. This is what I am not too sure about, 

Show us how.

(I am not saying there is not a scenario.  I just haven't yet seen a
scenario that would cause a big problem in the absence of a mis-behaving
receiver.  (Or, a very very flawed network element that is duplicating
packets like nobody's business.))

allman