Re: [tsvwg] Consensus call on ECT(1)

[Mikael Abrahamsson <[e-mail]>]

I support 3.

I think I am mostly on Dave Tahts line.

I am still sceptical that L4S is safe together with other traffic on 
todays Internet. We have everything from very shallow buffered FIFO (L2 
switches) via various AQMs (both (non)flow aware, DSCP aware, future 
dual-Q etc) all the way up via deep buffered ones that might or might not 
support PIE/RED or something else, or just be stupid tail-drop ones. We 
have packet schedulers that might have hundreds of clients and vary the 
available bw becuase they're egressing on a variable speed medium (wifi 
with L1/L2 retransmits) inducing PDV on the flows etc.

This is an extremely complex environment. I'd like to see all these 
tested. I am sympathetic with L4S goals and if it can be shown that 
L4S-enabled flows can interop fairly well (doesn't have to be perfect) in 
all the above cases we have in the wild Internet today, then I am slightly 
leaning towards 1/ below. It would be great if we could have a scenario 
where we safely could migrate to the kind of dual-Q scheduling with 
support for low-latency that L4S envisions.

Some claim that a lot of scheduling on the Internet today is flow aware. 
My experience is quite the opposite. If I look at what's deployed, most of 
the time it's more or less stupid FIFO, if it's good then it's got limited 
queue depth and not seconds of buffering. Looking at the typical kind of 
devices that do speed conversion today, it's not going to be flow aware. 
Residential gateways, BNGs, wifi routers/APs etc. None of these typically 
does FQ. So for me to support L4S and ECT(1) as input signal, I'd like to 
see more test results for *all* these deployed "schedulers" with 
simulations of lots of different traffic mixes, lots of flows, low number 
of flows, asymmetric scenarios with dual-q one direction and not the 
other. Simulating queue stalls due to wifi output "stall" for ~100ms, what 
does this result in? 10ms?

I see so far very idealistic testing trying to test what will happen in a 
complex world. I see this decision a going to with us for decades, so I'd 
like to make sure we understand it properly.

On Mon, 4 May 2020, Wesley Eddy wrote:

> **
>
> *In this email thread, please state, concisely, which of the following 
> viewpoints on ECT(1) you prefer. Please have extended discussion in a 
> different thread. If you are uncomfortable sharing your opinion on the list, 
> you may email the tsvwg chairs directly ([e-mail]). *
>
> *
>
> If you did not attend the 27 April interim, please watch the meeting video 
> [https://www.youtube.com/watch?v=dw3YKyeFxQU] for context on this question.
>
>
> 1.
>
>   I support using ECT(1) as an input signal to the network. This is
>   the approach consistent with the current L4S drafts. This position
>   does not mean that there are no remaining issues with L4S, but that
>   the remaining issues can be resolved by continued WG effort on the
>   current drafts.
>
> 2.
>
>   I support using ECT(1) as an output signal from the network. This is
>   consistent with SCE. If you believe L4S will not be safe for the
>   internet without significant architectural changes, you are in this
>   group.
>
> 3.
>
>   There is a specific test or tests I need to see before making a
>   decision about ECT(1). Please be specific about the tests in your
>   response.
>
>
> Please submit your opinion by 5/18/2020.
>
> *
>
>

-- 
Mikael Abrahamsson    email: [e-mail]