Re: [tcpm] Linux doesn’t implement RFC3465

With AD hat on,

If I understand the current document state correctly, the current ABC
guidance we have is

RFC3465 (Experimental): L=2
RFC5681 (PS): L=1

There are a few PS drafts floating around that use byte counting in some
form and would benefit from a standards-track reference in this case.

1. The most comprehensive solution would be a 3465bis PS doc that obsoletes
3465 and updates 5681 with L= Infinity, 8, or whatever number the group
decides on. If we agree this is the right thing to do and someone has the
energy to drop 3465bis-00, then let's do so to have a basis of discussion.

2. If there is no such energy, or there are contentious issues that will
draw out the process to get this to RFC, than I can initiate a review of
upgrading 3465 to PS directly. I think we all agree this would be an
improvement on the status quo, but isn't worth doing if 3465bis is going to
happen quickly.

3. There might be interest in a more generalized 5681bis, but my instinct
is that this is a bigger job that will delay the most urgently needed
update -- which is not to say that we shouldn't do that document too.

4. However, I don't think it would be too much of a stretch to rope in an
IW update (6928bis) in 3465bis, if it doesn't add too much time. It all
fits in with the general theme of the maximum allowable burst on the
internet in the absence of any sort of pacing (ack-driven or
stack-enforced).

The most useful thing right now would be for people to either (1) disagree
with any of my 4 points above or (2) or volunteer to write 3465bis-00.

Martin

On Tue, Aug 10, 2021 at 8:55 AM Mirja Kuehlewind <mirja.kuehlewind=
40ericsson.com@dmarc.ietf.org> wrote:

> 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 <tcpm-bounces@ietf.org> on behalf of Yuchung Cheng <ycheng=
> 40google.com@dmarc.ietf.org>
> *Date: *Monday, 9. August 2021 at 22:53
> *To: *Mark Allman <mallman@icir.org>
> *Cc: *Extensions <tcpm@ietf.org>
> *Subject: *Re: [tcpm] Linux doesn’t implement RFC3465
>
>
>
>
>
>
>
> On Mon, Aug 9, 2021 at 10:05 AM Mark Allman <mallman@icir.org> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>