Subject: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 14 Nov 2019 05:50:09 -0800 (PST)

Hello tsvwg list members,

It is our intent to ask for adoption by the TSVWG of draft-morton-tsvwg-sce (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the IETF/106 Singapore TSVWG session.

The TSVWG chairs have provided the following guidelines for this adoption request:
 
(1) The WG chairs want to see interest in SCE technology beyond the draft authors in order to adopt the SCE draft.   This will include surveying the room in Singapore (e.g., who has read this
 draft?).
 
(2) Coexistence of the L4S and SCE experiments is a concern that will need to be addressed by the WG if the SCE draft is adopted, and hence is in scope for discussion of this adoption request
.  In particular, absence of a coexistence plan (e.g., to deal with the different uses of the ECT(1) codepoint by L4S and SCE) is not an automatic barrier to WG adoption of the SCE draft.
 
(3) The TCPM WG chairs have indicated TCPM WG willingness to consider complementary TCP work needed to complete SCE functionality.  In particular, draft-grimes-tcpm-tcpsce is likely to be inc
luded in the TCPM Singapore agenda for Friday morning.

Regards,
-- 
Rod Grimes                                                 [email-masked]

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 14 Nov 2019 09:16:30 -0500

On Thu, Nov 14, 2019 at 8:50 AM Rodney W. Grimes
<[email-masked]> wrote:
> It is our intent to ask for adoption by the TSVWG of draft-morton-tsvwg-sce
> (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the IETF/106
> Singapore TSVWG session.

One random thought: the draft-morton-tsvwg-sce-01 draft mentions:

   Permitted ECN codepoint packet transitions by middleboxes are:

           Not-ECT ->   Not-ECT (or drop)
           ECT     ->   ECT or SCE or CE
           SCE     ->   SCE or CE
           CE      ->   CE

Presumably if the buffer space is full and an ECT-, SCE-, or CE-marked
packet arrives then that packet can be dropped. So presumably "drop"
is permitted from those codepoint states as well. (I see the point
that hopefully this will be rare for ECT/SCE/CE packets, but with
bursty connection arrivals it seems important to clarify that this is
possible.)

Since a drop is not really an "ECN codepoint packet transition", and
can happen to any packet, perhaps "(or drop)" could be omitted from
the table, for clarity? And as a replacement, the text could mention
something about "drop" being a possibility for packets marked with any
of those ECN code points?

best,
neal

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 14 Nov 2019 17:04:31 +0000

Hi all,

I think it will be a very bad idea to start now an additional experiment which conflicts with the ongoing adopted drafts. We need to make sure that the initial work can be finalized and that we don't self-undermine the ongoing successful initiative with a second proposal which has a lesser scope and no industry adoption.

L4S work might not be very visible on the mailing list (because of the industry context), but there is traction with first product availabilities to be announced next year. CableLabs standardized L4S in LLD, and vendors are working on this. Nokia has demonstrated L4S integration in its WiFi Beacons at BBWF19, which will be available Q1 next year, and other products will follow. I'm sure these are not the only examples.

On the other hand, the main concern about SCE is still not solved: I see no solution for the problem that SCE works only for FQ_x.
I also see no solution for SCE to work next to and without interfering with the ongoing L4S initiative.

If we want to achieve low latency on the Internet, we need to bundle the effort and maximize the chances for success of the most promising solution. No solution is perfect by the way, and we should stop trying to expect perfection too.

I hope from a network vendor's perspective that we can finalize the network drafts. The DualPI2 implementation is stable, seems we need to get some agreement on the wording of the drafts and we need to find a compromise on the TCP-Prague requirements between what application developers think is feasible and safe enough/likely to happen. The application/service provider's motivation will be higher than that of network vendors to get a deployable TCP-Prague implementation (they for sure have already solutions ready to try out and experiment with). Let's focus on this, instead of creating diversions...

Koen.

-----Original Message-----
From: tsvwg <[email-masked]> On Behalf Of Rodney W. Grimes
Sent: Thursday, November 14, 2019 2:50 PM
To: [email-masked]
Subject: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

 
 
(2) Coexistence of the L4S and SCE experiments is a concern that will need to be addressed by the WG if the SCE draft is adopted, and hence is in scope for discussion of this adoption request ..  In particular, absence of a coexistence plan (e.g., to deal with the different uses of the ECT(1) codepoint by L4S and SCE) is not an automatic barrier to WG adoption of the SCE draft.
 
(3) The TCPM WG chairs have indicated TCPM WG willingness to consider complementary TCP work needed to complete SCE functionality.  In particular, draft-grimes-tcpm-tcpsce is likely to be inc luded in the TCPM Singapore agenda for Friday morning.

Regards,

---

From: G Fairhurst <[email-masked]>
Date: Fri, 15 Nov 2019 02:30:15 +0800

I would expect loss to be an important mechanism to deal with overload 
of a ECT(0) queue.

The observation that TCP senders received two signals - loss and 
CE-marking was the  important step behind RFC8511 to take advantage of 
any lower queuing delay that an ECN-capable AQM can provide, while 
accepting that bursts and other traffic can exceed the router's 
buffering and induce loss. That is somewhat different in L4S which seeks 
to keep a much lower queuing delay.

Gory

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 14 Nov 2019 20:35:39 +0200

I think the possibility of packet loss is inherently implied in the best
effort nature of IP routing.  The previous wording did include an explicit
reference to dropping each class of packet, but I thought it was
unnecessarily verbose like that.

Is an explicit reference to dropping needed here at all?  If so, I may move
it to a separate sentence and remove it from the table altogether.

---

From: Dave Taht <[email-masked]>
Date: Thu, 14 Nov 2019 10:38:17 -0800

> I would expect loss to be an important mechanism to deal with overload

I expect loss to be an important mechanism to deal with overload of
ECT(0) *or* ECT(1).

In fact, I'd rather like it if transports considered a mixture of loss
and CE, in the SCE case, as an indication of grosser overload with a
correspondingly higher rate reduction.

This idea is not possible in the L4S case, sadly enough.

A bit more below.

> buffering and induce loss. That is somewhat different in L4S which
> seeks to keep a much lower queuing delay.
>
> Gory
>
>

Good idea.

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 14 Nov 2019 19:39:46 +0100

Hi Koen,

given the list of open issues with L4S components adopting this draft seems pre-mature:

1) peaceful coexistence with 1/sqrt(p) traffic at short RTTs with L4S's preferred dual queue AQM (dualQ), IMHO this is a show stopper unless the aim is to give L4S style traffic an (unfair) bandwidth advantage.

2) peaceful coexistence with rfc3168-compliant ECN using AQMs (TCP Prague)

