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

[Jean Mahoney <[e-mail]>]

Martin,

Thank you for the updated file. As we did in RFC 9001, we have 
explicitly set the URLs in the XML file to fix the discrepancy in 
xml2rfc output:

https://www.rfc-editor.org/authors/rfc9002-xmllastrfcdiff.html (these 
changes in the XML)
https://www.rfc-editor.org/authors/rfc9002-lastrfcdiff.html (these 
changes in the text)

https://www.rfc-editor.org/authors/rfc9002.txt
https://www.rfc-editor.org/authors/rfc9002.pdf
https://www.rfc-editor.org/authors/rfc9002.html
https://www.rfc-editor.org/authors/rfc9002.xml

We will await further word from Jana and Ian regarding other AUTH48 
changes and/or approval.

Best regards,

RFC Editor/jm


On 5/17/21 7:16 PM, Martin Thomson via C430 wrote:
> I have these changes staged in our copy and can provide an update based on that.  I don't know how the rfc-editor.org links got broken though: the XML I have uses /info/ for all RFC reference targets.
>
> On Tue, May 18, 2021, at 10:02, Jana Iyengar via C430 wrote:
>> Jean, Ian,
>>
>> Given that we are making these changes for the transport document, it
>> might make sense for us to do these as well. Also so that our github
>> repo is in line with what eventually gets published. I'm happy to make
>> these changes.
>>
>> - jana
>>
>> On Mon, May 17, 2021 at 3:32 PM Ian Swett via C430 <[e-mail]> wrote:
>>> 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
>>>>>>
>>>>>>
>>>>>>
>>> -- 
>>> C430 mailing list
>>> [e-mail]
>>> https://www.rfc-editor.org/mailman/listinfo/c430
>> -- 
>> C430 mailing list
>> [e-mail] <mailto:C430%40rfc-editor.org>
>> https://www.rfc-editor.org/mailman/listinfo/c430
>>