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

> Cwnd  = (f/2 + 3*SMSS) + 6SMSS > f.  This can happen since there seems
> to be no explicit rule to cap the cwnd growth which may cause the higher
> than appropriate sending rate to be used.  To make the above example
> assuming f = 10 before fast recovery entered, we would be in a situation
> where cwnd becomes 14!!, which is un-desirable.

It is not.  After out iteration earlier today I went through this in
more detail in my head.  You want cwnd to grow past where it was before
recovery.  That is how you're able to strobe new segments out.  Simple
example:

FlightSize=40
lose 1 segment; expect 39 dupacks (say none are lost)
after the 3rd dupack:
  cwnd = (FlightSize / 2) + 3 = 23
  ssthresh = FlightSize / 2 = 20
  retransmit
receiver 36 more dupacks, on each:
  cwnd += 1
  if FlightSize < cwnd:
    transmit
    FlightSize += 1
receive an ACK for everything
  cwnd = ssthresh

So, basically before the rexmt is ACKed cwnd will be 59 segments---or,
19 more than it was before the loss happened.  But, this increase is
termed *artificial*.  We did not put 59 segments into the network during
the last RTT, we put 19 segments into the network (or, half of the
FlightSize when the loss occured)---so, we did in fact halve our rate
even though the cwnd is larger.  Before continuing the cwnd collapses
back to what it ought to be (20 segments in this case).

What the new text is attempting to do is to allow stacks to protect
against malicious receivers that strobe many more dupacks into the
stream to boost the sending rate.  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.

allman