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

["Martin Thomson" <[e-mail]>]

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
>