<div dir="ltr">+1<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 23, 2019 at 9:02 AM Roland Bless <<a href="mailto:roland.bless@kit.edu">roland.bless@kit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 22.03.19 at 19:28 Victor Hou wrote:<br>
<br>
> Broadcom has been deeply involved in developing the Low Latency DOCSIS<br>
> cable industry specification that Bob Briscoe mentioned.  We concur with<br>
> the L4S use of ECT(1).  L4S can be implemented either in a dual-queue or<br>
> an fq implementation. SCE cannot be implemented with a dual-queue<br>
> implementation; the only way to support it is with an fq<br>
> implementation.  An fq implementation is incompatible with the Low<br>
> Latency DOCSIS specification developed within the cable industry.<br>
<br>
I don't understand your rationale here.<br>
The basic SCE concept could be used for L4S as well.<br>
I suggest to use an additional DSCP to mark L4S packets.<br>
The L4S sender/receiver can simply react to the SCE<br>
markings the same way that they now react to CE, with<br>
the difference that it's safer to react to SCE, because<br>
the signal is unambiguous, whereas CE would be ambiguous<br>
(could be set by either classic AQM/ECN node or by<br>
an L4S node).<br>
<br>
Regards<br>
 Roland<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div>