> On Mar 19, 2019, at 08:10, Jonathan Morton <chromati...@gmail.com> wrote:
>
>> On 19 Mar, 2019, at 7:52 am, Greg White <g.wh...@cablelabs.com> wrote:
>>
>> L4S utilizes TCP Prague, which falls back to traditional congestion control
>> if the bottleneck link doesn't provide isolation.
>
> You see, this is the part I find difficult to believe that it will operate
> reliably. For a start, I have seen no detailed public description of TCP
> Prague, even though it has supposedly been in "open" development for so long.
> My most recent information is that it's essentially a slightly modified
> DCTCP.
>
> " It would take time for endpoints to distinguish classic and L4S ECN
> marking. An increase in queuing delay or in delay variation would be
> a tell-tale sign, but it is not yet clear where a line would be drawn
> between the two behaviours. "
IMHO this is caused by the fact that ECT(1) is simply not suitable as a
classifier, as it will only reliably classify unmarked packets, anything marked
CE will looses the destinction whether the flow considers itself L4S ready or
not. Could anyone point me to the section in the L4S RFCs that discusses this,
please?
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ has the following:
" Given shortage of codepoints, both L4S and classic ECN sides of
an AQM would have to use the same CE codepoint to indicate that
a packet had experienced congestion. If a packet that had
already been marked CE in an upstream buffer arrived at a
subsequent AQM, this AQM would then have to guess whether to
classify CE packets as L4S or classic ECN. Choosing the L4S
treatment would be a safer choice, because then a few classic
packets might arrive early, rather than a few L4S packets
arriving late;"
But how is the L4S queue actually maintaining its low latency if it just
admitted an non-L4S flow? This _might_ work if CE marked packets are rare, but
IMHO this confirms my assessment that ECT(1) is a terrible choice for a
classifier bit.
Best Regards
Sebastian
> Internet history is littered with failed attempts at implementing
> delay-sensitive TCPs. I can immediately think of several reasons why delay
> can and will vary for reasons other than the bottleneck not implementing an
> isolated queue (just ask the BBR devs). The mere presence of a wifi link on
> the path, even if it is never the bottleneck, would be a trivial and common
> example.
>
> So please explain (or point to good documentation) how TCP Prague robustly
> avoids misbehaving in a standard ECN environment, as is presently deployed.
>
>
> SCE explicitly does not rely on specific changes in behaviour by endpoints.
> It just provides a conduit of information from the network to the receiver,
> in addition to standard ECN behaviour. The receiver is free to ignore that
> information, without harming the network, and will naturally behave normally
> and safely when that information is absent. We have a proof-of-concept
> implementation (a trivial mod of sch_codel and sch_fq_codel) which
> successfully passes this information across the Internet and works with (is
> transparently ignored by) existing endpoints and middleboxes.
>
> In short, SCE is incrementally deployable by design.
>
> The broader system of feedback and modified congestion control, which I call
> ELR (Explicit Load Regulation) as an umbrella term, offers benefits which,
> yes, have not yet been proved - but which are straightforward in concept and
> should be amenable to analysis. It seems likely that some work from L4S can
> be used in this context.
>
> - Jonathan Morton
>
> _______________________________________________
> 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
