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

From: Wesley Eddy <[email-masked]>
Date: Mon, 4 May 2020 14:15:07 -0400

**

*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 ([email-masked]). *

*

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.

*

---

From: Greg White <[email-masked]>
Date: Mon, 4 May 2020 20:39:00 +0000

I support using ECT(1) as an input (Option 1).

From: tsvwg <[email-masked]> on behalf of Wesley Eddy <[email-masked]>
Date: Monday, May 4, 2020 at 12:15 PM
To: "[email-masked]" <[email-masked]>
Subject: [tsvwg] Consensus call on ECT(1)

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 ([email-masked]<mailto:[email-masked]>).

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.

2.

3.    I support using ECT(1) as an input

4.     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.
5.
6.

7.

8.    I support using ECT(1) as an output

9.     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.
10.
11.

12.

13.  There is a specific test or tests

14.   I need to see before making a decision about ECT(1). Please be specific about the tests in your response.
15.

Please

submit your opinion by 5/18/2020.

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 5 May 2020 02:33:48 +0300

> 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 ([email-masked]). 
> 
> 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.
> 
> 	• 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.
> 	• 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.
> 	• 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.

I support Option 2: using ECT(1) as an output signal.  I believe that the L4S design is unsafe.

 - Jonathan Morton

---

From: Steven Blake <[email-masked]>
Date: Mon, 04 May 2020 21:54:48 -0400

On Mon, 2020-05-04 at 14:15 -0400, Wesley Eddy wrote:
>     
>         
> In this email thread, please state, concisely, which of the following
> different thread. If you are uncomfortable sharing your opinion on
> the list, you may email the tsvwg chairs directly (
> [email-masked]). 
> 
>         
> 
>         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.
> 
>         
> 
>         
>           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.
>           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.
>           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.
>         
>         
> 

I support preserving ECT(1) for future potential use as a congestion
control *output signal* from the network (my interpretation of option
2), once one or more sufficiently vetted proposals are ready for multi-
domain experimentation.

I *do not* support the use of ECT(1) as a queue selector *input signal*
to the network. There already exists an architected, implemented, and
deployed mechanism in IP to unambiguously steer packets into PHB
queues.

I have concerns about redefining the semantics of CE markings (in terms
of the expected transport protocol rate reduction) if deployed in the
general Internet (instead of in controlled domains e.g., datacenters).
Any proposal to change CE semantics would need to demonstrate robust
detection of and response to RFC 3168-compliant ECN implementations in
real HW on real network paths with realistic propagation delays.

Regards,

// Steve

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 5 May 2020 10:11:26 +0200

Dear Wes,

> On May 4, 2020, at 20:15, Wesley Eddy <[email-masked]> wrote:
> 

POSITION: 
	I support using ECT(1) as an output signal from the network.

RATIONALE: 
	The L4S data so far demonstrates that even after 4+ years in the effort none of the technical challenges from using ETC(1) as input have robust and reliable solutions yet.
	With the designated reference  transport protocol TCP Prague still work-in-progress (case in point the much promised paced chirping has yet to make it into TCP Prague) all the testing done with DCTCP is essentially needs to be repeated, as it is the properties of the final implementation that need to be vetted. That will only be possible after TCP Prague will have reached a certain level of maturity and only then one potentially can make the point that ECT(1) as input actually can work reliably and robustly with acceptable side-effects. 
	Since ECT(1) as output by design has far fewer side-effects and none of the issues of cramming a function requiring 1 bit into one codepoint, I see ECT(1) as output as a better way to invest the remaining ECN code-point to get high-fidelity 1/p type congestion signaling into the wider internet in an evolutionary fashion that has a realistic chance of succeeding.
	ETC(1) as output also is not incompatible with L4S' requirement of a 1/p type congestion signal, so will in itself not make L4S impossible; granted L4S will need  to use another classifier, be it DSCP or a new protocol number, to steer traffic to its respective matching congestion controller, but I see this as an improvement of the L4S design.

Best Regards
	Sebastian

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 5 May 2020 09:30:14 +0100

I support using ECT(1) as an output signal from the network
(option 2).
-- 
Jeremy

---

From: "Smith, Kevin, Vodafone Group" <[email-masked]>
Date: Tue, 5 May 2020 09:10:29 +0000

Hi,

I support option 1, ECT(1) as an input signal to the network.

All best,
Kevin

> Message: 2
> Date: Mon, 4 May 2020 14:15:07 -0400
> From: Wesley Eddy <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> **
>
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 ([email-masked]). *
>
> *
>
> 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.
>

C2 General

---

From: Roland Bless <[email-masked]>
Date: Tue, 5 May 2020 11:38:44 +0200

Hi,

* I support using ECT(1) as an output signal from the network.

Having better feedback (more fine grained congestion signal)
from the network is really valuable in various contexts.
ECT(1) could be used as output for various different approaches,
not just L4S. I believe that a DSCP can be used as input signal
for L4S instead.

Regards,
 Roland

---

From: Neal Cardwell <[email-masked]>
Date: Tue, 5 May 2020 07:47:31 -0400

I support using ECT(1) as an input signal to the network. (Option 1).

best regards,
neal

On Mon, May 4, 2020 at 4:39 PM Greg White <[email-masked]> wrote:
> 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 ([email-masked]).
>
>
>
> If
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 5 May 2020 12:19:05 +0000

I support option 1: ECT(1) as an input signal.

There has been a lot of work on L4S and this is the most promising approach for me to transition to a better network service and use of ECT(1) as an input signal seems the most promising deployment path.

From: tsvwg <[email-masked]> on behalf of Wesley Eddy <[email-masked]>
Date: Monday, 4. May 2020 at 20:15
To: "[email-masked]" <[email-masked]>
Subject: [tsvwg] Consensus call on ECT(1)

In

If

1.

2.

7.

12.

Please

---

From: Anders Bloom <[email-masked]>
Date: Tue, 5 May 2020 12:42:58 +0000

Hi,

Kind regards //

Anders Bloom
Senior Systems Architect Broadband
TechOps, Broadband HFC
Tele2 Sverige AB
Box 62/Torshamnsgatan 17, 164 94 Kista​​
+46 709 265 179
www.tele2.se

Från: tsvwg <[email-masked]> på uppdrag av Wesley Eddy <[email-masked]>
Datum: måndag 4 maj 2020 20:15
Till: "[email-masked]" <[email-masked]>
Ämne: [tsvwg] Consensus call on ECT(1)

In

If

you did not attend the 27 April interim, please watch the meeting video [https://www.youtube.com/watch?v=dw3YKyeFxQU<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Ddw3YKyeFxQU&data=02%7C01%7Canders.bloom%40tele2.com%7C7c349f5406284a2fa8e408d7f057238e%7C76431109ff8942c28781a07ca07a2d57%7C0%7C0%7C637242129365730914&sdata=Ik22RZcIl5neJXxJdm0fS1%2FA%2FhJBqLuvb0PNjWt%2B1Zc%3D&reserved=0>]

  1.
  2.

Please

******** IMPORTANT NOTICE ********
The content of this e-mail is intended for the addressee(s) only and may contain information that is confidential and/or otherwise protected from disclosure. If you are not the intended recipient, please note that any copying, distribution or any other use or dissemination of the information contained in this e-mail (and its attachments) is strictly prohibited. If you have received this e-mail in error, kindly notify the sender immediately by replying to this e-mail and delete the e-mail and any copies thereof.

Tele2 AB (publ) and its subsidiaries (“Tele2 Group”) accepts no responsibility for the consequences of any viruses, corruption or other interference transmitted by e-mail.

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 05 May 2020 08:52:14 -0700

I support using ECT(1) as an input signal (option 1).

Thanks,
Tommy

> On May 4, 2020, at 11:15 AM, Wesley Eddy <[email-masked]> 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 ([email-masked] <mailto:[email-masked]>). 
> 
> If you did not attend the 27 April interim, please watch the meeting video [https://www.youtube.com/watch?v=dw3YKyeFxQU <https://www.youtube.com/watch?v=dw3YKyeFxQU>] for context on this question.
> 
> 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.
> 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.
> 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.
>

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 5 May 2020 17:41:43 +0000

Regards,
Koen.

From: tsvwg <[email-masked]> On Behalf Of Wesley Eddy
Sent: Monday, May 4, 2020 8:15 PM
To: [email-masked]
Subject: [tsvwg] Consensus call on ECT(1)

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 ([email-masked]<mailto:[email-masked]>).

  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.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 5 May 2020 11:56:30 -0700

On Mon, May 4, 2020 at 11:15 AM Wesley Eddy <[email-masked]> wrote:

> list, you may email the tsvwg chairs directly ([email-masked]
> <[email-masked]>). *
>
>
>
>
>
> * If you did not attend the 27 April interim, please watch the meeting
> video [https://www.youtube.com/watch?v=dw3YKyeFxQU
> <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.*
>

After an examination of the evidence, I am not convinced that L4S can be
made safe for the Internet without significant architectural changes, so
that puts me squarely in group 2: use ECT(1) as an output signal from the
network.

What drives me to this conclusion is the need for L4S endpoints to
implement heuristics to detect classic ECN bottlenecks and fall-back to
using the RFC 3168 interpretation of CE markings. The evidence that I have
seen does not give me confidence that it is possible to make this reliable.

Mike Heard

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 5 May 2020 17:27:12 -0700

Support Option-1 i.e.,  ECT(1) as an input signal to the network and
remaining issues need to be worked out here.

FWIW:
There is real need for this work and it can ease things from best-effort
queues. While I don't claim to understand all other implications of various
CC stuff on this, IMO  this is better than mapping it to DSCP code points
(which has only limited options when its mapped to TC bits in some
environments).

--
Uma C.

On Mon, May 4, 2020 at 11:15 AM Wesley Eddy <[email-masked]> wrote:

> submit your opinion by 5/18/2020. *
>
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 6 May 2020 08:53:47 -0400

I support using ECT(1) as output, but that doesn't really capture my
thoughts on the issue at hand.

In accordance with the chairs' ask, I will post my thoughts in a new thread.

---

From: "Black, David" <[email-masked]>
Date: Fri, 8 May 2020 19:00:20 +0000

> After an examination of the evidence, I am not convinced that L4S can be made safe for the Internet without significant architectural changes,
> so that puts me squarely in group 2: use ECT(1) as an output signal from the network.
>
> What drives me to this conclusion is the need for L4S endpoints to implement heuristics to detect classic ECN bottlenecks and fall-back to using
> the RFC 3168 interpretation of CE markings. The evidence that I have seen does not give me confidence that it is possible to make this reliable.

+1 as an individual – I’m also squarely in group 2 for the same reason, and will send a longer explanation in a separate message.

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of C. M. Heard
Sent: Tuesday, May 5, 2020 2:57 PM
To: Wesley Eddy
Cc: TSVWG
Subject: Re: [tsvwg] Consensus call on ECT(1)

[EXTERNAL EMAIL]
On Mon, May 4, 2020 at 11:15 AM Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:

After an examination of the evidence, I am not convinced that L4S can be made safe for the Internet without significant architectural changes, so that puts me squarely in group 2: use ECT(1) as an output signal from the network.

What drives me to this conclusion is the need for L4S endpoints to implement heuristics to detect classic ECN bottlenecks and fall-back to using the RFC 3168 interpretation of CE markings. The evidence that I have seen does not give me confidence that it is possible to make this reliable.

Mike Heard

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 8 May 2020 20:08:40 +0000

I am also squarely in group 2:  I don't think L4S can be made safe 
without significant architectural changes.

However, I currently support ECT(1) as input, with an important
qualifier.

The qualifier is that my position is contingent on a specific suggestion
for a significant architectural change to L4S that I currently believe
makes it possible to use ECT(1) as an input safely.  (If the suggestion
turns out to be unsupportable for some reason, I revert to my previously
expressed preference for ECT(1) as output, with DSCP as the L4S
classifier.)

I regret to say that I was unable to make it concise, so I've written up
a more detailed description in a separate email:
https://mailarchive.ietf.org/arch/msg/tsvwg/vW8eEt7V58SWPoLIJ5dklCG4WqM/

HTH.

-Jake

---

From: "Ozer, Sebnem" <[email-masked]>
Date: Fri, 8 May 2020 21:54:08 +0000

Hi All,

I support option 1.

Thanks,
Sebnem Ozer
Comcast

From: tsvwg <[email-masked]> On Behalf Of Wesley Eddy
Sent: Monday, May 4, 2020 2:15 PM
To: [email-masked]
Subject: [tsvwg] Consensus call on ECT(1)

If you did not attend the 27 April interim, please watch the meeting video [https://www.youtube.com/watch?v=dw3YKyeFxQU<https://urldefense.com/v3/__https:/www.youtube.com/watch?v=dw3YKyeFxQU__;!!CQl3mcHX2A!QRzgyPE5ColHdJ1V081XThUXRsVbXCEVtxJXq1if8tY_Ly93j53UKPB0UnaOfubI67E$>] for context on this question.

---

From: Dave Taht <[email-masked]>
Date: Sat, 9 May 2020 11:29:27 -0700

It seems like the vast majority of participants have missed on
answering this question, so I assume, for most,
the answer to this question is "no."?

Perhaps a separate question on just that, on another thread, would be
productive? Like this one?

"Please be specific about the tests in your response."

I have a very, very long list, here, myself, starting with detailed
analysis of bidirectional asymmetric bandwidth (e.g 1gig/35mbit)
traffic, (rrul test + other traffic anyone?)...

now extending well past all the work items on tsvwg and the ecn-sane
worklist and with new factors exposed by the extensive testing thus
far, like jitter sensitivity and ack-filtering, and tunneling and
configuration issues... which will take a while to assemble more
fully.

but: I'm still looking over tons of data from both sides, very happy
to see less buggy, running code and repeatable tests, and I don't plan
to make a statement
on the rest of the ect(1) question until 5/16 or so at the earliest.

So... does anyone else have tests they'd like to propose?

PS Anyone taking apart the misconfigured ecn + bbrv1 data yet from
dropbox? I could use some help on that...

--
"For a successful technology, reality must take precedence over public
relations... because mother nature cannot be fooled." -- richard
feynman

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

---

From: "Ranganathan, Ram" <[email-masked]>
Date: Sun, 10 May 2020 23:09:30 +0000

I support Option 1 – ECT(1) as input. I believe the classification and treatment of low latency traffic, in a generic manner, is very important for future evolution of applications – and it is not specific to DOCSIS or wireless technologies alone. Ability of network elements to adapt quickly to congestion and maintain very low latency queues is imperative for URLLC style applications. I believe that continued work on improving any L4S weaknesses to avoid impact on classic/Cubic traffic will assist in making this a viable option and mitigate any currently existing weaknesses.

Ram Ranganathan
CommScope

From: tsvwg <[email-masked]> on behalf of Wesley Eddy <[email-masked]>
Date: Monday, May 4, 2020 at 2:15 PM
To: "[email-masked]" <[email-masked]>
Subject: [tsvwg] Consensus call on ECT(1)

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 opin
External ([email-masked]<mailto:[email-masked]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2lhbi53aGVlbG9ja0Bjb21tc2NvcGUuY29tLzA2MzM3NjY0ZjQ2MmVlZTMyODU5MzI1N2ZmZjExNThmLzE1ODg2MTYxMzAuMA==#key=c7a5ff4b8fef1435341ea264eb77da86>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

In

If

  1.
  2.  I
  3.  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
  4.  on the current drafts.
  5.
  6.
  7.  I
  8.  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.
  9.
  10.
  11. There
  12. 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.
  13.

Please

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 May 2020 03:23:25 +0000

i've been following this mailing list since the recent interrim videochat. my 
thoughts and prayers go out to the WG chairs who tried very hard to boil the 
directional census down to a single issue, network input or network output of 
the remaining IP TOS bit. this search for the essence of the matter lasted the 
usual couple of days before the community of people whose views are more 
nuanced began to re-describe or in some cases re-litigate those nuances. this 
brought everything else the WG chairs were hoping to keep briefly off the 
table, back onto the table. i've carefully observed the ebbs and flows of the 
resulting pandemonium, noting that there is more than one argument occuring 
here, and therefore more than one side for someone to be on. the WG chairs are 
trying to make water and dirt out of mud, and the mud isn't cooperating. i'd 
like to improve the situation somehow, or at worst not degrade it further. my 
advice is as follows.

first, remember why we have a WG and why that WG has chairs. we won't progress 
toward a livable goal for ourselves and our descendants without coherence in 
our method of identifying and reaching consensus. the WG chairs asked a 
question having at most one answer out of at most two alternatives. if this 
was the wrong question, tell them so and tell them why. note that you may end 
up volunteering to help them, and you may prefer your former life that did not 
have a bag of puppies in it. but, don't bypass the WG chairs. either answer 
their question or challenge it, don't ignore what they're trying to do.

second, remember IEN 145, from 1980.

> "XIII. CONGESTION CONTROL
> 
> Dave Clark discussed some studies about what to do when a Source
> Quench message arrives. A simulation program was used to try various
> methods. All were bad. The delay in the feedback loop is quite
> large and some information needs to be supplied about how far away
> (in time) the bottleneck is."

in this context RED made sense in its day compared to always-head and always-
tail drops, simply because it would look more like "line noise" common in the  
telecommunications circuits of the day. the guidance of RED was don't try to 
act smarter than you actually are, find a response that mimics something else 
that the system already deals with. the community has been trying since RED to 
add intelligence, and that's a worthy goal. but in the words of IEN 145, "all 
were bad", or else we would not be looking at queue management behaviour now, 
with an eye toward new signalling, new state, and new complexity.

third, remember MPLS. at first, MPLS networks appeared to IP as a single "hop" 
which drastically shortened one's "traceroute" results and made diagnostics 
harder. modern MPLS routers now violate the layering, decrementing the IP TTL 
and generating an ICMP message if IP TTL goes to zero. MPLS both is and 
simultaneously is not an underlay network for IP, and its costs are higher and 
its benefits lower as a result of having one foot in each layer. many IP 
routers lack a hardware fast-path for generating ICMP messages, and so the 
quality of this signal, especially in its time measurement and timeliness, is 
nowhere near the quality of the forwarding operation. we ought to think very 
carefully before asking intermediate system gateways to use their CPU for any 
operation which requires fidelity and which might have to scale.

fourth, remember security. if there's an unauthenticated signal which can be 
used to change behaviour at a distance in a way that could interfere with the 
operations of second or third parties, then that signal will be used in that 
way. it's not a probability, but a certainty. therefore we should design any 
such signal/response logic with the idea that it will be forged most of the 
time it's used, and decide whether it would still be worth having once that 
equilibrium is reached. if you give me a way to rain ICMP down on a victim as 
part of a spoofed-source DDoS, it will be used. if you give me a way to get my 
packets into the "internet fast lane" you can bet that will become ubiquitous 
for traffic you did not think needed low latency. if you can't harden it, 
don't do it.

fifth, get consensus on a problem statement before trying to get consensus on 
whether to assign some bit an input purpose or an output purpose. i am for 
example not onboard with more complexity. every congestion avoidance goal i 
have would be met if fq_codel were ubiquitous and buffers were rigorously and 
universally de-bloated. i share a comcast business fiber connection between 
zoom-et-al, youtube-et-al, ssh and other interactive tools, and online 
backups. when i do have a problem it's either because of a DDoS here or 
elsewhere, or because of unfixed buffer bloat.

my position should be predictable based on those five recommendations. try not 
to add state or complexity to the routing system. if you must do so, then ask 
intermediate system gateways to respond to new signals but do not ask them to 
generate new signals, and be aware that some IP substratums won't do either. 
but before you do either, get consensus on why more complexity is needed at 
all, and then exclude from dispositive consensus calls such as input-vs-output 
anyone who didn't join the consensus on the problem statement -- because most 
will lack the herculean strength needed to remain on-topic.

to all of you, thanks for reading this far, and for caring so much about the 
internet that you've chosen to study and measure and improve it in ways that 
are on-topic for this WG. i hope to meet some of you some post-pandemic day.

vixie

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 May 2020 16:37:29 +0100

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:
> video [https://www.youtube.com/watch?v=dw3YKyeFxQU] for context on 
> this question.
>
>
> 1.
>
>     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.
>

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

---

From: Adi Masputra <[email-masked]>
Date: Mon, 11 May 2020 17:12:26 -0700

I support option 1: using ECT(1) as an input signal.

Adi

> On May 4, 2020, at 11:15, Wesley Eddy <[email-masked]> wrote:
>

---

From: Asad Sajjad Ahmed <[email-masked]>
Date: Tue, 12 May 2020 02:32:42 +0200

I support ECT(1) as an input to the network (option 1).

Asad

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 11 May 2020 17:49:49 -0700

I support using ECT(1) as an input to the network.

Christoph

On 04/05/20 - 14:15:07, Wesley Eddy wrote:
> different thread. If you are uncomfortable sharing your opinion on the list,
> you may email the tsvwg chairs directly ([email-masked]). *
> 
> *
> 
> [https://www.youtube.com/watch?v=dw3YKyeFxQU] for context on this question.
> 
> 
> 1.
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 12 May 2020 16:30:35 +0200

Count me in camp 1 (an input signal into the network, while retaining
the ECT0 / ECT1 semantics of RFC3168 as an output).

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 May 2020 18:39:28 +0300

> I support using ECT(1) as an input signal to the network. (Option 1).

+1

Lars

---

From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 12 May 2020 15:57:34 +0000

Best,
Olivier

 > -----Original Message-----
 > From: tsvwg <[email-masked]> On Behalf Of Lars Eggert
 > Sent: Tuesday, May 12, 2020 5:39 PM
 > Cc: [email-masked]
 > On 2020-5-5, at 14:47, Neal Cardwell
 > <ncardwell=[email-masked]> wrote:

---

From: Andreas Petlund <[email-masked]>
Date: Tue, 12 May 2020 21:20:41 +0200

I support option 1) - using ECT(1) as an input signal to the network. 

Regards,
Andreas P.

> 4. mai 2020 kl. 20:15 skrev Wesley Eddy <[email-masked]>:
>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 12 May 2020 20:00:27 -0700 (PDT)

But pragmatically I must object to the boxs you have force us
to limit our selection to.  Especially given the direct association
of making this an L4S vs SCE "vote" by the qualifying conditions
attatched to options 1 and 2.

-- 
Rod Grimes                                                 [email-masked]

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 May 2020 23:14:16 -0700

(I've explained my position during the interim so not doing it again. I'm
happy to do it over email if the chairs need it.)

---

From: Joakim Misund <[email-masked]>
Date: Wed, 13 May 2020 08:46:33 +0200

Regards,
Joakim

---

From: Pete Heist <[email-masked]>
Date: Wed, 13 May 2020 13:41:50 +0200

I support option 2: using ECT(1) as an output signal, and will provide justification in a separate thread.

> On May 4, 2020, at 8:15 PM, Wesley Eddy <[email-masked]> wrote:
> 
>

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 13 May 2020 20:44:29 -0700

On 4 May 2020, at 11:15, Wesley Eddy <[email-masked]> wrote:

> In this email thread, please state, concisely, which of the following viewpoints on ECT(1) you prefer.

I support option 1, using ECT(1) as an *input* signal to the network.

We need an input signal to the network because it allows the sender to signal to the network that it it is able to gracefully handle (and indeed, benefit from) ultra-shallow network queues. It also serves as a commitment by the sender not to abuse that shallow queue by bloating it (under pain of severe penalty if caught doing that by a stochastic traffic policer). Without an input signal to communicate the source’s request for the shallower queue (and acceptance of the corresponding consequences if caught cheating) the network can’t know to which traffic it can safely apply the stricter policy.

Stuart Cheshire

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 14 May 2020 09:36:30 +0200

Hi Stuart,

I have a question about your rationale below.

> On May 14, 2020, at 05:44, Stuart Cheshire <cheshire=[email-masked]> wrote:
> 

	[SM] The L4S RFCs make it explicitly clear, that no such "stochastic traffic policer" will be mandated (or maybe not even needed). In an earlier discussions here on the mailing list I got the impression that even the idea of mandating even just the implementation (let alone default activation) of such a monitoring and enforcement was rejected. The official L4S position seems to be that the shallowness of the LL-queue alone would be sufficient to act as disincentive against abuse.

From https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-06:

"8.1.  Traffic (Non-)Policing

   Because the L4S service can serve all traffic that is using the
   capacity of a link, it should not be necessary to police access to
   the L4S service.  In contrast, Diffserv only works if some packets
   get less favourable treatment than others.  So Diffserv has to use
   traffic rate policers to limit how much traffic can be favoured.  In
   turn, traffic policers require traffic contracts between users and
   networks as well as pairwise between networks.  Because L4S will lack
   all this management complexity, it is more likely to work end-to-end.

[...]
8.2.  'Latency Friendliness'

   Like the Classic service, the L4S service relies on self-constraint -
   limiting rate in response to congestion.  In addition, the L4S
   service requires self-constraint in terms of limiting latency
   (burstiness).  It is hoped that self-interest and standardization of
   dynamic behaviour (especially flow start-up) will be sufficient to
   prevent transports from sending excessive bursts of L4S traffic,
   given the application's own latency will suffer most from such
   behaviour.

   Whether burst policing becomes necessary remains to be seen.  Without
   it, there will be potential for attacks on the low latency of the L4S
   service.  However it may only be necessary to apply such policing
   reactively, e.g. punitively targeted at any deployments of new bursty
   malware.

   A per-flow (5-tuple) queue protection function [I-D.briscoe-docsis-q-protection] 
   has been developed for the low
   latency queue in DOCSIS, which has adopted the DualQ L4S
   architecture.  It protects the low latency service from any queue-
   building flows that accidentally or maliciously classify themselves
   into the low latency queue.  It is designed to score flows based
   solely on their contribution to queuing (not flow rate in itself).
   Then, if the shared low latency queue is at risk of exceeding a
   threshold, the function redirects enough packets of the highest
   scoring flow(s) into the Classic queue to preserve low latency.

   Such a queue protection function is not considered a necessary part
   of the L4S architecture, which works without it (in a similar way to
   how the Internet works without per-flow rate policing).  Indeed,
   under normal circumstances, DOCSIS queue protection does not
   intervene, and if operators find it is not necessary they can disable
   it.  Part of the L4S experiment will be to see whether such a
   function is necessary.
"

and https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11"

"4.1.  Overload Handling

   Where the interests of users or flows might conflict, it could be
   necessary to police traffic to isolate any harm to the performance of
   individual flows.  However it is hard to avoid unintended side-
   effects with policing, and in a trusted environment policing is not
   necessary.  Therefore per-flow policing (e.g.
   [I-D.briscoe-docsis-q-protection]) needs to be separable from a basic
   AQM, as an option under policy control."

It seems clear that this position of not requiring a policer is not based on actual data, as otherwise there would be references demonstrating that. IMHO this is based on hope/wishful thinking.

QUESTIONS:

1) Are you agreeing that these definitions are not fully aligned with your idea that misusing the input signal will have negative consequences for the abuser?

2) Are you proposing to make such policing mandatory (which would require at least changes to the cited section of RFC drafts) or are you fine with leaving this aspect purely for implementers? At that point L4S proponents will argue that this will drag in reading L4 headers something they want to avoid at all costs* 

Best Regards
	Sebastian

*) IMHO this is misguided, a node not having access to L4 headers simply can use a 3-tupel (just from the IP header) for "flow-group" identification, or on IPv6 ualso se the flow label as part of the flow identification or not use ECN in its AQM at all. Or put differently, I do not assume meaningful roll-out of AQMs to this nodes, as the value equation that has made operators not deploy single queue PIE or Codel to those nodes still apply. And those single queue AQMs would already deliver the bulk of the latency improvement expected with L4S, from multiple 100s to 1000s of milliseconds down to the high single to low double digit millisecond range. But I digress.

---

From: David Pullen <[email-masked]>
Date: Thu, 14 May 2020 13:01:52 -0400

Thanks,
  - Dave

David Pullen
Distinguished Engineer  |  Wired Networking, Cable Modems
Broadcom

office: 678.475.3143  |  mobile: 678.477.4108  |  fax: 770.232.0211
4385 River Green Parkway  |  Duluth, GA 30096
[email-masked]   |   broadcom.com

---

From: "Campos, Angel, Vodafone Spain" <[email-masked]>
Date: Thu, 14 May 2020 16:43:27 +0000

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.

[Vodafone]<http://vodafone.es/>

ANGEL CAMPOS
Group Network Engineering Manager
NGA Evolution
+34610510906
[email-masked]

Vodafone Spain, Area Portuaria de Bouzas s/n, Consorcio Zona Franca. 36208 Vigo - Spain

vodafone.es<http://vodafone.es/>

The future is exciting.
Ready?

Este mensaje, así como sus archivos o documentos adjuntos, son confidenciales y pueden estar sujetos a secreto profesional, quedando prohibida su revelación y/o protegido por las correspondientes normas legales. El mensaje se dirige exclusivamente a las personas físicas o jurídicas que figuran como destinatarios. Si usted no es el destinatario de este mensaje o lo ha recibido por error, le rogamos informe de manera inmediata de ello al remitente, elimínelo de sus sistemas y no reproduzca o revele su contenido ni lo utilice para ningún fin. Muchas gracias. Por favor tenga en cuenta que la transmisión de correos no es segura ni garantiza la correcta recepción de los mismos.

From: tsvwg <[email-masked]<mailto:[email-masked]>> on behalf of Wesley Eddy <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 4, 2020 at 12:15 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [tsvwg] Consensus call on ECT(1)

Please

C2 General

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Fri, 15 May 2020 05:45:43 +0000

Best regards
Hannu

From: tsvwg <[email-masked]> On Behalf Of Wesley Eddy
Sent: Monday, May 4, 2020 9:15 PM
To: [email-masked]
Subject: [tsvwg] Consensus call on ECT(1)

---

From: Karthik Sundaresan <[email-masked]>
Date: Fri, 15 May 2020 15:40:21 +0000

Hello,

I support ECT(1) as an input signal to the network .  (L4S approach)

Thanks
Karthik

Karthik Sundaresan,
R&D Wired, CableLabs
303 661 3895

In

If

  1.
  2.

Please

---

From: <[email-masked]>
Date: Sat, 16 May 2020 15:46:49 +0000

Best wishes
phil
Sent: 04 May 2020 19:15

---

From: Tom Henderson <[email-masked]>
Date: Sun, 17 May 2020 09:58:21 -0700

On 5/4/20 11:15 AM, Wesley Eddy wrote:
> viewpoints on ECT(1) you prefer. 

Option 3, with rationale to follow.

- Tom

---

From: Dave Taht <[email-masked]>
Date: Sun, 17 May 2020 10:52:19 -0700

If I had to make a choice, today, I would vote for option 2.
ECT(1) as a network output. The present conception of SCE "fails safe"
in far more circumstances than the present conception of L4S appears to.

The internet as a whole needs to retain and improve upon, the existing strong
signal of congestion that the RFC3168 compliant CE indicator brings to it, and
furthermore, more fully deploy the existing IETF AQMs in more places
where it matters.

However, I vote for option 3, with a rationale to follow. (The chair's
question also wanted
a list of tests, but that got too long for this vote, so I am moving that to the
rationale)

-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

[email-masked] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

---

From: Liyizhou <[email-masked]>
Date: Mon, 18 May 2020 08:00:11 +0000

Hi,

Rgds,
Yizhou

From: tsvwg [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Tuesday, May 5, 2020 2:15 AM
To: [email-masked]
Subject: [tsvwg] Consensus call on ECT(1)

---

From: Dan Siemon <[email-masked]>
Date: Mon, 18 May 2020 12:46:34 -0400

Long time lurker, first time contributor so I'm not sure if that means
my vote counts or not...

My vote is #3 (more testing) because I don't have a complete enough
understanding of L4S to be firmly against it and I don't fully
understand the tunnel marking implications. Second choice is ECT as
output.

My interest and concern in this comes from the point of view of a
vendor [1] that offers traffic management solutions for the fixed
wireless market [2]. We use FQ-CoDel but at this point have not widely
enabled ECN (the little experimentation we've done looks promising).

My rational is as follows:
* One of the reasons that DSCP hasn't taken off, in addition to the
coordination problem, is that without per-subscriber isolation, it will
be gamed. I do not understand why a new classification scheme would not
suffer the same fate.
* The improvement with a modern AQM is already dramatic.
* It's "weird" that in the "ECT(1) as input" option, of the four ECN
combinations, three are related to congestion control and one is a
special, 'DSCP doesn't work so we stole it for classification' value.
Explaining that outside of this forum may not be fun.
* SCE (ECT(1) as output) is more intuitive to me.
* Most fixed wireless networks are flat IP with little tunnelling and
use simple equipment that I'm skeptical will adopt L4S. These networks
host millions of subscribers in the U.S. alone.

[1] - https://www.preseem.com
[2] - https://www.wispa.org/what_is_a_wisp.php

On Mon, 2020-05-04 at 14:15 -0400, 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 (
> [email-masked]). 
> 
> 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
> remaining issues can be resolved by continued WG effort on the
> current drafts.

---

From: "Mohit P. Tahiliani" <[email-masked]>
Date: Tue, 19 May 2020 03:29:07 +0530

I would prefer Option 3, and the following is my view:

Besides the inter-protocol fairness tests that have been already discussed
in the list, I would suggest to extensively evaluate the intra-protocol
fairness of the proposed mechanisms. One of the tests for evaluating
intra-protocol fairness could be to consider a scenario where long lasting
flows are transmitting at rates that sum up to the link capacity, and the
buffer is below the marking threshold. Add new flows that are short lived
so that the buffer starts growing, and eventually the ECN marks begin to be
generated. We should then confirm that the long lasting flows back off
sufficiently to provide a fair share to the newly started short lived
flows, the queue control is as desired and the link capacity is fully
utilised. After the short flows end, let only the long lasting flows
operate for some duration, and then again add short lived flows. This test
could be repeated with varying RTTs for short flows in each epoch to
evaluate the proposals in scenarios with different feedback delays.

In my opinion, it is important to evaluate both the proposals (L4S and SCE)
in a realistic traffic model consisting of a mixture of long lasting flows
and short lived flows (the ones that do not last beyond the slow start
phase), and feedback delays ranging from a 100s of microseconds to 100s of
milliseconds.

I would suggest that we carefully outline the benchmark tests to
extensively evaluate the new proposals in terms of other desired metrics
and network scenarios.

Thanks and Regards,
Mohit P. Tahiliani

---

From: Roland Bless <[email-masked]>
Date: Tue, 19 May 2020 09:46:35 +0200

Hi Dan,

+1

> Explaining that outside of this forum may not be fun.

Yep, that's also one of the points I find quite odd. It would be better
to make DSCPs "work" (at least not bleaching them) instead of creating
more and more work arounds.

> * SCE (ECT(1) as output) is more intuitive to me.

The nice thing about this is that the output is at least unambiguous:
ECT(1) means some/light congestion level (scalable congestion control
reaction), CE means traditional indication of congestion (stronger
congestion control reaction). Whereas in L4S it is not clear whether
CE actually means "classic CE" or "L4S CE".

Regards
 Roland

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 May 2020 13:07:30 +0200 (CEST)

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.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Steven Blake <[email-masked]>
Date: Tue, 19 May 2020 12:49:54 -0400

> > [2] - https://www.wispa.org/what_is_a_wisp.php

The sad/hilarious side of this is that we once had a bit in IP to
indicate a preference for low-delay: the D bit in the TOS field.

https://tools.ietf.org/html/rfc791#page-12

Unfortunately, in addition to (correctly IMHO) advising vendors to make
the mapping between these bits and HW mechanisms configurable, the
geniuses who came up with Diffserv also changed the (default) semantic
interpretation of this bits in ways that, with 20 years of hindsight,
haven't resulted in a raging operational success.

SMDH.

// Steve