Re: [tcpm] Linux doesn’t implement RFC3465

[Neal Cardwell <[e-mail]>]

On Mon, Aug 2, 2021 at 7:02 PM Vidhi Goel <[e-mail]> wrote:

>
> On Mon, Aug 2, 2021 at 3:37 PM Mark Allman <[e-mail]> wrote:
>>
>>>
>>> > The fact is that Linux CC has long moved to infinite L since 2031,
>>>
>>> So, if our experience is with L=\infinity and it is demonstrably OK
>>> why don't we say *THAT* instead of "make L=5 or L=10"?  I would
>>> submit that it makes more sense to leverage experience than it does
>>
>> to make things up.
>>>
>> +1
>>
>
> Yes, I agree that would be a great approach to take.
>
>
> So, we are saying it is fine to ignore L completely and simply increase
> cwnd by bytes_acked during slow start? And if this causes large bursts to
> be sent out (when an implementation doesn’t do pacing), that is fine?
>

Yes, I think that is the proposal on the table, and it sounds good to me.

A rationale would be:

(1) Implementations SHOULD pace (RFC 7661).

(2) Implementations that don't pace will generally be causing large bursts
for many different reasons anyway (data and/or ACK aggregation in the
network or end hosts), restart from idle,...) so having a constant L does
not provide enough protection from bursts to justify the cost in reduced
performance (in the form of slower slow-start). In support of this,
experience with this as the default behavior in Linux TCP over the
2013-2021 period suggests this works well enough in practice.

neal