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

[Ian Swett <[e-mail]>]

Thanks, please make those updates.

On Mon, May 17, 2021 at 5:25 PM Jean Mahoney <[e-mail]> wrote:

> 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]> 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
>>
>>
>>
>>
>