Re: [tcpm] draft-ietf-tcpm-prr-rfc6937bis-03 and RecoverFS initialization

[Yuchung Cheng <[e-mail]>]

On Mon, Apr 17, 2023 at 2:00 PM Neal Cardwell <[e-mail]> wrote:

>
>
> On Mon, Apr 17, 2023 at 4:13 PM Yuchung Cheng <[e-mail]> wrote:
>
>> Hi Neal,
>>
>> That's a good point and it was considered in the early stage of PRR. We
>> picked FlightSize (=snd.nxt - snd.una) to ensure ssthresh/RecoverFS
>> faithfully reflects the proportion of the congestion control window
>> reduction: RFC5681 still use FlightSize to compute ssthresh. But  some TCP
>> or specific C.C.s may use either cwnd (e.g. Linux cubic/reno) or pipe.  How
>> about a small graph:
>>
>> "If a TCP or congestion control implementation uses cwnd or pipe instead
>> of FlightSize to compute ssthresh, then RecoverFS should use the specific
>> metric accordingly, i.e. cwnd right before recovery"
>>
>
> AFAICT that analysis is conflating two different issues:
>
> (1) How does the congestion control compute ssthresh (based on cwnd or
> pipe or FlightSize?) You rightly point out that approaches vary for this
> part.
>
> (2) How does PRR determine what fraction of outstanding packets have been
> delivered (aka prr_delivered / RecoverFS)?
>
> AFAICT to get the right answer for the (2) question, RecoverFS should be
> initialized to "pipe", no matter what approach the CC takes for answering
> (1).
>
> My understanding of PRR is that if (pipe > ssthresh) is true, then the
> algorithm is doing Proportional Rate Reduction, and is essentially
> computing:
>
>       sndcnt ~= (target data sent in recovery)            - (actual data
> sent in recovery)
>       sndcnt ~= (fraction of data delivered) * ssthresh   - prr_out
>       sndcnt ~= (prr_delivered / RecoverFS ) * ssthresh   - prr_out
>
> For the (target data sent in recovery) to equal ssthresh at the end of the
> first round in recovery the algorithm must reach the point where
> prr_delivered == RecoverFS, so that (prr_delivered / RecoverFS ) is 1.
> Since  prr_delivered can only reach as high as "pipe" at the start of
> recovery, to be able to reach that condition we need to have RecoverFS ==
> "pipe". If RecoverFS is (snd.nxt - snd.una) then RecoverFS is too big, and
> prr_delivered won't be able to match RecoverFS and the (target data sent in
> recovery) won't reach ssthresh, and the algorithm will undershoot (the cwnd
> won't reach the ssthresh specified by congestion control, however it
> calculated that).
>
I still can't parse your analysis after reading it multiple times.

"prr_delivered can only reach as high as "pipe" at the start of recovery"
--> prr_delivered is initiated to 0 at the start of the recovery?
"If RecoverFS is (snd.nxt - snd.una) then RecoverFS is too big, and
prr_delivered won't be able to match RecoverFS" --> why is RecoverFS too
big and prr_delivered won't reach it.

I am not saying RecoverFS initiated to "pipe" is wrong. I just don't see a
substantial difference between FlightSize vs pipe, unless the
FlightSize/cwnd is small and/or limited-transmits were not used.

maybe you can walk an example with FlightSize vs pipe...


>
> What am I missing? :-)
>
> best regards,
> neal
>
>
>
>
>> On Mon, Apr 17, 2023 at 11:23 AM Neal Cardwell <[e-mail]>
>> wrote:
>>
>>> Regarding this line in draft-ietf-tcpm-prr-rfc6937bis-03:
>>>
>>>    RecoverFS = snd.nxt - snd.una // FlightSize right before recovery
>>>
>>> AFAICT this should be:
>>>
>>>   RecoverFS = pipe  // RFC 6675 pipe algorithm
>>>
>>> Rationale: when recovery starts, often snd.nxt - snd.una includes 1 or
>>> more lost packets above snd.una and 3 or more SACKed packets above that;
>>> those packets are not really in the pipe, and not really in the FlightSize.
>>>
>>> With the draft as-is, packets that were SACKed on ACKs that happened
>>> before entering fast recovery are incorporated in RecoverFS (snd.nxt -
>>> snd.una) but never in prr_delivered (since that is set to 0 upon entering
>>> fast recovery), so at the end of fast recovery the expression:
>>>
>>>   CEIL(prr_delivered * ssthresh / RecoverFS)
>>>
>>> can be quite far below ssthresh, for very large numbers of packets
>>> SACKed before entering fast recovery (e.g., if the reordering degree is
>>> large).
>>>
>>> AFAICT that means that at the end of recovery the cwnd could be quite
>>> far below ssthresh, to the same degree, resulting in the cwnd being less
>>> than what congestion control specified when the connection entered fast
>>> recovery.
>>>
>>> AFAICT switching to RecoverFS = pipe fixes this, since it means that
>>> RecoverFS only includes packets in the pipe when the connection enters fast
>>> recovery, and thus prr_delivered can eventually reach RecoverFS, so tha) t
>>> the target number of packets sent (CEIL(prr_delivered * ssthresh /
>>> RecoverFS) can fully reach ssthresh.
>>>
>>> Apologies if I'm missing something or this has already been discussed.
>>>
>>> best regards,
>>> neal
>>>
>>>