[Ecn-sane] [tsvwg] Comments on L4S drafts

[Dave Taht]

Sebastian Moeller <moeller0 at gmx.de> writes:

> Hi Jonathan,
>
>
>
>> On Jul 19, 2019, at 22:44, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> 
>>> On 19 Jul, 2019, at 4:06 pm, Black, David <David.Black at dell.com> wrote:
>>> 
>>> To be clear on what I have in mind:
>>> 	o Unacceptable: All traffic marked with ECT(1) goes into the L4S queue, independent of what DSCP it is marked with.
>>> 	o Acceptable: There's an operator-configurable list of DSCPs
>>> that support an L4S service - traffic marked with ECT(1) goes into
>>> the L4S queue if and only if that traffic is also marked with a
>>> DSCP that is on the operator's DSCPs-for-L4S list.
>> 
>> I take it, in the latter case, that this increases the cases in
>> which L4S endpoints would need to detect that they are not receiving
>> L4S signals, but RFC-3168 signals.  The current lack of such a
>> mechanism therefore remains concerning.  For comparison, SCE
>> inherently retains such a mechanism by putting the RFC-3168 and
>> high-fidelity signals on different ECN codepoints.
>> 
>> So I'm pleased to hear that the L4S team will be at the hackathon
>> with a demo setup.  Hopefully we will be able to obtain comparative
>> test results, using the same test scripts as we use on SCE, and also
>> insert an RFC-3168 single queue AQM into their network to
>> demonstrate what actually happens in that case.  I think that the
>> results will be illuminating for all concerned.
>
> 	What I really would like to see, how L4S endpoints will deal
> with post-bottleneck ingress shaping by an RFC3168 -compliant
> FQ-AQM. I know the experts here deems this not even a theoretical
> concern, but I really really want to see data, that L4S flows will not
> crowd out the more reactive RFC3168 flows in that situation. This is
> the set-up quite a number of latency sensitive end-users actually use
> to "debloat" the internet and it would be nice to have real data
> showing that this is not a concern.

+10

>
> Best Regards
> 	Sebastian
>
>
>
>> 
>> - Jonathan Morton
>> _______________________________________________
>> Ecn-sane mailing list
>> Ecn-sane at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/ecn-sane