Given the duration of the L4S project's development so far, it seems optimistic that these issues will be solved and robustly stress tested any time soon. 

In that light in incompleteness and given that evolution works best under selective pressure and competition I think SCE should be allowed to progress to RFC status on its own merits
IMHO both proposals should (once show stoppers for safe operation on the internet are fixed) be given a fair chance to prove themselves as robust reliable and effective. Trying to dispose of valid competition by appeal to the editors strikes me as an indirect admission that one's own solution might be inferior...

Best Regards

> On Nov 14, 2019, at 18:04, De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> Hi all,
>

---

From: G Fairhurst <[email-masked]>
Date: Fri, 15 Nov 2019 02:50:42 +0800

I think we could do better to keep the discussion focussed on why the 
IETF would need an additional level of signal (aka 
ECT(0)->SCE->CE->Loss) and whether this has implications on existing 
RFCs and the chartered work.

Gorry

On 15/11/2019, 02:39, Sebastian Moeller wrote:
>> On Nov 14, 2019, at 18:04, De Schepper, Koen (Nokia - BE/Antwerp)<[email-masked]>  wrote:
>>
>> Hi all,
>>
>> From: tsvwg<[email-masked]>  On Behalf Of Rodney W. Grimes

---

From: Matt Mathis <[email-masked]>
Date: Thu, 14 Nov 2019 11:10:46 -0800

Note that the most common case would actually be two bottlenecks having
completely different statistics: a highly aggregated short queue "core"
device where approximately all drops are caused by bursts in other flows,
and an edge bottleneck which is properly marking CE, and is in good control
of its total load.

In this environment, the best solution is the MIN() of independent loss
based and ECN based controllers.  All other functional combination of
those signals will cause fairness problems where unrelated core losses
reduce a flow's share of the well controlled edge bottleneck.

This is one of the observations that flipped me into strongly pro BBR,
where in principle it is trivial to run multiple independent rate
controllers, and explicitly pick the min.   (Did we mention that BBR
isn't really done yet? - There is a lot to do...)

Going back to the original question, I would expect it to be a rare corner
case for the losses and partial CE marks to come from the same bottleneck.
(100% CE is a different story).  Rare == bad bottleneck design, and not
worthy of addressing in congestion control.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.

---

From: Dave Taht <[email-masked]>
Date: Thu, 14 Nov 2019 11:44:29 -0800

Matt Mathis <[email-masked]> writes:

> Note that the most common case would actually be two bottlenecks
> having completely different statistics: a highly aggregated short
> queue "core" device where approximately all drops are caused by bursts
> in other flows, and an edge bottleneck which is properly marking CE,
> and is in good control of its total load.
>
> In this environment, the best solution is the MIN() of independent
> loss based and ECN based controllers. All other functional combination
> of those signals will cause fairness problems where unrelated core
> losses reduce a flow's share of the well controlled edge bottleneck.

Agree. We can wave hands a little regarding other lossage on the
link(s), in an environment where we see no SCE, CE and some drop,
or in an environment where we are seeing SCE and some drop.

> isn't really done yet? - There is a lot to do...)

I'm pro-BBR as well, and looking forward to the SCE version.

>
> Going back to the original question, I would expect it to be a rare
> corner case for the losses and partial CE marks to come from the same
> bottleneck. (100% CE is a different story). Rare == bad bottleneck
> design, and not worthy of addressing in congestion control.

Regrettably that's not the measured case with pie, at least, in that
the standard (with ecn enabled) it starts dropping at 10% drop probability.

So does fq-pie.

fq-codel does not drop until queue overload, however (due to memory
constraints on consumer routers) shorter queues than desirable are often
deployed, and the bulk dropper has been observed to kick in more often
than it should, so a typical pattern is CEs with a big bulk drop
periodically in the case of overload. There's a partial cure for the non
O(1) cpu overhead of finding the fattest queue now in linux head, and a
complete removal of the non O(1) search in the fq_codel_fast (SCE)
repository that's a tad probalistic. (It's O(1) but relies on finding
the next fattest flow in under 32 packet deliveries)

https://github.com/dtaht/fq_codel_fast/commit/f00ad01168e6d4e18b2d46f3de4f12aaee2bb778

