Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
* [Ecn-sane] ect(1) queue selector question
@ 2021-02-20 19:27 Dave Taht
  2021-02-21  1:51 ` Sebastian Moeller
  0 siblings, 1 reply; 10+ messages in thread
From: Dave Taht @ 2021-02-20 19:27 UTC (permalink / raw)
  To: ECN-Sane

I note that I have done my best to stay out of this for a while, so
long that I (thankfully) mis-remember various aspects of the debate.
Today I have a question about l4s vs SCE as it's come up again.

l4s uses both a dscp codepoint AND ect(1) to indicate dctcp style
congestion control
is in use, and also can dump other protocols into that queue lacking
any ecn markings.

SCE proposes to use ect(1) as an indicator of some congestion and does
not explictly
require a dscp codepoint in a FQ'd implementation.

Do I have that right? Now, my question was, simply, in MPLS or X-G are
they out of bits, and
that's why they want to use up this one in L4S?

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

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [Ecn-sane] ect(1) queue selector question
@ 2021-03-09  0:36 Pete Heist
  2021-03-09  1:18 ` Dave Taht
  0 siblings, 1 reply; 10+ messages in thread
From: Pete Heist @ 2021-03-09  0:36 UTC (permalink / raw)
  To: ECN-Sane

Sorry for reviving an old thread as I haven't been on this list in a
while:

> > SCE proposes to use ect(1) as an indicator of some congestion and
does
> > not explictly
> > require a dscp codepoint in a FQ'd implementation.
> 	Pretty much. I do think that a demonstration using an
> additional DSCP to create a similar HOV lane for SCE would have gone
> miles in convincing people in the WG that L4S might really not be as
> swell as its proponents argue, IMHO it won the day more with its
> attractive promise of low latency for all instead of what it
delivers.

On that, I don't think any of us knows how things will end up or how
long it will take to get there...

I do agree that the interim meeting leading up to the codepoint
decision could have gone better. Everything went great until it came to
how to deploy SCE in a small number of queues. We had dismissed the
idea of using DSCP, because we thought it would be panned for its poor
traversal over the Internet. That may still have been the case, but it
also may have worked if sold right. We thought that AF alone might be
enough to get past that part, but it wasn't.

We already implemented a two-queue design that uses DSCP, but either
there wasn't much interest, or we didn't sell it enough. Plus, for
those who demand a two queue solution that requires no flow awareness
at all, DSCP alone may not get you there, because you still need some
reasonably fair way to schedule the two queues. So that might have been
the next line of criticism. Scheduling in proportion to the number of
flows each queue contains is one effective way to do that, but that
requires at least some concept of a flow. Perhaps there's another way
that doesn't introduce too much RTT unfairness, but I'm not sure.

In our defense, there was already a lot of support built up for L4S,
and stepping in front of that was like stepping in front of a freight
train no matter what we did. I think we've made a decent argument in
the most recent version of the SCE draft that ECN is a "network
feature" which carries higher risks than drop-based signaling, and
warrants the requirement for unresponsive flow mitigation, for
starters. That of course requires some level of flow awareness, which
then makes various queueing designs possible. And, there may still be
deployment possibilities with DSCP, as Rodney mentioned.

Anyway, there's progress being made on SCE, with some new ideas and
improvements to testing tools coming along.

Pete



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-03-09 15:38 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-20 19:27 [Ecn-sane] ect(1) queue selector question Dave Taht
2021-02-21  1:51 ` Sebastian Moeller
2021-02-21 17:14   ` Rodney W. Grimes
2021-02-21 20:26     ` Dave Taht
2021-03-09  0:36 Pete Heist
2021-03-09  1:18 ` Dave Taht
2021-03-09  9:11   ` Pete Heist
2021-03-09 15:19   ` Rodney W. Grimes
2021-03-09 15:28     ` Dave Taht
2021-03-09 15:38       ` Rodney W. Grimes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox