Re: [Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

[Dave Taht <dave.taht@gmail.com>]

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 <michawe@ifi.uio.no> wrote:
>
>
>
> > On 29 Nov 2018, at 13:52, Jonathan Morton <chromatix99@gmail.com> wrote:
> >
> >> On 29 Nov, 2018, at 2:06 pm, Michael Welzl <michawe@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