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

[Bob Briscoe <[e-mail]>]

I support using ECT(1) as an input.

My reasoning: we have a dilemma:

1. Without a second input state, there is no way to isolate scalable 
(low latency) from existing traffic, without using other classifiers 
such as flow IDs or DSCPs. Using either would consign the ultra-low 
latency of scalable congestion control to a minority niche {Note 1}, 
rather than for all applications, over all types of network.

2. Without an additional output state, we only have a fallable heuristic 
way for scalable and classic flows to share any single-queue RFC3168 
bottlenecks.

We have to choose the least worst.

* Lack of an extra input state (#1) would be a problem for ever.
* Lack of an extra output state (#2) is a potential problem for 
transition. That's not ideal, but it's not strictly unsafe {Note 2}. 
Also no-one is even sure that there are (or will be) significant 
deployments of single-queue RFC3168 bottlenecks to transition from.

Regards



Bob

{Note 1} Using Flow IDs violates layering, so cannot be used in settings 
like mobile or VPNs. Using a DSCP would consign ultra-low latency to 
hosts connected to the same ISP.

{Note 2} During transition, even if the heuristic fails to detect a 
single-queue RFC3168 bottleneck, a long-running classic flow will 
progress more slowly (typically 1/6, worst-case 1/16), but it will not 
starve. That is unfortunate, but not unsafe. That already happens on the 
Internet, and it's rarely noticeable.



On 04/05/2020 19:15, 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.
>
> *

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/