Re: [Ecn-sane] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft -

["Richard Scheffenegger" <rscheff@gmx.at>]

I can remember reading quite a few papers where a similar scheme for ect(1) was adopted - often with additional changes on both ends to make use of this signal. Including schemes that encoded complex information in the stream of ect0/ect1...

Where can one find simulations of the interaction between legacy and l4s flows when using this?

I think the l4s use of dctcp, to allow coupled queue selection based on the transports expectations, is a more useful case for ect(1)

Richard

Gesendet mit der GMX iPhone App

Am 11.03.19 um 08:08 schrieb Mikael Abrahamsson

> On Sun, 10 Mar 2019, Jonathan Morton wrote:
> 
> > An interesting idea, but SCE marks will appear even when there's a lot 
> > of congestion (at high rates, ie. probably every packet that doesn't 
> > carry CE), as well as showing up at low frequency when the level of 
> > congestion only warrants reducing the growth rate.  I think the word 
> > "Some" is sufficiently descriptive, while "Slight" might cause people to 
> > ignore it completely.
> 
> One way to handle this would be "buffering experienced" or something like 
> that. Ie if this packet is being enqueued into a buffer with non-trivial 
> number of packets in it, mark it.
> 
> The L4S proposal also has the property that their use of this last code 
> point combination in the entire packet header (and this is a big thing, 
> this is the last unicorn) also meant the packet was allowed to be 
> re-ordered. I thought this was a big and nice thing, for other areas. This 
> new proposal removes that property.
> 
> From what I can see, L4S actually is quite novel and has the chance to 
> seriously change the way queueing is done. This proposal seems more like 
> "a little more of what we had before" which I do not think warrants 
> claiming this last unicorn codepoint. I'd like its use to be truly novel 
> and be more than a tweak.
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat