[Ballot comment]
Another well-written QUIC document; thank you!
(The last version of -recovery I read was quite some time ago, perhaps the
-09, and left me scratching my head quite often.  This one is quite clear.)

I put my usual editorial suggestions up at https://github.com/quicwg/base-drafts/pull/4685

Section 5.2

> Endpoints SHOULD set the min_rtt to the newest RTT sample after
> persistent congestion is established.  [...]

Earlier we said that min_rtt was the minimum value observed "over the
lifetime of the path", which seems in conflict with this behavior unless
we somehow declare that the path is re-established after a persistent
congestion event.  Perhaps we could finesse the wording a bit in the
former location (given that we go on to allow re-establishing (or
refreshing) the min_rtt at other times as well)?  (Appendix A.3 might be
affected as well, if changes are made.)

Section 5.3

> After the handshake is confirmed, any acknowledgement delays reported
> by the peer that are greater than the peer's max_ack_delay are
> attributed to unintentional but potentially repeating delays, such as
> scheduler latency at the peer or loss of previous acknowledgements.

I don't think I understand how loss of previous acknowledgements could
induce a peer to delay sending an ack longer than its max_ack_delay
after an ack-eliciting packet.

Section 6.2.1

> A sender SHOULD restart its PTO timer every time an ack-eliciting
> packet is sent or acknowledged, when the handshake is confirmed
> (Section 4.1.2 of [QUIC-TLS]), or when Initial or Handshake keys are
> discarded (Section 4.9 of [QUIC-TLS]).  [...]

If I understand correctly, "handshake is confirmed" and "handshake keys
are discarded" occur simultaneously, thus it is redundant to list both.

Section 6.2.3

> Endpoints
> that do not cease retransmitting packets in response to
> unauthenticated data risk creating an infinite exchange of packets.

We may want to be more precise about what "unauthenticated data" means
here, since in -transport we say that even Initial packets are
"authenticated" in some sense.

Section 6.2.4


> When a PTO timer expires, a sender MUST send at least one ack-
> eliciting packet in the packet number space as a probe.  [...]
> [...]
> When the PTO timer expires, an ack-eliciting packet MUST be sent.  [...]

These look redundant to me (which, of course, does not necessarily mean
that there is no value in having both).

Section 7.7

> Endpoints can implement pacing as they choose.  A perfectly paced
> sender spreads packets exactly evenly over time.  For a window-based
> congestion controller, such as the one in this document, that rate
> can be computed by averaging the congestion window over the round-
> trip time.  Expressed as a rate in bytes:

I cringed a little when I saw a rate being expressed as a unit
expression with no time denominator, but am not sure how it might be
improved.  The best I can come up with is "bytes/time".

Section 8.1

I guess in some sense the observed RTT is also a signal under the
control of a (Dolev-Yao) attacker, in addition to the loss and ECN
signals.

Appendix A

Should we say explicitly that '^' in the pseudocode is used to indicate
exponentiation?

[Ballot comment]
Thank you for the work put into this document. Even for a non transport person like myself, I find the text easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Does the QUIC WG intend to have a BCP-like document on how network devices on the path should handle buffers? E.g., QUIC ressembles a lot to TCP so nodes can apply back pressure with mechanisms similar to RED (but, AFAIK, RED is mainly applied to TCP traffic so not to QUIC/UDP).

-- Abstract --
Should the QUIC version be specified ?

-- Section 1 --
Suggest to specify version 1 for the 2nd sentence.

This (too?) short introduction would benefit by mentioning UDP transport.

== NITS ==

-- Section 7.2 --
  "Endpoints SHOULD use an initial congestion
  window of 10 times the maximum datagram size (max_datagram_size),
  limited to the larger of 14720 bytes or twice the maximum datagram
  size. "

The above text looks ambiguous to me especially with the ',' before 'limited'.

Also, s/8 byte overhead/8-byte overhead/ ?

[Ballot comment]
Thanks to Derrell Piper for the SECDIR review.

** Section 3.  Per “The encryption level indicates the packet number space, as described in [QUIC-TRANSPORT ]”, I think that reference here is Section 4.* from [QUIC-TLS] as I can’t find a mapping between PNS and encryption levels as discussed here in [QUIC-TRANSPORT].

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-quic-recovery-32, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-16):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: quic-chairs@ietf.org, quic@ietf.org, magnus.westerlund@ericsson.com, lars@eggert.org, draft-ietf-quic-recovery@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-quic-recovery-32.txt> (QUIC Loss Detection and Congestion Control) to Proposed Standard


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@ietf.org and quic@ietf.org).

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@ietf.org mailing lists by 2020-11-16. Exceptionally, comments may
be sent to iesg@ietf.org 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@ietf.org (mailto:quic@ietf.org)), 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/

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.