100% CE is also easy to do, given that modern TCPs cap cwnd reduction to
2 or (4 in BBR's case), and all you need to do is have enough ECN
enabled tcp flows going through the bottleneck, to get stuck there at
any X maximum queue length. This should be an easy figure to calculate,
and why sub-packet windows (and/or a MSS reduction) should be
requirements IMHO for a more fully ecn-abled internet, and why I like
RFC3168 sec 6.1.5 and other things like losing syns vs things like ECN++.

I haven't really catagorized dualpie's behaviors, not having the kind of
time for I had 2011-2014. 

as for cake, well, I think cake should revert to drop far sooner than
it does, but that's a pretty lonely opinion thus far.

And in all cases, so far as I know, the combination of CE, (or SCE) +
drop has not been explored well in any transport so it's early to dismiss
the idea entirely, and don't know how rare these corner cases actually
are. Until recently the dctcp implementation in linux had no response to
drop at all (no cwnd reduction!!), and all my data on it predates that change.

> too strong would be hypocritical and risks spiraling out of control;

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 14 Nov 2019 21:55:48 +0200

> as for cake, well, I think cake should revert to drop far sooner than it
does, but that's a pretty lonely opinion thus far.

If it's any comfort, we're now testing a version of COBALT which activates
the BLUE algorithm (which, for the uninitiated, we use with hard drops for
overload control) at a particular sojourn time rather than only on queue
overflow.  That should be an easy thing to drop into Cake, and it would
address some of the nastier looking charts from Mohit's paper.

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 14 Nov 2019 15:22:00 -0500

On Thu, Nov 14, 2019 at 1:35 PM Jonathan Morton <[email-masked]> wrote:
>
> I think the possibility of packet loss is inherently implied in the best effort nature of IP routing.  The previous wording did include an explicit reference to dropping each class of packet, but I thought it was unnecessarily verbose like that.
>
> Is an explicit reference to dropping needed here at all?  If so, I may move it to a separate sentence and remove it from the table altogether.

Since this is a table summarizing "codepoint packet transitions", IMHO
a mention of "(or drop)" is not needed in the table, and just confuses
things if "(or drop)" is only listed in one row when it really applies
to all rows.

IMHO an explicit reference to dropping is not needed in that passage.
But if others think it's necessary, then moving it to a separate
sentence and removing it from the table altogether sounds great.

best,
neal

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 14 Nov 2019 21:22:14 +0100

Hi Gorry,

more below.

> On Nov 14, 2019, at 19:50, G Fairhurst <[email-masked]> wrote:
> 
> I think we could do better to keep the discussion focussed on why the IETF would need an additional level of signal (aka ECT(0)->SCE->CE->Loss) and whether this has implications on existing RFCs and the chartered work.

	[SM] Well , since CE is already in use, re-defining it comes with the issue of non-compatibility with parts of the existing internet. It seems much easier to avoid undesired negative interactions with rfc3168 compliant network nodes by keeping the original meaning of CE. But since a [weaker | faster | non-1/sqrt(p)] type signal is desired for explicit congestion notification an additional signal level seems worth to spend one ECN code point on. (It is not that the L4S approach would conserve that ECN codepoint). SCE seems to be compatible with the existing internet. 
	To my knowledge the only known issue of contention is L4S' proposed redefinition of the ECN code-points which makes L4S and SCE incompatible. Since L4S seems to be currently aimed for deployment at the ISP customer boundary, I would propose for the duration of both the L4S and SCE experiments to mandate an "access network MUST make the use of L4S/SCE type AQMs configurable by the end-customers" (what I mean is if an ISP deploys any one the customer needs to be able to shut it off), that way end-users have the choice which interpretation of ECT(1) they prefer. 
	Yes, that will not be perfect future proof way to deploy any of these, but how about getting real world data in to show that universal deployment of any of the alternatives is justified and desirable?

Best Regards
	Sebastian

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 14 Nov 2019 22:32:54 +0200

> I think we could do better to keep the discussion focussed on why the
IETF would need an additional level of signal (aka ECT(0)->SCE->CE->Loss)
and whether this has implications on existing RFCs and the chartered work.

On this point I agree.

Meanwhile I will simply note that I disagree on a factual basis with
several of Koen's points.  More detail will have to wait until I and my
colleagues are not stuck in airports in multiple timezones.

- Jonathan Morton

---

From: G Fairhurst <[email-masked]>
Date: Fri, 15 Nov 2019 04:50:09 +0800

On 15/11/2019, 04:22, Sebastian Moeller wrote:
> Hi Gorry,
>
> more below.
>
>> On Nov 14, 2019, at 19:50, G Fairhurst<[email-masked]>  wrote:
>>
> 	To my knowledge the only known issue of contention is L4S' proposed redefinition of the ECN code-points which makes L4S and SCE incompatible.

> Since L4S seems to be currently aimed for deployment at the ISP customer boundary, I would propose for the duration of both the L4S and SCE experiments to mandate an "access network MUST make the use of L4S/SCE type AQMs configurable by the end-customers" (what I mean is if an ISP deploys any one the customer needs to be able to shut it off), that way end-users have the choice which interpretation of ECT(1) they prefer.

The first question is whether there should be two experiments in parallel.

Gorry

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Fri, 15 Nov 2019 08:02:29 -0800 (PST)

[ Charset UTF-8 unsupported, converting... ]
> it to a separate sentence and remove it from the table altogether.

With my coders hat on the drop in the table is explicit and clear,
but either is actually adaquate.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Fri, 15 Nov 2019 08:14:24 -0800 (PST)

> sentence and removing it from the table altogether sounds great.

I can agree with this as long as the table is called "codepoint
packet transitions", but what an implementation is interested in
is the state machine transitions, and that state machine is going
to have a drop node.

So you could call this table "packet state transitions", and
use the "or drop", or you can do what Neal outlines above,
either works for me as good solutions to this slightly unclear
table.

---

From: "Roni Even (A)" <[email-masked]>
Date: Sat, 16 Nov 2019 03:16:02 +0000

Inline

> From: tsvwg [mailto:[email-masked]] On Behalf Of G Fairhurst
> Sent: Thursday, November 14, 2019 8:51 PM
> To: [email-masked]
> Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-
> tsvwg-sce
> 
> I think we could do better to keep the discussion focussed on why the IETF
> would need an additional level of signal (aka
> ECT(0)->SCE->CE->Loss) and whether this has implications on existing RFCs
> and the chartered work.
[Roni] I think this is one  way to look at it but in my view I think that the SCE/L4S usage is a hint that we need to look at a more general way to extend the ECN/CC information to allow for more congestion information and learning the path characteristics to allow for other extensions in the future
> > 1) peaceful coexistence with 1/sqrt(p) traffic at short RTTs with L4S's
> preferred dual queue AQM (dualQ), IMHO this is a show stopper unless the
> aim is to give L4S style traffic an (unfair) bandwidth advantage.
> >
> > Given the duration of the L4S project's development so far, it seems
> optimistic that these issues will be solved and robustly stress tested any time
> soon.
> >
> > In that light in incompleteness and given that evolution works best
> > under selective pressure and competition I think SCE should be allowed to
> progress to RFC status on its own merits IMHO both proposals should (once
> show stoppers for safe operation on the internet are fixed) be given a fair
> chance to prove themselves as robust reliable and effective. Trying to
> dispose of valid competition by appeal to the editors strikes me as an indirect
> admission that one's own solution might be inferior...
> >
> >
> > Best Regards
> >
> >
> >
> >
> >> On Nov 14, 2019, at 18:04, De Schepper, Koen (Nokia -
> BE/Antwerp)<[email-masked]>  wrote:
> >>
> >> Hi all,
> >>
> >> I think it will be a very bad idea to start now an additional experiment
> which conflicts with the ongoing adopted drafts. We need to make sure that
> the initial work can be finalized and that we don't self-undermine the
> ongoing successful initiative with a second proposal which has a lesser scope
> and no industry adoption.
> >>
> >> L4S work might not be very visible on the mailing list (because of the
> industry context), but there is traction with first product availabilities to be
> announced next year. CableLabs standardized L4S in LLD, and vendors are
> working on this. Nokia has demonstrated L4S integration in its WiFi Beacons
> at BBWF19, which will be available Q1 next year, and other products will
> follow. I'm sure these are not the only examples.
> >>
> >> On the other hand, the main concern about SCE is still not solved: I see no
> solution for the problem that SCE works only for FQ_x.
> >> If we want to achieve low latency on the Internet, we need to bundle the
> effort and maximize the chances for success of the most promising solution.
> No solution is perfect by the way, and we should stop trying to expect
> perfection too.
> >>
> >> I hope from a network vendor's perspective that we can finalize the
> network drafts. The DualPI2 implementation is stable, seems we need to get
> some agreement on the wording of the drafts and we need to find a
> compromise on the TCP-Prague requirements between what application
> developers think is feasible and safe enough/likely to happen. The
> application/service provider's motivation will be higher than that of network
> vendors to get a deployable TCP-Prague implementation (they for sure have
> already solutions ready to try out and experiment with). Let's focus on this,
> instead of creating diversions...
> >>
> >> Koen.
> >>
> >>
> >> It is our intent to ask for adoption by the TSVWG of draft-morton-tsvwg-
> sce (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the
> IETF/106 Singapore TSVWG session.
> >>
> >>
> >> (1) The WG chairs want to see interest in SCE technology beyond the draft
> authors in order to adopt the SCE draft.   This will include surveying the room
> in Singapore (e.g., who has read this
> >> draft?).
> >>
> >> (2) Coexistence of the L4S and SCE experiments is a concern that will need
> to be addressed by the WG if the SCE draft is adopted, and hence is in scope
> for discussion of this adoption request ..  In particular, absence of a
> coexistence plan (e.g., to deal with the different uses of the ECT(1)
> codepoint by L4S and SCE) is not an automatic barrier to WG adoption of the
> SCE draft.
> >>
> >> (3) The TCPM WG chairs have indicated TCPM WG willingness to consider
> complementary TCP work needed to complete SCE functionality.  In
> particular, draft-grimes-tcpm-tcpsce is likely to be inc luded in the TCPM
> Singapore agenda for Friday morning.
> >>
> >>
> >> Regards,
> >> --

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sat, 16 Nov 2019 12:32:34 +0000

Hi SCE'ers,

I don't think this is a personal battle, nor a competition or an attempt to stop/block competition. I just want to call for using common sense. It is the role of IETF to come to consensus and make sure that there is a common way forward. We also cannot let individual users of cars decide if they want to drive left or right on the roads, or pick their favorite color to stop on traffic lights.

Releasing two simultaneous experiments on the same code point with largely the same goals will likely result in the code point becoming useless.

On the other hand, I think the evolutional analogy is a good approach. If the Internet is the existing ecosystem and the new ECN codepoint we select is the gene combination, we need to make sure that we select the fittest one, that gets the best chances to survive and flourishing (that users want to use and that replaces the existing codepoint). Releasing 2 in parallel that will rather kill each other is not what we want, right?

I also don't think that coupling or blocking the future of Low Latency ECN on technologies, that have been proven hard to adopt in the industry, is a better strategy.
Related to long adoption times, rfc3168 got the opportunity of about 20 years to get adopted, FQ got I guess 10 years to get adopted, and for both I see no real/general Telco industry (silicon) adoption.

That's why I see only the SCE-FQ dependency as a real adoption-show stopper. Believe me that getting support for ECN in silicon is already a challenge, you don't want to additionally put FQ on the plate (or should I say wafer) as well...

Obviously in circumstances where FQ is beneficial or FQ and ECN is easy to implement or is already implemented, L4S is a very simple upgrade. I think it would be very useful to have an L4S-FQ draft for this. Volunteers?

Regards,
Koen.

-----Original Message-----
From: Sebastian Moeller <[email-masked]> 
Sent: Thursday, November 14, 2019 7:40 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>
Cc: Rodney W. Grimes <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

Hi Koen,

In that light in incompleteness and given that evolution works best under selective pressure and competition I think SCE should be allowed to progress to RFC status on its own merits IMHO both proposals should (once show stoppers for safe operation on the internet are fixed) be given a fair chance to prove themselves as robust reliable and effective. Trying to dispose of valid competition by appeal to the editors strikes me as an indirect admission that one's own solution might be inferior...

Best Regards

---

From: Dave Taht <[email-masked]>
Date: Sat, 16 Nov 2019 11:49:35 -0800

"De Schepper, Koen (Nokia - BE/Antwerp)"

> Hi SCE'ers,

I'd like to be clear in all my communications that I am not on either
the L4S or SCE side. I am deeply skeptical about the viability of ecn in
general. I'd perpetually be pointing at all the non-IP ethertypes people
use, or mentioning that nearly every routing protocol is going to need
to be ECNed (ISIS is impossible)...

and a variety of other things on the ecn-sane worklist...

if I had the time.

> I don't think this is a personal battle, nor a competition or an
> attempt to stop/block competition. I just want to call for using
> common sense.

Common sense to me has been the ietf tradition of running code and two
interoperable implementations, and a ton of independent benchmarks.

We're getting there. Bugs are showing up and getting fixed.

Common sense to me is what google did with QUIC - 20! (no kidding)
iterations of the codebase every couple of weeks, for 3 years, tested on
millions of users each time - before entering the ietf processes.

Oh! to have resources like that and to be iterating the l4s and sce
ideas like that!

> It is the role of IETF to come to consensus and make
> sure that there is a common way forward.

> We also cannot let individual
> users of cars decide if they want to drive left or right on the roads,
> or pick their favorite color to stop on traffic lights.

I enjoyed this analogy! I lost the morning trying to come up with a
viable counter.

> Releasing two simultaneous experiments on the same code point with
> largely the same goals will likely result in the code point becoming
> useless.

What is your definition of release? Why on earth does the IETF have
to bless an "experiment" or experiments?

> On the other hand, I think the evolutional analogy is a good
> approach. If the Internet is the existing ecosystem and the new ECN
> codepoint we select is the gene combination, we need to make sure that
> we select the fittest one, that gets the best chances to survive and
> flourishing (that users want to use and that replaces the existing
> codepoint). Releasing 2 in parallel that will rather kill each other
> is not what we want, right?

Given that there seems to be months and months of simulation and coding
work left to be done on either the SCE or L4S alternatives, with ever
more adversial tests to construct and run, "releasing an RFC" seems
extremely premature, and having two approaches under consideration
(and competing) in this wg seems like a sound idea.

I don't have much truck with the official RFC release process. Certainly
I think writing an internet draft, whether approved or not, is useful.

Secondly, now that the specs are solid enough for decent code to start
emerging, I don't (and have never understood) why this code cannot
be tested at a smaller scale across the internet today.

I'm rather blase' about twiddling a few bits here or there on the
internet - in a world rife with terabit DDOS attacks, syn floods, all
sorts of exploits, I simply do not understand why folk here just don't
burn a few bucks on vpses in multiple cloud providers and fire stuff up
to see what happens from as many vantage points as they can find.

It's way cheaper than the ietf conference fee.

>
> I also don't think that coupling or blocking the future of Low Latency
> ECN on technologies, that have been proven hard to adopt in the
> industry, is a better strategy.
> Related to long adoption times, rfc3168 got the opportunity of about
> 20 years to get adopted, FQ got I guess 10 years to get adopted, and
> for both I see no real/general Telco industry (silicon) adoption.

As to your silicon point, yea. I find that just as frustrating as anyone
else.

but while I'm always pointing to how software is eating hardware...

... As to actual adoption, SFQ first appeared in cisco routers circa 1994
(?), it was in one dsl router's firmware as early as 2001,
and adopted by nearly every linux shaper I've looked at starting in
2002. I see a lot of SFQ-like behaviors from a few ISPs.

Certainly, the fq_codel variant has exploded in size since 2012.

Meanwhile...

post-2002, RFC3168 was widely adopted in tcps, but it crashing hardware
kind of killed the deployment. Thanks to apple's big push worldwide, it
seems to be working now (with some issues with load balancers like
cloudflare's now showing up) with more and more data showing up in the
last 2 years.

In my opinion it was too late to change the definition of CE by 2006,
much less 2012, or post the apple deployment and the rise of containers.
It's premature to change it all.

I don't know why y'all think obsoleting *every* end user OS's
tcp implementation of rfc3168 is a good idea. Improving that deployment
with something backwards compatible best serves a billion users.

Historical note:

ECN appeared in the 90s before sack, but sack finished first and despite
sack's usefulness... I've lost track - was at 60? 70% ? percent of traffic a
few years back.

I'm sad that the telco industry is so slow to change, and glad that the
edge can innovate so much faster than the center or IETF can.

> That's why I see only the SCE-FQ dependency as a real adoption-show
> stopper.. Believe me that getting support for ECN in silicon is
> already a challenge, you don't want to additionally put FQ on the
> plate (or should I say wafer) as well...

If it doesn't work worth beans, why pour it into silicon? It would
certainly help to prove it out thoroughly in simulation and software and
small scale tests across the internet before bothering to try.

So far, extreme RTT unfairness, and slow convergence has been shown
to be a L4S and SCE problem. In software. In repeatable simulations.

>
> Obviously in circumstances where FQ is beneficial or FQ and ECN is
> easy to implement or is already implemented, L4S is a very simple
> upgrade. I think it would be very useful to have an L4S-FQ draft for
> this. Volunteers?

I'd much rather focus on improving running code, and having two
interoperable implementations than bother writing yet another draft.

> 1) peaceful coexistence with 1/sqrt(p) traffic at short RTTs with
> L4S's preferred dual queue AQM (dualQ), IMHO this is a show stopper
> unless the aim is to give L4S style traffic an (unfair) bandwidth
> advantage.
>
> optimistic that these issues will be solved and robustly stress tested
> any time soon.
>
> under selective pressure and competition I think SCE should be allowed
> to progress to RFC status on its own merits IMHO both proposals should
> (once show stoppers for safe operation on the internet are fixed) be
> given a fair chance to prove themselves as robust reliable and
> effective. Trying to dispose of valid competition by appeal to the
> editors strikes me as an indirect admission that one's own solution
> might be inferior...
>
>
> Best Regards
>
>
>
>
>> I think it will be a very bad idea to start now an additional
>> experiment which conflicts with the ongoing adopted drafts. We need
>> to make sure that the initial work can be finalized and that we
>> don't self-undermine the ongoing successful initiative with a second
>> proposal which has a lesser scope and no industry adoption.
>> 
>> L4S work might not be very visible on the mailing list (because of
>> the industry context), but there is traction with first product
>> availabilities to be announced next year. CableLabs standardized L4S
>> in LLD, and vendors are working on this. Nokia has demonstrated L4S
>> integration in its WiFi Beacons at BBWF19, which will be available
>> Q1 next year, and other products will follow. I'm sure these are not
>> the only examples.
>> 
>> If we want to achieve low latency on the Internet, we need to bundle
>> the effort and maximize the chances for success of the most
>> promising solution. No solution is perfect by the way, and we should
>> stop trying to expect perfection too.
>> 
>> network drafts. The DualPI2 implementation is stable, seems we need
>> to get some agreement on the wording of the drafts and we need to
>> find a compromise on the TCP-Prague requirements between what
>> application developers think is feasible and safe enough/likely to
>> happen. The application/service provider's motivation will be higher
>> than that of network vendors to get a deployable TCP-Prague
>> implementation (they for sure have already solutions ready to try
>> out and experiment with). Let's focus on this, instead of creating
>> diversions...
>> 
>> Koen.
>> 
>> 
>> (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the
>> (1) The WG chairs want to see interest in SCE technology beyond the
>> draft authors in order to adopt the SCE draft.  This will include
>> surveying the room in Singapore (e.g., who has read this
>> draft?).
>> 
>> (2) Coexistence of the L4S and SCE experiments is a concern that
>> will need to be addressed by the WG if the SCE draft is adopted, and
>> hence is in scope for discussion of this adoption request ..  In
>> particular, absence of a coexistence plan (e.g., to deal with the
>> different uses of the ECT(1) codepoint by L4S and SCE) is not an
>> automatic barrier to WG adoption of the SCE draft.
>> 
>> (3) The TCPM WG chairs have indicated TCPM WG willingness to
>> consider complementary TCP work needed to complete SCE
>> functionality.  In particular, draft-grimes-tcpm-tcpsce is likely to
>> be inc luded in the TCPM Singapore agenda for Friday morning.
>> 
>> 
>> Regards,
>> --

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 18 Nov 2019 07:30:40 +0800

tsvwg Chairs,

> The TSVWG chairs have provided the following guidelines for this adoption request:
[snip]
> ..  In particular, absence of a coexistence plan (e.g., to deal with the different uses of the ECT(1) codepoint by L4S and SCE) is not an automatic barrier to WG adoption of the SCE draft.
Could the chairs give clarity on whether Rod's statement above came from 
the them please? And if it did, what the chairs thinking was in saying 
that. It seems rather an odd thing for chairs of an IETF WG to say about 
a codepoint in the IP header, when the prime role of the IETF is 
interoperability and coexistence.

Bob

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

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 18 Nov 2019 00:27:44 +0000

> > (2) Coexistence of the L4S and SCE experiments is a concern that will
> > need to be addressed by the WG if the SCE draft is adopted, and hence is in
> scope for discussion of this adoption request ..  In particular, absence of a
> the them please? And if it did, what the chairs thinking was in saying that. It
> seems rather an odd thing for chairs of an IETF WG to say about a codepoint
> in the IP header, when the prime role of the IETF is interoperability and
> coexistence.
[Roni] My reading of the text was that while LS4 was adopted by the WG the usage of ECT(1) by LS4 should not be the reason for not adopting SCE. The decision should be on the merit of the SCE. The usage of ECT(1) is a separate issue

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Nov 2019 08:52:57 +0800

While on the surface, the AQM marking strategy (abstract from what
actual signal is used to convey this) seems to be quite similar between
DCTCP (L4S) and SCE, what I am still missing would be a detailed
mathematical model of the SCE congestion control loop.

In the draft, the reaction is described as 1/sqrt(cwnd) - per mark,
compared to 1/cwnd (*alpha) for (fluid model) dctcp; at least the dctcp
implementation I work with, currently has not implemented the fluid
model reaction of dctcp though, but rather follows the original paper
and RFC.

I don't perceive the explicit ramp function in the marking probability
at the queue as fundamentally different between these two proposals.
Others have pointed out, that stability can be improved with dctcp, if
the aqm there is not using the step-function, but also a (steep) ramp.

The differnet CC reaction however will certainly result in a higher
marking level for SCE in the steady state. OTOH, SCE absolutely requires
a secondary signal (CE or drops), since the dynamic range of the control
is not sufficient to respond to large swings of the bottleneck state
over short (~RTT) time periods (dctcp has adjustable gain - G - to
address this.

Thus my ballpark estimate is, that SCE - on average - will operate at
higher Q utilization points compared to DCTCP/L4S, that is, with higher
queueing latency.

I would love to discuss the three pieces of SCE (AQM marking strategy,
Congestion Control loop, and signaling) separate from each other first,
before we wade into certain implementation details - like how to convey
the signal back and forth.

Best regards,
    Richard

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 18 Nov 2019 09:22:46 +0800

> On 18 Nov, 2019, at 8:52 am, Scheffenegger, Richard <[email-masked]> wrote:
> 

[snip]

> the signal back and forth.

On the contrary, I consider the signalling method to be the most important aspect of SCE.  The marking strategies and congestion control algorithms applied using this signalling are interesting and potentially useful, but the critical aspect is providing an extra congestion signal without breaking RFC-3168 compatibility.

There's no fundamental reason why the same marking strategies and congestion control algorithms as L4S can't be applied with SCE signalling, with equivalent performance - *except* that the backwards compatibility problems with existing Internet traffic and infrastructure (as Jake just helpfully outlined) would be solved.

I believe DCTCP made a fundamental error in deciding to redefine CE, and that's the problem that L4S is presently running into.  We do have (since IETF-104 @ Prague) an alternative version of DCTCP using SCE signalling, and that could illustrate a starting point for merging the two experiments.  I believe that would solve an awful lot of problems at a stroke.

 - Jonathan Morton

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Nov 2019 10:19:15 +0800

Hi Jonathan,

 > I believe DCTCP made a fundamental error in deciding to redefine CE,
and that's the problem that L4S is presently running into.  We do have
(since IETF-104 @ Prague) an alternative version of DCTCP using SCE
signalling, and that could illustrate a starting point for merging the
two experiments.  I believe that would solve an awful lot of problems at
a stroke.

Being in a position of having no immediate control over the ECN marking
strategy, and having to reuse existing silicon's RED implementation,
that choice of DCTCP was IMHO reasonable. (Also, IMHO it is not
realistic to see a timely implementation of more modern AQMs in very
high speed chipsets - but others would be in a better position to
discuss, if the SCE codepoint transitions could be implemented with
little effort in those asics).

I agree that this was not a choice that lends itself to good, backwards
compatible interoperability. As such, a clean slate approach (such as
SCE) is more free in using "proper" codepoints. However, that allowed
the immediate deployment using existing RED AQM (and an additonal
classifier so that non-DCTCP is not using the queue with the aggressive
marking).

However, because of the different reaction of the CC (1/cwnd vs
1/sqrt(cwnd) ), these two will not coexist with each other in the same
(non-FQ) queue, correct?

Best regards,
    Richard

---

From: "Black, David" <[email-masked]>
Date: Mon, 18 Nov 2019 02:32:19 +0000

and Roni's interpretation is close to the chairs' intent:

> [Roni] My reading of the text was that while LS4 was adopted by the WG the
> usage of ECT(1) by LS4 should not be the reason for not adopting SCE. The
> decision should be on the merit of the SCE. The usage of ECT(1) is a separate
> issue

A small clarification is to insert one word: "... should not be the *procedural* reason ..."

In other words, the proposed use of ECT(1) by L4S does not bar the WG from considering other possible uses of ECT(1) - in particular, WG discussion of possible adoption of the SCE draft will not be prohibited by the chairs for that reason.  This is a procedural statement only, not a technical statement - in particular, a technical view that there is no reasonable way for L4S and SCE to coexist as simultaneous/concurrent experiments on the public Internet is a possible technical rationale for opposing WG adoption of the SCE draft as part of that WG discussion.

Thanks, --David

> From: Roni Even (A) <[email-masked]>
> Sent: Sunday, November 17, 2019 7:28 PM
> To: Bob Briscoe; [email-masked]
> Cc: Rodney W. Grimes; [email-masked]
> Subject: RE: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-
> sce
> 
> 
> [EXTERNAL EMAIL]
> 
> >
> > tsvwg Chairs,
> >
> >
> [Roni] My reading of the text was that while LS4 was adopted by the WG the
> usage of ECT(1) by LS4 should not be the reason for not adopting SCE. The
> decision should be on the merit of the SCE. The usage of ECT(1) is a separate
> issue
> 
> >
> >
> >
> > Bob
> >
> >
> > --

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 18 Nov 2019 04:38:30 +0200

> 1/sqrt(cwnd) ), these two will not coexist with each other in the same

It's the same class of problem as having plain RFC-3168 compliant traffic
in the same single queue as SCE traffic, regardless of which response to
SCE is chosen.  The same solutions should apply:

- Dropping or RFC-3168 marking AQMs will cause the same congestion response
in Not-ECT, RFC-3168, DCTCP-SCE and ELR-SCE flows, so they will coexist
naturally.  This is also true of dumb FIFOs.  So the problem only manifests
when actively upgrading the middlebox to perform SCE marking.

- Adding FQ at the same time as adding SCE marking solves the fairness
problem, and has its own benefits - and costs.

- CNQ offers a way to limit the extent to which SCE flows give way to other
traffic, as well as allowing sparse traffic to bypass the queue, with
minimal added complexity compared to a FIFO AQM.  As a halfway house
between a FIFO and true FQ, this might be a good choice for high capacity
deployments, especially where persistent saturation is expected to be rare.

- Jonathan Morton

---

From: G Fairhurst <[email-masked]>
Date: Mon, 18 Nov 2019 11:03:24 +0800

The phrase: "is not an automatic barrier to WG adoption" - is true, but 
I would expect there to be a barrier to *immediate* adoption.

Thw WG has a chartered work item, following a BOF and adoption 
procedure. The Chairs work with the AD to manage the chartered work 
items, so I expect there will be no immediate change to the milestones 
(list of adopted drafts).

To clarify my own Chair position, I would not expect a WG to consider 
lightly starting a second deployment experiment in parallel using the 
same set of codepoints.

I think it is helpful to consider questions such as the following:

- Level of interest in performing the experiments and expected 
implementation/deployment.
- Understand how two parallel deployment experiments can co-exist.
- Understand how someone knows which experiment act on a particular flow.
- Document a pathway forward, should one (or both) experiments conclude.

Gorry

On 18/11/2019, 10:32, Black, David wrote:
>> From: Roni Even (A)<[email-masked]>

---

From: Kyle Rose <[email-masked]>
Date: Mon, 18 Nov 2019 11:31:53 +0800

> lightly starting a second deployment experiment in parallel using the

I'll offer a counterpoint as a former co-chair of tcpinc, the early history
of which this work area increasingly resembles.

When there are two competing proposals for the same deliverable (in this
case, high-fidelity congestion signaling) such that rough consensus does
not seem obviously forthcoming, the right approach may very well be to
adopt both and see which pans out.

If multiple experimental uses of the ECT(1) codepoint are not deployable
simultaneously, this might suggest withholding publication of any
experimental RFC making use of that codepoint until rough consensus is
achieved, which would suggest a longer period of evaluation and comparison
in synthetic environments.

OTOH, if the two experiments are deployable simultaneously (because the
consequences of conflict are not dire), perhaps an experimental RFC
outlining success criteria for evaluation of the two approaches would be
helpful in breaking the logjam.

What I don't want to see are variants of the sunk cost fallacy or
preference given to one experiment over the other for reasons other than
consensus based on demonstrated technical superiority. I've witnessed too
much of that on this mailing list over the past several months.

Kyle

---

From: Luca Muscariello <[email-masked]>
Date: Mon, 18 Nov 2019 09:37:02 +0100

Hi,

I've followed the different discussions on the list on this topic and, IMHO,
it would be highly desirable to let the SCE proposal move forward in the WG.

The effects of the coexistence of different classes of applications in the
same traffic mix
seem not explored very well so far, and answers based on DSCP or coupled
queueing systems
with non predictable performance raised even more questions and worries.

Traffic isolation is an important topic in this whole discussion and I
noticed
different proposals have been recently proposed with announced running code
for testing such
as

https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-01

It would make sense to know more about the different solutions in terms of
isolation
and see if they can provide predictable performance and at which
implementation
and operational cost.
Nonetheless, it would be important to also know what happens when isolation
is not in place.

IMHO, It would be difficult to understand why the WG would refuse fresh
energies
coming from people willing to do actual work on the topic.

I'm not doing any work on SCE but I'd be ready to spend some time to review
results and documents,
if that helps.

Regards
Luca
:wq

On Thu, Nov 14, 2019 at 2:50 PM Rodney W. Grimes <[email-masked]>
wrote:

> It is our intent to ask for adoption by the TSVWG of
> draft-morton-tsvwg-sce (
> https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the
> authors in order to adopt the SCE draft.   This will include surveying the
> room in Singapore (e.g., who has read this
>  draft?).
>
> to be addressed by the WG if the SCE draft is adopted, and hence is in
> scope for discussion of this adoption request
> ..  In particular, absence of a coexistence plan (e.g., to deal with the
> different uses of the ECT(1) codepoint by L4S and SCE) is not an automatic
> barrier to WG adoption of the SCE draft.
>
> particular, draft-grimes-tcpm-tcpsce is likely to be inc

---

From: Loganaden Velvindron <[email-masked]>
Date: Mon, 18 Nov 2019 12:49:28 +0400

On Monday, November 18, 2019, Luca Muscariello <[email-masked]> wrote:

> different proposals have been recently proposed with announced running
> code for testing such
> as
>
> Nonetheless, it would be important to also know what happens when
> isolation is not in place.
>

I'm also in favour of adoption. I'm also willing to review.

>
> I'm not doing any work on SCE but I'd be ready to spend some time to
> review results and documents,
> if that helps.
>
> Regards
> Luca
> :wq
>
>
>> draft-morton-tsvwg-sce (https://tools.ietf.org/html/
>> draft-morton-tsvwg-sce-01) during the IETF/106 Singapore TSVWG session.
>>
>>
>> ...  In particular, absence of a coexistence plan (e.g., to deal with the

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 18 Nov 2019 12:41:25 +0000

Hi Luca,

>> The effects of the coexistence of different classes of applications in the same traffic mix
>> seem not explored very well so far, and answers based on DSCP or coupled queueing systems
>> Traffic isolation is an important topic in this whole discussion

I agree that this is an important topic to be discussed / debated, but I don’t know if we will soon get consensus on this matter. I myself was a once a proponent of FQ. It is simple, strict fair and eliminates a lot of todays hurdles that prevent progress on congestion control. Why did I change my mind? Discussing with people it seems that it has some problems too. Some I learned and can quickly list:

  *   It removes the responsibility from the congestion controller to be fair to other flows, and moves it to the network (another hot potato that is passed?). This might look a good feature now, but will make it impossible to ever move the responsibility back to the CCs (due to backwards compatibility)
  *   It requires general support on all bottlenecks to be usable, or an indication from the network that it is safe to assume isolation, or another migration strategy.
  *   Perfection in throughput sharing is not what we need. Optimally we want smaller flows to get priority, and longer flows to almost scavenge leftover throughput. The short flows complete faster and the longer are not taking longer (as they had to share the bandwidth anyway). This is something that can be achieved by sensing other flows when there is no isolation.
  *   It does not support lesser-than-best-effort/LEDBAT/Scavenger flows as it cannot detect peer pressure due to the isolation. The congestion signals (delay, drop, ECN, …) are not coupled anymore.
  *   It does not support more-than-best-effort (deadline aware, CBR, TCP-friendly, …) flows anymore for the same reason
  *   It does cost a price, that (I learned in the meantime) not everybody is willing to pay…

For this reason I think it is a bad idea to couple it to the low latency discussion ongoing.
It does make the challenge for congestion controls more difficult, but I think we have a good traction in the L4S context. Also a large part of the SCE work is very useful and reusable in the scope of L4S, or could be refocused in the scope of L4S if the non-isolation challenge is taken. I think allowing both isolated and non-isolated bottlenecks to exist, allows also to use both camps’ experience and enthusiasm to work on the common goal to deploy DCTCP-like traffic on the Internet.

Regards,
Koen.

From: tsvwg <[email-masked]> On Behalf Of Luca Muscariello
Sent: Monday, November 18, 2019 9:37 AM
To: Rodney W. Grimes <[email-masked]>
Cc: tsvwg IETF list <[email-masked]>
Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

Hi,

The effects of the coexistence of different classes of applications in the same traffic mix
seem not explored very well so far, and answers based on DSCP or coupled queueing systems
with non predictable performance raised even more questions and worries.

Traffic isolation is an important topic in this whole discussion and I noticed
different proposals have been recently proposed with announced running code for testing such
as

It would make sense to know more about the different solutions in terms of isolation
and see if they can provide predictable performance and at which implementation
and operational cost.
Nonetheless, it would be important to also know what happens when isolation is not in place.

IMHO, It would be difficult to understand why the WG would refuse fresh energies
coming from people willing to do actual work on the topic.

I'm not doing any work on SCE but I'd be ready to spend some time to review results and documents,
if that helps.

Regards
Luca
:wq

On Thu, Nov 14, 2019 at 2:50 PM Rodney W. Grimes <[email-masked]<mailto:[email-masked]>> wrote:
Hello tsvwg list members,

(2) Coexistence of the L4S and SCE experiments is a concern that will need to be addressed by the WG if the SCE draft is adopted, and hence is in scope for discussion of this adoption request
...  In particular, absence of a coexistence plan (e.g., to deal with the different uses of the ECT(1) codepoint by L4S and SCE) is not an automatic barrier to WG adoption of the SCE draft.

Regards,
--
Rod Grimes                                                 [email-masked]<mailto:[email-masked]>

---

From: Luca Muscariello <[email-masked]>
Date: Mon, 18 Nov 2019 14:35:12 +0100

Dear Koen,

I did not mention FQ and I did not have it in mind when talking about
isolation
and predictable performance.

I do not think that QoS can be solved by just one single mechanism.
There are many, including diffserv.

If someone thinks that QoS is going to be solved using a single
mechanism, there may be a lot of disappointment eventually.

It looks to me, that performance of the mechanisms currently on the
table are not well understood and not backed by data from real world
experiments.

Considering that many people are available to do actual work to
answer many of the unanswered questions, I would tend to welcome and
support
and not discourage that.

Regards,
Luca

On Mon, Nov 18, 2019 at 1:41 PM De Schepper, Koen (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> I agree that this is an important topic to be discussed / debated, but I
> don’t know if we will soon get consensus on this matter. I myself was a
> once a proponent of FQ. It is simple, strict fair and eliminates a lot of
> todays hurdles that prevent progress on congestion control. Why did I
> change my mind? Discussing with people it seems that it has some problems
> too. Some I learned and can quickly list:
>
>    - It removes the responsibility from the congestion controller to be
>    fair to other flows, and moves it to the network (another hot potato that
>    is passed?). This might look a good feature now, but will make it
>    impossible to ever move the responsibility back to the CCs (due to
>    backwards compatibility)
>    - It requires general support on all bottlenecks to be usable, or an
>    indication from the network that it is safe to assume isolation, or another
>    migration strategy.
>    - Perfection in throughput sharing is not what we need. Optimally we
>    want smaller flows to get priority, and longer flows to almost scavenge
>    leftover throughput. The short flows complete faster and the longer are not
>    taking longer (as they had to share the bandwidth anyway). This is
>    something that can be achieved by sensing other flows when there is no
>    isolation.
>    - It does not support lesser-than-best-effort/LEDBAT/Scavenger flows
>    as it cannot detect peer pressure due to the isolation. The congestion
>    signals (delay, drop, ECN, …) are not coupled anymore.
>    - It does not support more-than-best-effort (deadline aware, CBR,
>    TCP-friendly, …) flows anymore for the same reason
>    - It does cost a price, that (I learned in the meantime) not everybody
>    is willing to pay…
>
>
>
> It does make the challenge for congestion controls more difficult, but I
> think we have a good traction in the L4S context. Also a large part of the
> SCE work is very useful and reusable in the scope of L4S, or could be
> refocused in the scope of L4S if the non-isolation challenge is taken. I
> think allowing both isolated and non-isolated bottlenecks to exist, allows
> also to use both camps’ experience and enthusiasm to work on the common
> goal to deploy DCTCP-like traffic on the Internet.
>
>
>
> Regards,
>
> Koen.
>
>
>
>
>
> *From:* tsvwg <[email-masked]> *On Behalf Of * Luca Muscariello
> *Sent:* Monday, November 18, 2019 9:37 AM
> *To:* Rodney W. Grimes <[email-masked]>
> *Cc:* tsvwg IETF list <[email-masked]>
> *Subject:* Re: [tsvwg] Requesting TSVWG adoption of SCE
> draft-morton-tsvwg-sce
>
>
>
> Hi,
>
>
>