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

From: The IESG <[email-masked]>
Date: Wed, 21 Oct 2020 06:26:57 -0700

The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'QUIC Loss Detection and Congestion Control'
  <draft-ietf-quic-recovery-32.txt> as Proposed Standard

This document is part of a combined 26-day last call for multiple 
related documents that defines the QUIC protocol and the HTTP mapping
onto QUIC. The documents are:
	
   - draft-ietf-quic-transport
   - draft-ietf-quic-recovery
   - draft-ietf-quic-tls
   - draft-ietf-quic-invariants
   - draft-ietf-quic-http
   - draft-ietf-quic-qpack

Due to its GitHub-centric work style, the QUIC WG requests that LC review 
comments are individually filed as issues in the WG repository at 
https://github.com/quicwg/base-drafts if at all possible. A summary email with 
URLs to the individual issue should then also be sent to the relevant mailing list 
(primarily [email-masked] and [email-masked]).	

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-11-16. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document describes loss detection and congestion control
   mechanisms for QUIC.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list ([email-masked] (mailto:[email-masked])), which is
   archived at https://mailarchive.ietf.org/arch/
   search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-recovery.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2910/

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 24 Oct 2020 12:36:00 +0100

See below.

>     https://datatracker.ietf.org/ipr/2910/

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?

... anyway before I think on that, I wonder if I missed a discussion or 
issue specifically on this topic (I am no git expert). Could someone 
send a pointer to where the WG discussed the updated congestion response 
and point me at the discussion about if this method is ready for 
inclusion in the PS for QUIC?

Slightly at the same time, I see the topic of whether RFC 6937 (PRR) 
should progress towards PS - with changes - is on the agenda for 
IETF-109 in TCPM, so this is clearly something on the radar for 
discussion...

Gorry

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 25 Oct 2020 05:42:06 -0700

Hi Gorry,

> This did surprise me, but perhaps the working group thinks this is Reno

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

---

From: Ian Swett <[email-masked]>
Date: Sun, 25 Oct 2020 08:53:17 -0400

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

---

From: "Gorry (erg)" <[email-masked]>
Date: Sun, 25 Oct 2020 17:57:08 +0000

> On 25 Oct 2020, at 12:53, Ian Swett <[email-masked]> 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-masked]> wrote:
>> 
>> Hi Gorry, 
>> 
>>> On Sat, Oct 24, 2020 at 4:36 AM Gorry Fairhurst <[email-masked]> wrote:
>>> 
>> 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".
>> 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