Re: [C430] AUTH48 [JM]: RFC 9002 <draft-ietf-quic-recovery-34.txt> NOW AVAILABLE

[Ian Swett <[e-mail]>]

Similar to Martin, I'm writing PRs to address these issues.

Changes are in PR #4892 <https://github.com/quicwg/base-drafts/pull/4892>
unless otherwise noted.  I've gone over the changes with Jana and he's now
approved the relevant PRs, so I think we're good to go.

On Thu, Apr 29, 2021 at 2:19 PM <[e-mail]> wrote:

> Authors,
>
> While reviewing this document during AUTH48, please resolve
> (as necessary) the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search.
> -->
>
> Thanks, in https://github.com/quicwg/base-drafts/pull/4890


>
> 2) <!-- [rfced]  We have updated the cross reference to point to RFC 6298
> ("Computing TCP's Retransmission Timer") instead of RFC 6297 ("A Survey of
> Lower-than-Best-Effort Transport Protocols"). Please let us know if
> other changes are necessary.
>
> Original:
>    QUIC uses a probe timeout (PTO; see Section 6.2), with a timer based
>    on TCP's RTO computation; see [RFC6297].
>
> Current:
>    QUIC uses a probe timeout (PTO; see Section 6.2), with a timer based
>    on TCP's retransmission timeout (RTO) computation; see [RFC6298].
> -->
>
>
Thanks for catching that!


>
> 3) <!-- [rfced] Does the following improve the readability of the
> paragraph?
>
> Current:
>    Endpoints SHOULD set the min_rtt to the newest RTT sample after
>    persistent congestion is established. This is to allow a connection
>    to reset its estimate of min_rtt and smoothed_rtt after a
>    disruptive network event (Section 5.3), and because it is possible
>    that an increase in path delay resulted in persistent congestion
>    being incorrectly declared.
>
> Perhaps:
>    Endpoints SHOULD set the min_rtt to the newest RTT sample after
>    persistent congestion is established because it is possible that
>    an increase in path delay resulted in persistent congestion being
>    incorrectly declared. This also allows a connection to reset its
>    estimate of min_rtt and smoothed_rtt after a disruptive network
>    event (Section 5.3).
> -->
>
>
I agree this is more readable, but it is subtly different, so I put it in a
separate PR: https://github.com/quicwg/base-drafts/pull/4891


>
> 4) <!-- [rfced]  In the following sentence, do implementations also
> increase the time threshold?
>
> Current:
>     Implementations can detect spurious retransmissions and increase
>     the reordering threshold in packets or time to reduce future
>     spurious retransmissions and loss events.
>
> Perhaps:
>     Implementations can detect spurious retransmissions and can increase
>     the reordering threshold in packets or increase the time threshold
>     in order to reduce future spurious retransmissions and loss events.
> -->
>
>
Changed to "the packet or time reordering threshold to reduce..." to
clarify.


> 5) <!-- [rfced] Note that we have marked this Note as an <aside>.
> <aside> is defined as follows:
>
> From https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2
>    This element is a container for content that is semantically
>    less important or tangential to the content that surrounds it.
>
> Please let us know if any updates are needed.
> -->
>
>
Included in https://github.com/quicwg/base-drafts/pull/4889


>
> 6) <!-- [rfced] Throughout the text, the following term appears to be used
> inconsistently. Please review these occurrences and let us know if/how they
> may be made consistent.
>
> application data / Application Data
>
> Note that RFC-to-be 9000 <draft-ietf-quic-transport> uses the lowercase
> form consistently.
>
> We raised a similar question for RFC-to-be 9001; the authors decided on
> the following:
>
> > The outcome is that figures will use title case for consistency (as
> appropriate)
> > and text will use the  lowercase form.  There is one reference to TLS
> > Application Data, where I have kept the title case to match the usage in
> RFC 8446.
>
> (see https://www.rfc-editor.org/pipermail/c430/2021-April/000016.html)
>
> -->
>

I changed the text to use "Application Data" when referring to the packet
number space, and "application data" otherwise.
https://github.com/quicwg/base-drafts/pull/4893


>
>
> 7) <!-- [rfced]  We are having difficulty parsing the following sentence.
> Could the packets be acknowledged if the keys were still available?
>
> Current:
>    Initial packets and Handshake packets could be never acknowledged,
>    but they are removed from bytes in flight when the Initial and
>    Handshake keys are discarded
>
> Perhaps:
>    When the Initial and Handshake keys are discarded, the Initial
>    packets and Handshake packets can no longer be acknowledged, and
>    they are removed from bytes in flight
> -->
>
>
Yes, the packets can be acknowledged until the keys are discarded, so I
took your suggestion and added 'keys' after the first 'Initial' for
parallelism.


>
> 8) <!-- [rfced]  In the following, is "PTO timer" rather than "probe
> timer"
> meant?
>
> Current:
>    That is, the client MUST set the probe timer if the client has not
>    received an acknowledgment for any of its Handshake packets and the
>    handshake is not confirmed (see Section 4.1.2 of [QUIC-TLS]), even
>    if there are no packets in flight.
> -->
>
>
 Yes, at some point we were using "probe timer" and "PTO timer"
interchangeably, but it's best to consistently use PTO timer. Fixed.


