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 wrote:
>
>
>
> > On 29 Nov 2018, at 13:52, Jonathan Morton wrote:
> >
> >> On 29 Nov, 2018, at 2:06 pm, Michael Welzl 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
