I have to admit after reviewing the tattered mess of the l4s stuff, and the ongoing work in the tsvwg like the 40+ pager for dual queue
https://datatracker.ietf.org/wg/tsvwg/documents/ the non-proposals here: https://datatracker.ietf.org/wg/l4s/documents/ that I'm finally inclined to make a go of jonathan's proposal for "some congestion experienced", as an incremental, backward compatible mechanism for the existing AQM deployments to provide an earlier signal than CE. Pluses are - 1 line of code to codel/fq_codel, basically replacing CE_THRESHOLD, easy to add to RTP/QUIC and other transports, transparent to all implementations I'm aware of (they should just ignore the change) a minus is retrofitting it to TCPs - as this is basically a receiver side optimization - is hard. On Thu, Nov 29, 2018 at 11:54 PM Michael Welzl <mich...@ifi.uio.no> wrote: > > > > > On 29 Nov 2018, at 13:52, Jonathan Morton <chromati...@gmail.com> wrote: > > > >> On 29 Nov, 2018, at 2:06 pm, Michael Welzl <mich...@ifi.uio.no> wrote: > >> > >>> That's my proposal. > >> > >> - and it's an interesting one. Indeed, I wasn't aware that you're thinking > >> of a DCTCP-style signal from a string of packets. > >> > >> Of course, this is hard to get right - there are many possible flavours to > >> ideas like this ... but yes, interesting! > > > > I'm glad you think so. Working title is ELR - Explicit Load Regulation. > > > > As noted, this needs standardisation effort, which is a bit outside my > > realm of experience - Cake was a great success, but relied entirely on > > exploiting existing standards to their logical conclusions. I think I > > started writing some material to put in an I-D, but got distracted by > > something more urgent. > > Well - "interesting" is one thing, "better than current proposals" is > another... I guess this needs lots of evaluations before going anywhere. > > > > If there's an opportunity to coordinate with relevant people from similar > > efforts, so much the better. I wonder, for example, whether the DCTCP > > folks would be open to supporting a more deployable version of their idea, > > or whether that would be a political non-starter for them. > > I'm not convinced (and I strongly doubt that they would be) that this would > indeed be more deployable; your idea also includes TCP option changes, which > have their own deployment trouble... the L4S effort, to me, sounds "easier" > to deploy (which is not to say that it's easy to deploy at all; though I did > like a recent conversation on possibly deploying it with a PEP... that > sounded quite doable to me). > > Cheers, > Michael > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