> 9) <!-- [rfced] We are having difficulty parsing the following:
>
> Current:
>    It is expected that keys are discarded after packets encrypted with
>    them would be acknowledged or declared lost.
>
> Perhaps:
>    It is expected that keys are discarded at some time after the
>    packets encrypted with them are either acknowledged or declared lost.
>
> Or perhaps:
>    Some time after the packets are either acknowledged or declared lost,
>    the keys with which they were encrypted are discarded.
> -->
>
>
The first suggestion is good, so I will use that. The second suggestion
doesn't fully convey the intent of the sentence, IMHO.


>
> 10) <!-- [rfced]  We note that RFC 9000 (draft-ietf-quic-transport) uses
> <tt> for some equations.  Please review and let us know if you would like
> the equations to appear in <tt>.
>
> Current:
>    Packets 2 through 8 are declared lost when the acknowledgment for
>    packet 9 is received at t = 12.2.
>
>    The congestion period is calculated as the time between the oldest
>    and newest lost packets: 8 - 1 = 7.  The persistent congestion
>    duration is: 2 * 3 = 6.
> -->
>
>
Good point, MT changed in https://github.com/quicwg/base-drafts/pull/4889


>
> 11) <!-- [rfced] Does the following reordering of the sentences improve
> readability?
>
> Current:
>    When bytes in flight is smaller than the congestion window and
>    sending is not pacing limited, the congestion window is
>    underutilized.  When this occurs, the congestion window SHOULD NOT be
>    increased in either slow start or congestion avoidance.  This can
>    happen due to insufficient application data or flow control limits.
>
> Perhaps:
>    When the count of bytes in flight is smaller than the congestion
>    window and sending is not pacing limited, the congestion window is
>    underutilized, which can happen due to insufficient application
>    data or reduced flow control limits.  When this occurs in either the
>    slow start or congestion avoidance states, the congestion window
>    SHOULD NOT be increased.
> -->
>
>
I think the reordering reads more clearly, but the addition of "count of"
does not help, so I swapped the second and third sentences.


> 12) <!-- [rfced] We did not find the paper below published in January 1995.
> We did find one published in 1987 and a revision published in 1991.
> Which one should be referenced?
>
> Original:
>    [RETRANSMISSION]
>               Karn, P. and C. Partridge, "Improving Round-Trip Time
>               Estimates in Reliable Transport Protocols", ACM SIGCOMM
>               CCR , January 1995.
>
> Perhaps:
>    [RETRANSMISSION]
>               Karn, P. and C. Partridge, "Improving Round-Trip Time
>               Estimates in Reliable Transport Protocols", ACM SIGCOMM
>               Computer Communication Review, DOI 10.1145/55483.55484,
>               August 1987, <https://doi.org/10.1145/55483.55484>.
>
> Or perhaps:
>    [RETRANSMISSION]
>               Karn, P. and C. Partridge, "Improving Round-Trip Time
>               Estimates in Reliable Transport Protocols", ACM Transactions
>               on Computer Systems, DOI 10.1145/118544.118549,
>               November 1991, <https://doi.org/10.1145/118544.118549>.
> -->
>
>
Martin put this into https://github.com/quicwg/base-drafts/pull/4889


>
> Thank you.
>
> RFC Editor
>
>
> On Apr 29, 2021, at 11:14 AM, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2021/04/29
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>   Please review and resolve any questions raised by the RFC Editor
>   that have been included in the XML file as comments marked as
>   follows:
>
>   <!-- [rfced] ... -->
>
>   These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>   Please ensure that you review any changes submitted by your
>   coauthors.  We assume that if you do not speak up that you
>   agree to changes submitted by your coauthors.
>
> *  Content
>
>   Please review the full content of the document, as this cannot
>   change once the RFC is published. Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
>
> *  Copyright notices and legends
>
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions
>   (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>   Please review the markup in the XML file to ensure that elements of
>   content are correctly tagged.  For example, ensure that <sourcecode>
>   and <artwork> are set correctly.  See details at
>   <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
>
> *  Formatted output
>
>   Please review the PDF, HTML, and TXT files to ensure that the
>   formatted output, as generated from the markup in the XML file, is
>   reasonable.  Please note that the TXT will have formatting
>   limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email with one of the following,
> using ‘REPLY ALL’ as all the parties CC’ed on this message need to see
> your changes:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email s
> tating that you approve this RFC for publication.  Please use ‘REPLY ALL’
> as all the parties CC’ed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9002.xml
>   https://www.rfc-editor.org/authors/rfc9002.html
>   https://www.rfc-editor.org/authors/rfc9002.pdf
>   https://www.rfc-editor.org/authors/rfc9002.txt
>
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9002-diff.html
>
> Diff of the XML:
>   https://www.rfc-editor.org/authors/rfc9002-xmldiff1.html
>
> The following file is provided to facilitate creation of your own
> diff files of the XML.  This file is a best effort to capture v3-related
> format updates only:
>   https://www.rfc-editor.org/authors/rfc9002.form.xml
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9002
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9002 (draft-ietf-quic-recovery-34)
>
> Title            : QUIC Loss Detection and Congestion Control
> Author(s)        : J. Iyengar, Ed., I. Swett, Ed.
> WG Chair(s)      : Lars Eggert, Lucas Pardue, Matt Joras
> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>
>
>
>