Re: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-02.txt

[Yuchung Cheng <[e-mail]>]

On Wed, Nov 9, 2022 at 3:13 PM Scheffenegger, Richard <[e-mail]> wrote:
>
> Chairs,
>
> Matt, Yuchung,
>
> This is a summary of my Read of 6937bis-02.
>
> I found mostly editorial only nit-picks, and a few clarification
> questions - if my read of the heuristic is correct now.
>
> In short, I'm happy with the document, there are few editorial nits; I
> would like a very concrete example of a SafeACK, even though the last
> and final description appears to confirm what I assumed a SafeACK would
> be. But then again, still not 100% sure.
>
> Reason for my question: "does not indicate prior fast retransmit has
> been lost" may indicate only partial ACKs which do *not* shrink a SACK
> hole *from the right*, or create a new SACK hole (e.g. splitting an old
> one) are elegible... But partial ACKs on non-SACK sessions would always
> be elegible?

see my reply below

>
> The forced fast retransmit may not be reflected in the PRR packet
> diagram - unless I didn't quite understand the values there...

The examples do not include force retransmit examples. We'd clarify
that in the description of the examples to clarify.

>
> Thanks for doing this important work!
Thanks for the detailed review!


>
> Other than the above (SafeAck), all my comments from 8.Feb 2021 and
> 23.Feb.2021 appear to have been addressed.
>
> Best regards,
>     Richard
>
>
>
> Abstract:
>
>  > PRR potentially replaces the Fast Recovery to regulate
>
> missing noun "Fast Recovery algorithm" (excessive deletion btwn -01/-02.
>
> Also, the abbreviations PRR, ssthresh are mentioned again in
> Introduction, so maybe leave the bracketed acronym out in the abstract.
>
> Sec 1 - maybe reference to RACK-TLP with LRD when LRD is mentioned the
> first time; the reference is further down below currently. There are
> other ways to do LRD (with SACK), but not in the RFC series.
>
> Sec 2 - [6675] is not a link.
>
> Sec 5 - update rfc793 to 9293?

will address the nits above in the next rev. thanks

>
> SafeACK - missing what "and the ACK does not indicate
>     further losses." actually means. No new SACK block ? (new sack
> scoreboard hole)?
>
> Sec 6 - SafeACK again: "and the ACK does not indicate
>     further losses." (concrete example?)
>
>
> Sec 7, PRR example... You describe the forced fast retransmit on the
> first transmission oppty. Shouldn't that shift the "N" transmissions
> here one notch to the left? (The ACK for "4").
>
> PRR
>     ack#   X  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
>     cwnd:    20 20 19 19 18 17 17 16 16 15 15 14 14 13 13 12 12 11 10
>     pipe:    19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10
>     sent:     N  N  R  N        N     N     N     N     N     N     N
no because forced retransmit only applies when the fast recovery
starts (i.e. prr_out = 0). by ack #4, prr_out is already 1 due to the
first "R".

>
> Sec 9 - SafeAck seems to indicate, when SACK is in use, that no new SACK
> range is included (adding a new hole to the scoreboard). However, in a
> non-SACK case, due to the lack of this knowledge, wouldn't be all
> partial ACKs be considered to be SafeACKs?

Yes when SACK is not used SafeACK will be true for all partial ACKs.
To clarify better, we'd add LRD requirement on SACK and non-SACK sup

The current wording in the section "Changes from RFC 6937 is less
clear. We'd revise from
"For TCP, when the latest ACK advances snd.una and does not indicate
prior fast retransmit has been lost"
to
"For TCP, when the latest ACK advances snd.una and does not indicate
further new packet losses on both SACK and NonSACK"

And we'd change the SafeACK descriptions accordingly so they are
consistent across the draft. How to detect packet losses (including
retransmission) is out of scope of PRR (eg sack blocks changes). PRR
recommends RACK-TLP but does not want to mandate a particular loss
detection. Does that answer your question?


>
>
>
>
>
>
>
> Am 08.02.2021 um 23:27 schrieb Scheffenegger, Richard:
> >
> > Hi Matt, Yuchung, Nandita,
> >
> > The heuristic to switch between PRR-CRB and PRR-SSRB is only mentioned
> > in section 1 (intro to bis).
> >
> > Perhaps the actual pseudocode and text in secion 4 (algo) should also be
> > expanded to contain this.
> >
> >  From an implementers viewpoint, the paragraph about the heuristic (as
> > well as my conversation with Matt about this) left me wondering, if this
> > needs additional state, or how to achive this (e.g. tracking changes to
> > the SACK scoreboard - if an additional "hole" got accounted even when
> > snd.una advances, for example.
> >
> > one nit: In the para for the definition of "SACKd", there is one
> > instance where the "SACK blocks" got changed to "sack blocks". Its the
> > only instance of lowercase SACK.
> >
> > Best regards,
> >     Richard
> >
> >
> >
> > Am 14.01.2021 um 08:18 schrieb [e-mail]:
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the TCP Maintenance and Minor Extensions
> >> WG of the IETF.
> >>
> >>          Title           : Proportional Rate Reduction for TCP
> >>          Authors         : Matt Mathis
> >>                            Nandita Dukkipati
> >>                            Yuchung Cheng
> >>     Filename        : draft-ietf-tcpm-prr-rfc6937bis-00.txt
> >>     Pages           : 19
> >>     Date            : 2021-01-13
> >>
> >> Abstract:
> >>     This document updates the Proportional Rate Reduction (PRR) algorithm
> >>     described as experimental in RFC 6937 to standards track.  PRR
> >>     potentially replaces the Fast Recovery and Rate-Halving algorithms.
> >>     All of these algorithms regulate the amount of data sent by TCP or
> >>     other transport protocol during loss recovery.  PRR more accurately
> >>     regulates the actual flight size through recovery such that at the
> >>     end of recovery it will be as close as possible to the ssthresh, as
> >>     determined by the congestion control algorithm.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tcpm-prr-rfc6937bis-00
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-00
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >>
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm