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

Hi,

Nit (Freudian slip?): Section 3, 1st para has "BBR-SSRB". Guess the
hamming distance between the TLA BBR and PRR is too small :)

Also, after having worked on that code lately, I don't think I fully
agree with the wording in the statement here
        .... "recommended to use BBR-SSRB
        by default.  For all of the environments explored in earlier PRR
  ->    research, the new heuristic is consistent with the old
  ->    recommendation."

Reason being that the heuristic - as I understand it currently, before
reading further into -01 - effectively switches to PRR-CRB during the
first window after loss always (once pipe < ssthresh), and only enables
PRR-SSRB in the 2nd window, when snd.una advances again after the
retransmission(s) are delivered to the client.

The prior recommendation was to generally use PRR-SSRB, critically also
in the first window, when snd.una does not advance yet - provided pipe
was smaller than ssthresh. And by that possibly increasing cwnd already.

I guess the heuristic, as described, would never be in SSRB mode during
the first window of loss recovery - unless the criterial is extended
(e.g. advance of snd.fack [although not specified in the RFC series]
without indication of additional loss (additional holes in the scoreboard).

Also, LRD is mentioned in the text, but unless I am mistaken, RACK may
be the only variant of TCP in the RFC series, where that is specified.

Perhaps a short paragraph about the merit of the heuristic, when lost
retransmission detection is not available (and a RTO will be needed in
any case some time later) would be good. After all, assuming SACK,
successfully retransmitting as many packets during the initial loss
recovery epoch should help drive goodput up a little faster, and
minimize the number of packets that RTO needs to recover, correct?

Overall I like this 6937bis text!

Best regards,
    Richard

Am 22.02.2021 um 23:51 schrieb internet-drafts@ietf.org:
>
> 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-01.txt
> 	Pages           : 18
> 	Date            : 2021-02-22
>
> Abstract:
>     This document updates the experimental Proportional Rate Reduction
>     (PRR) algorithm, described 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 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-01
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-prr-rfc6937bis-01
>
>
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>