Re: [tcpm] Linux doesn’t implement RFC3465

[Mirja Kuehlewind <[e-mail]>]

Sigcomm paper from 2015:

http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000002.pdf

They’ve observed 11-22% of connections with stretched ACKs, ack’ing mostly up to 6 packets….



From: tcpm <[e-mail]> on behalf of Yuchung Cheng <ycheng=[e-mail]>
Date: Monday, 9. August 2021 at 22:53
To: Mark Allman <[e-mail]>
Cc: Extensions <[e-mail]>
Subject: Re: [tcpm] Linux doesn’t implement RFC3465



On Mon, Aug 9, 2021 at 10:05 AM Mark Allman <[e-mail]<mailto:[e-mail]>> wrote:

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

I think at some point someone should put some meat on the bones of
"suggests this works well enough in practice".
Good point. We could add anecdotal words on the degree of stretched ACK.

Maybe we can also cite priori discussions on ACK compression / decimation a couple years ago in tcpm / tsvwg. Are there research papers on stretch ACK degrees too?


It isn't enough for linux to have implemented this.  Or, even had it
turned on.  E.g., if L=\infinity yet receivers ACK every other
packet then there is an effective L of 2.  We see lots of people
saying this scenario isn't the prevalent scenario these days.  If
that's true then it should be easy to provide a summary of
experience with L=\infinity.

This would all just seem better with some concrete experience rather
than the quite hand wavy statements we've seen so far.

allman