Re: [Last-Call] Last Call: <draft-ietf-quic-recovery-32.txt> (QUIC Loss Detection and Congestion Control) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Gorry, 

On Sat, Oct 24, 2020 at 4:36 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> 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
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux