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

[Markku Kojo <[e-mail]>]

Hi Neal, all,

I changed the subject line for discussing this specific topic of PRR 
behaviour when loss of a retransmission is detected.

Please see below tagged [MK].

On Mon, 18 Mar 2024, Neal Cardwell wrote:

>       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.
> 
> 
> I would argue that the question of whether a connection should reduce ssthresh when RACK-TLP detects the
> loss of a retransmission, while important, is outside the scope of PRR. PRR is taking loss detection and
> congestion control decisions as externally provided inputs into PRR. When to mark a packet as lost is a
> loss detection question, and whether to reduce ssthresh upon a particular packet loss is a congestion
> control decision. PRR is focused on taking the ssthresh output from congestion control, and loss detection
> decisions from the loss detection algorithm, and deciding how to evolve the cwnd to try to smoothly and
> safely converge the volume of in-flight data toward the given ssthresh.

[MK] Yes, agreed that loss detection (including detecting the loss of 
a retransmission) is outside of scope of PRR (i.e., detecting loss of 
rexmit is currently RACK-TLP).

However, PRR is a congestion control algorithm defining the congestion 
control behaviour of the sender during a fast recovery. Currently it 
borrows only the multiplicative decrease factor from other congestion 
control algos, that is, either from RFC 5681 or RFC 9438) but defines 
everything else in controlling the send rate (= congestion ctrl) during 
fast recovery.

PRR does not need to define the multiplicative decrease factor to be used 
when a loss of rexmitted segment is detected. It may borrow it from 
another doc like it currently does for entering loss recovery.
However, I don't quite see how some other document possibly could define 
how the other PRR-specific variables are reinitialized, 
e.g., RecoverFS. Maybe I am missing something but the algo seems 
not to work correctly with a lowered ssthresh after detection of 
lost rexmit unless RecoverFS (and prr_deliverd and prr_out too?) is also 
adjusted. Could you explain how the algo is supposed to work upon 
detecting loss of a rexmit with multiplicative decrease factor of 0.5, 
for example.

Thanks,

/Markku