Re: [tcpm] Linux doesn’t implement RFC3465

[Vidhi Goel <[e-mail]>]

Thanks Martin for mentioning the different available options.

> If I understand the current document state correctly, the current ABC guidance we have is
> 
> RFC3465 (Experimental): L=2
> RFC5681 (PS): L=1

I want to note that the guidance in 3465 is a MUST while in 5681 is a RECOMMEND.

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

I created a GitHub repo https://github.com/goelvidhi/rfc3465-bis <https://github.com/goelvidhi/rfc3465-bis> with the current text of 3465. Neal and Yuchung have mentioned that they would be willing to contribute. (Neal, Yuchung, please correct me if I misunderstood).

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

I don’t think 3465 can be upgraded to PS as-is.

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

Yeah, it could delay the simpler and important update to 3465. I am ok with going either way - 5681-bis or 3465-bis whichever could likely make faster progress.

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

Personally, I like the structure of 6928 more than 3465. Is it possible to rope in ABC (3465) in a 6928bis and change the title - Would like to hear more from the authors of both the RFCs.

Thanks,
Vidhi

> On Aug 12, 2021, at 11:10 AM, Martin Duke <[e-mail]> wrote:
> 
> 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=[e-mail] <mailto:[e-mail]>> wrote:
> Sigcomm paper from 2015:
> 
>  
> 
> http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000002.pdf <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] <mailto:[e-mail]>> on behalf of Yuchung Cheng <ycheng=[e-mail] <mailto:[e-mail]>>
> Date: Monday, 9. August 2021 at 22:53
> To: Mark Allman <[e-mail] <mailto:[e-mail]>>
> Cc: Extensions <[e-mail] <mailto:[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
> 
> _______________________________________________
> tcpm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm