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 last-call@xxxxxxxx and quic@xxxxxxxx).
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
last-call@xxxxxxxx mailing lists by 2020-11-16. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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 (quic@xxxxxxxx (mailto:quic@xxxxxxxx)), 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
