[tcpm] Re: PRR behaviour on detecting loss of a retransmission(WAS:I-DAction: draft-ietf-tcpm-prr-rfc6937bis-06.txt)

[Neal Cardwell <[e-mail]>]

On Mon, Nov 4, 2024 at 8:23 PM Markku Kojo <[e-mail]> wrote:

> Hi Yoshi,
>
...

> The major point is that during fast recovery the value of FlightSize and
> cwnd is RANDOM (in certain range) and the value depends on loss pattern
> and recovery stage at the time the loss of a rexmit is detected. That is,
> if the amount of outstanding data is 100 segments with CUBIC when a loss
> is detected and fast rexmit&fast recovery is entered, the value of
> flightsize can be anything in range 0..170 at the time a loss of a
> rexmitted segments is detected. Similarly, cwnd can be anything in range
> 1..99.
> So, no matter if we use flightsize or cwnd to calculate the new walue of
> ssthresh, we may end up with extremely low value or way too high value.
> And, it is also irrelevant which multiplicative decrease factor we
> decide to use to calculate the new value ssthresh.
>
> ...

>
> > In my view, PRR is designed just to regulate the amount of data sent
> during the recovery based on input
> > parameters such as ssthresh, cwnd and pipe size. So, I would like to
> think the problems in input
> > parameters should basically be outside of PRR.
>
> [MK3] IMHO opinion RFCs should be of high enough quality such that an
> implementor is able to come up with correctly behaving implementation.
> I cannot quite see how it is possible to come up with a correct
> implementation by reading the current text in the PRR doc together with
> the text in RFC 5681 and RFC 9438 that advises to use either cwnd or
> FlightSize to calculate a new value of ssthresh. Could you possibly
> explain how a new value of ssthresh could be correctly calculated when
> a new PRR episode is initiated due to lost rexmit during fast recovery if
> one uses either cwnd or FlightSize to calculated ssthresh as instructed in
> RFC 5681 and/or RFC 9438?
>

Hi Markku,

Thanks for nicely outlining the problem where FlightSize is an incorrect
basis for computing a new ssthresh upon the detection of a lost retransmit.

As Matt nicely summarizes: "This problem is general, quite complicated, and
not specifically related to PRR."

Specifically, I may be missing something, but as far as I can tell, this
problem you identify also applies to the RFC 5681  and RFC 6675
standards, even when not using PRR. Specifically, RFC 5681 / 6675 specify
that upon detecting lost retransmits, ssthresh should be reduced, and
ssthresh should be computed using FlightSize/2. But as you nicely outline
in this thread,  a sender that started with cwnd=100, and entered fast
recovery and set ssthresh to 50, and then detects a lost retransmit, and is
implementing RFC 5681  and/or RFC 6675, may have a FlightSize that is 150,
so the ssthresh computed upon the lost retransmit would be FlightSize / 2 =
150 / 2 = 75. So upon the lost retransmit the ssthresh may, sadly,
*increase* from 50 to 75 when following RFC 5681  and RFC 6675. This is
bad, as you note. But this bad behavior seems implied by the existing RFC
5681  and RFC 6675 standards, even before we add PRR into the mix.

Since this is a pre-existing problem in the existing standards-track RFCs,
and AFAIK there is no solution to this problem that has deployment
experience, IMHO it does not make sense to block the PRR draft process
while the community waits for a solution to this issue.

best regards,
neal