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