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

[Markku Kojo <[e-mail]>]

Hi, Neal, all,

I have not been able to follow the progress of this draft for a long 
while, so apologies for chiming in this late.

I took a quick look at the latest discussions on setting RecoverFS.

The idea of setting RecoverFS = pipe seems like a neat idea to get cwnd 
descend smoothly to the target in the given example. However, isn't it 
more important to ensure that in all cases the sender sends at most 
ssthresh pkts per RTT during the recovery and that in the end of the 
recovery cwnd is at most ssthresh?

If I am not mistaken, reodering (and Ack losses) may result in undesired 
outcome. Let's modify Neal's example a bit such that reordering occurs but 
reordering window (with RACK-TLP) is slightly too small:

CC = Reno
cwnd = 100 packets
The application writes 100*MSS.
TCP sends 100 packets.

In this example the TCP sender has detected reordering with RACK-TLP or 
some other technique, so does not enter fast recovery on the third 
SACKed packet, but rather waits a while to accumulate more SACKs.

>From the flight of 100 packets, 1 packet is lost (P1), and 24 packets 
are delayed (packets P2..P25) and 3 packets (P26..P28) are SACKed 
(assume P2..P25 arrive after P28, for example).

We enter fast recovery with PRR.

RecoverFS = snd.nxt - snd.una = 100

ssthresh = cwnd / 2 = 50  (Reno)

pipe = snd.nxt - snd.una - (lost + SACKed) = 100 - (25 + 3) = 72 packets

The expression (pipe > ssthresh) is true for a number of consecutive 
SACKs, so we use the PRR code path repeatedly for a while as SACKs stream 
in for P2..25 and P29..P100.

When the the SACK for P100 has been processed we have sent

Sent_so_far = CEIL(prr_delivered * ssthresh / RecoverFS)
             = CEIL(96 * 50 / 72)
             = 67

So, PRR does not exit with cwnd = 50 but with much higher cwnd than 
expected.

If CC = CUBIC

Sent_so_far = CEIL(prr_delivered * ssthresh / RecoverFS)
             = CEIL(96 * 70 / 72)
             = 94


The same behavior seems to occurs also if the is significant Ack loss 
among P2..25 and at least one pkt gets reordered out of the reordering 
window. But, maybe I am missing something?


In addition, it seems that the algorithm in the latest version does not 
address my WGLC comment on reducing send rate (ssthresh) again if 
RACK-TLP detects loss of a retransmission. The sender must reduce 
ssthresh again as loss of a rexmit occurs on another RTT. If it is not 
done, the fast recovery keeps on sending at the same rate until the end 
of recovery regardless of how many times a segment has to be 
retransmitted. This sounds very bad behaviour to me in front of heavy 
congestion that drops a lot of pkts (rexmits) and the PRR sender does not 
react at all.

In addtion, there are a few other things that might be useful to
correct/clarify:

- When exactly does PRR algorithm exit? That is, is the algo steps
   executed also for the final cumulative ACK that covers RecoveryPoint
   (or recover)?

- The draft reads:

   "Although increasing the window
    during recovery seems to be ill advised, it is important to remember
    that this is actually less aggressive than permitted by RFC 5681,
    which sends the same quantity of additional data as a single burst in
    response to the ACK that triggered Fast Retransmit."

  I think it should cite RFC 6675 as TCP Reno loss recovery specified in
  RFC 5681 soes not send such a burst.


On Mon, 26 Feb 2024, Neal Cardwell wrote:

> As noted in the draft, revision 06 primarily has a single change relative to 05: it updates
> RecoverFS to be initialized as "RecoverFS = pipe" in both the prose and pseudocode.
> 
> Thanks to Richard Scheffenegger and the TCPM community for reviewing the 05 revision.
> Comments/suggestions welcome!
> 
> Thanks!
> neal
> 
> 
> On Mon, Feb 26, 2024 at 10:23 AM <[e-mail]> wrote:
>       Internet-Draft draft-ietf-tcpm-prr-rfc6937bis-06.txt is now available. It is a
>       work item of the TCP Maintenance and Minor Extensions (TCPM) WG of the IETF.
>
>          Title:   Proportional Rate Reduction for TCP
>          Authors: Matt Mathis
>                   Nandita Dukkipati
>                   Yuchung Cheng
>                   Neal Cardwell
>          Name:    draft-ietf-tcpm-prr-rfc6937bis-06.txt
>          Pages:   17
>          Dates:   2024-02-26
>
>       Abstract:
>
>          This document updates the experimental Proportional Rate Reduction
>          (PRR) algorithm, described RFC 6937, to standards track.  PRR
>          provides logic to regulate the amount of data sent by TCP or other
>          transport protocols during fast 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 slow start threshold
>          (ssthresh), as determined by the congestion control algorithm.
>
>       The IETF datatracker status page for this Internet-Draft is:
>       https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/
>
>       There is also an HTML version available at:
>       https://www.ietf.org/archive/id/draft-ietf-tcpm-prr-rfc6937bis-06.html
>
>       A diff from the previous version is available at:
>       https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-prr-rfc6937bis-06
>
>       Internet-Drafts are also available by rsync at:
>       rsync.ietf.org::internet-drafts
> 
>
>       _______________________________________________
>       tcpm mailing list
>       [e-mail]
>       https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
>