[Cake] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft -

[Sebastian Moeller]

Dear Richard,

I am an interested layman here, so do not take my questions too seriously...

> On Mar 11, 2019, at 08:35, Richard Scheffenegger <rscheff at gmx.at> wrote:
> 
> 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?

	Given that l4s is not deployed, I would argue that until it is anything new will only need to play nice with what you call legacy flows (I would call them normal flows).

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

	But L4s, at least from a glance at draft-briscoe-tsvwg-l4s-arch-01 seems ti merit the unicorn-qualifier that Mikael used: since it seems to imply that the l4s path will not encounter drops just marks to achieve its goal of "keep[ing] congestion loss to zero". This probably is true for a rather strict definition of "congestion loss", but it flies into the face of the naive insight that once under sufficient load a router is going to drop packets to keep its queues under control, and if each flow uses up less of the queue (a worthy goal) it will just take more concurrent flow to push the router into the dropping regime, but that is a quantitative difference not a qualitative one. I guess this shows the lack of understanding from my side more than short-comings of l4s...

Best Regards
	Sebastian

> 
> 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 at swm.pp.se
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat