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

[Gorry Fairhurst <[e-mail]>]

See below.

On 21/10/2020 14:26, The IESG wrote:
> 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 [e-mail] and [e-mail]).	
>
> 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
> [e-mail] mailing lists by 2020-11-16. Exceptionally, comments may
> be sent to [e-mail] 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 ([e-mail] (mailto:[e-mail])), 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/

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