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

From: [email-masked]
Date: Mon, 22 Feb 2021 14:51:24 -0800

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/

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 23 Feb 2021 00:48:36 +0100

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 [email-masked]:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>