> On 25 Oct 2020, at 12:53, Ian Swett <[email protected]> wrote: > > > The issue raised by Mirja is here(though it was subsumed by an existing > issue): https://github.com/quicwg/base-drafts/issues/4050 > > The quote of interest is "in https://tools.ietf.org/html/rfc5681#section-4.3 > ssthresh is reduced upon entering recovery but cwnd is set to ssthresh when > leaving recovery." > > QUIC's old behavior was overly conservative, since it reduced the CWND > immediately upon loss, rather than reducing ssthresh immediately and CWND > upon exiting recovery. The new text allows for the old behavior or RFC5681 > or things in between, with PRR being an example. > > Ian
Aha Indeed that seems to make sense - I will read this - many thanks, Gorry > >> On Sun, Oct 25, 2020 at 8:42 AM Yoshifumi Nishida <[email protected]> wrote: >> >> Hi Gorry, >> >>> On Sat, Oct 24, 2020 at 4:36 AM Gorry Fairhurst <[email protected]> >>> wrote: >>> >>> So I reviewed this ID several times in the WG. At the WGLC, I had no >>> substantive issues, and I see quite a lot of change since WGLC (most >>> really good!). >>> >>> However, I also something I hadn't expected and that since rev -30, this >>> has introduced the option to use PRR: >>> >>> ..."Implementations MAY reduce the congestion window immediately upon >>> entering a recovery period or use other mechanisms, such as >>> Proportional Rate Reduction ([PRR]), to reduce the congestion >>> window >>> more gradually." >>> >>> This did surprise me, but perhaps the working group thinks this is Reno >>> behaviour? >> >> This seems to be ok to me as QUIC's CC already deviates from Reno in various >> points and the doc just says "similar to Reno". >> Another point is this part is not mandatory. >> >> Since PRR doesn't change the window size after recovery, the deviation looks >> minor from my point of view. >> As long as the algorithm reduces the congestion window properly (be close to >> ssthresh at the end of recovery), I think it won't be aggressive. >> >> Thanks, >> -- >> Yoshi
