Re: [tcpm] Linux doesn’t implement RFC3465

[Yuchung Cheng <[e-mail]>]

On Mon, Aug 2, 2021 at 4:18 PM Neal Cardwell <[e-mail]> wrote:

>
>
> 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.
>
One simple example is:

Let's consider a sender receiving
1. one stretch ACK acking 100 packets due to ACK decimation
vs
2. 50 ACKs each acking 2 MSS within 0.1ms due to ACK compression

(2) still forms a sizable burst even with ACK clocking due to timing
compression.


>
> neal
>
>
>