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

[Neal Cardwell <[e-mail]>]

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).

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
>>
>>