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

[Jean Mahoney <[e-mail]>]

Ian,

Thank you for the updated document! We found a few small issues:

    We found a typo ("itsestimate") in the XML that is not present in
    the markdown file in GitHub:

        This also
        allows a connection to reset itsestimate of min_rtt and smoothed_rtt
        after a disruptive network event; see Section 5.3.

    In our edits, we had updated the [RACK] reference from
    draft-ietf-tcpm-rack-15 to the RFC that replaced it (RFC 8985). We
    see that the reference has changed back to draft-ietf-tcpm-rack-15.
    Is this intentional?

    In the References section, the URLs for RFCs should point to the RFC
    landing page ("/info/" instead of "/rfc/"):

        Current:  <https://www.rfc-editor.org/rfc/rfcNNNN>

        Should be:  <https://www.rfc-editor.org/info/rfcNNNN>

Would you like us to make these updates or would you like to update the 
file?

Best regards,

RFC Editor/jm

On 5/7/21 12:57 PM, Ian Swett wrote:
> 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] 
> <mailto:[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
>     <https://www.rfc-editor.org/search>.
>     -->
>
> Thanks, in https://github.com/quicwg/base-drafts/pull/4890 
> <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 
> <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
>     <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 
> <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
>     <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 
> <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 
> <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
>     <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
>     <https://doi.org/10.1145/118544.118549>>.
>     -->
>
>
> Martin put this into https://github.com/quicwg/base-drafts/pull/4889 
> <https://github.com/quicwg/base-drafts/pull/4889>
>
>
>     Thank you.
>
>     RFC Editor
>
>
>     On Apr 29, 2021, at 11:14 AM, [e-mail]
>     <mailto:[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/
>     <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/
>     <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
>     <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.xml>
>     https://www.rfc-editor.org/authors/rfc9002.html
>     <https://www.rfc-editor.org/authors/rfc9002.html>
>     https://www.rfc-editor.org/authors/rfc9002.pdf
>     <https://www.rfc-editor.org/authors/rfc9002.pdf>
>     https://www.rfc-editor.org/authors/rfc9002.txt
>     <https://www.rfc-editor.org/authors/rfc9002.txt>
>
>     Diff file of the text:
>     https://www.rfc-editor.org/authors/rfc9002-diff.html
>     <https://www.rfc-editor.org/authors/rfc9002-diff.html>
>
>     Diff of the XML:
>     https://www.rfc-editor.org/authors/rfc9002-xmldiff1.html
>     <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
>     <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
>     <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
>
>
>
>