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

["Scheffenegger, Richard" <[e-mail]>]

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?

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

Thanks for doing this important work!

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?

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

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?







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