Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS

[Michael Welzl <[e-mail]>]

Hi,

> On 22 Oct 2020, at 13:58, Mirja Kuehlewind <[e-mail]> wrote:
> 
> Hi Michael, hi Matt,
> 
> Frist I like to note that I support moving RFC6937 to PS and I'm happy to see that there is an additional heuristic to address "double drops". 
> 
> Years ago when we worked on RFC6937 in tcpm, I believe I observed a similar problem after slow start, where slow start will not only fill the queue but overshoot to double the cwnd. So when you "only" halve the cwnd as PRR does correctly, you end up will a full queue after recovery and you will see another congestion event soon after.

Yes - that's a general problem that we're now experiencing, as we're playing around with pacing ... halving cwnd sometimes works ok when senders are *not* paced, because the bursts may cause a drop before cwnd has even overshot to double - but with a fully paced sending behavior, halving cwnd after slow start is really not enough of a back-off, I think.


> Rate halving however would end up with only 1/4 of the cwnd after recovery and respectively empty the queue. However, in the end there was not much of a difference (regarding throughput and number of losses), only PRR would actually keep the queue slightly longer full... is this case also addressed by this heuristic?

I'm curious about this too.

I also wonder - in the case that I was concerned about at first, where there is little loss (e.g., only one packet): yes, ACK clocking will then prevent a double drop from happening, but PRR is also more likely than RFC 6675 to keep a queue full at this point, by avoiding the half-RTT break that may have allowed the queue to drain. So I still have my question: has anybody seen problems with this? Is it only always an advantage?   (I'm suspecting that it is, unless the queue is unreasonably large or there is a large amount of statmux ... but I wonder about data).

Cheers,
Michael