Discussion of explicit congestion notification's impact on the Internet
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: Sebastian Moeller <moeller0@gmx.de>,
	ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] ect(1) queue selector question
Date: Sun, 21 Feb 2021 12:26:34 -0800	[thread overview]
Message-ID: <CAA93jw6xaOgMgPw8dDUQhxBLdOw4MDLUJKPczQza0cqx7NcKXQ@mail.gmail.com> (raw)
In-Reply-To: <202102211714.11LHElPj006827@gndrsh.dnsmgr.net>

Thx for the clarifications. What I meant by X-G was 3G, 4G, 5G.

On Sun, Feb 21, 2021 at 9:14 AM Rodney W. Grimes
<4bone@gndrsh.dnsmgr.net> wrote:
>
> Hello Dave, and Sebastian,
>
> > Hi Dave,
> >
> >
> > > On Feb 20, 2021, at 20:27, Dave Taht <dave.taht@gmail.com> wrote:
> > >
> > > 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.
> >
> >       Mmmh, according to the L4S internet drafts, L4S does not want to use a DSCP at all. Interestingly enough, Greg White is proposing a related internet draft about the NQB PHB and DSCP that sounds awfully like the missing DSCP in the L4S drafts. IMHO if the whole thing would be guarded behind a DSCP I would be less annoyed by the design and process of L4S....
>
> That is correct, the L4S proponents absolutely do not want anything to do with a DSCP and L4S.
> If they would of simply agreed that this was actually a good idea they could propbably be at deployment state now.... but they insist it is pointless to take this route due to the traveral problem.
>
> >
> > >
> > > 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.
>
> The original SCE design was without any mention of DSCP.  Since that pretty much stahled us in the battle with L4S there actually *IS* an SCE design that uses one or more DSCP.  This technically allows SCE to proceed forward on its own without any blessing from IETF so that we may gain some additional experience and data.  This *IS NOT* the ideal design, but I feel by taking this road we might gain ground.
>
> > > 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?
> >
> >       I do not think that MPLS folks are a driver in all of this, no? No idea what X-G is.
>
> We do not know fully all of there motivations for being so very insistant on doing it this way, only this way, and with no changes of any kind.  But they do seem very stuck on there design and unflexiable in any and all suggestions of change.
>
> > > --
> > > "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
>
> Regards,
> --
> Rod Grimes                                                 rgrimes@freebsd.org



-- 
"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

  reply	other threads:[~2021-02-21 20:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-20 19:27 Dave Taht
2021-02-21  1:51 ` Sebastian Moeller
2021-02-21 17:14   ` Rodney W. Grimes
2021-02-21 20:26     ` Dave Taht [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw6xaOgMgPw8dDUQhxBLdOw4MDLUJKPczQza0cqx7NcKXQ@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=4bone@gndrsh.dnsmgr.net \
    --cc=ecn-sane@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox