From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: Dave Taht <dave.taht@gmail.com>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Ecn-sane] sce materials from ietf
Date: Fri, 29 Nov 2019 14:58:30 -0800 (PST) [thread overview]
Message-ID: <201911292258.xATMwUuu018462@gndrsh.dnsmgr.net> (raw)
In-Reply-To: <201911292255.xATMt2vN018446@gndrsh.dnsmgr.net>
> > there are no minutes posted.
> >
> > https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-81-some-congestion-experienced-00
> >
> > https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-some-congestion-experienced-in-tcp-00
>
> The above 2 decks are identical. Jonathan did not get any time
> during tsvwg, so I reposted the whole deck to tcpm, in which I
> also did not get any time to present.
Correction, Jonathan did get 6 minutes, iirc.
>
> BUT, and that is a all caps BUT, good stuff happened for SCE
> forward progress during the meetinhgs none the less. We did
> infact get an announcement that we have asked for adoption of
> draft-morton-tsvwg-sce, with a 25 hand count on who has read
> the draft, which by my rough estimate was more than 1/4 of
> the room.
>
> During the tcpm session the issues around allocation of bit 7
> for AccECN may of been worked out, that draft (AccECN) is becoming
> a proposed standard, which can do the IANA allocation, and Mira
> at least continues to affirm that bit 7 can be used for other
> purposes after an AccECN negotiation failure when it falls back
> to RFC3168 ECN, so we (SCE) believe we do have a path forward on
> our alternate use for bit 7.
>
> The tsvwg chairs, and the work group itself now needs to discuss
> the 2 experiment problem, the conflicts and compatibilities between
> the 2, and just how to deal with the situation.
>
> YOUR (that being all the list members of ecn-sane, and the larger
> bufferbloat community) inputs and helps are highly desired in
> this process.
>
> The SCE teams possition is that L4S is fundementally flawed in
> its use of the ECT(1) code point as a "Traffic Classifier" since
> that leads to the end nodes telling the network the traffic is
> special, aka treat me differently than any other traffic, and
> is likely to lead to abuse, which may possibly lead to bleaching
> of the code point, which would be bad for everyone.
>
> It would be much nicer to use this last code point, 1/2 a bit,
> for a high fidelity signal from the network to the receiver
> of the level of congestion in a fully backwards to RFC3168
> way.
>
> We (the SCE team) also feel that L4S is overly complex and continues
> to grow complexity as problems with it are exposed. (Recently it
> has become apparent that protecton from RFC3168 behavior is needed,
> and thus a new proposal and a new chunk of code are being
> developed to deal with this issue.
>
>
> > Dave T?ht
> --
> Rod Grimes rgrimes@freebsd.org
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
>
>
--
Rod Grimes rgrimes@freebsd.org
next prev parent reply other threads:[~2019-11-29 22:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 20:08 [Bloat] " Dave Taht
2019-11-29 21:20 ` Jonathan Morton
2019-11-29 23:10 ` alex.burr
2019-11-30 1:39 ` Jonathan Morton
2019-11-30 7:27 ` [Bloat] [Ecn-sane] " Sebastian Moeller
2019-11-30 14:32 ` Jonathan Morton
2019-11-30 15:42 ` Sebastian Moeller
2019-11-30 17:11 ` Jonathan Morton
2019-12-02 5:38 ` Dave Taht
2019-12-02 7:54 ` Sebastian Moeller
2019-12-02 9:57 ` Pete Heist
2019-11-30 22:17 ` Carsten Bormann
2019-11-30 22:23 ` Jonathan Morton
2019-12-01 16:35 ` Sebastian Moeller
2019-12-01 16:54 ` Jonathan Morton
2019-12-01 19:03 ` Sebastian Moeller
2019-12-01 19:27 ` Jonathan Morton
2019-12-01 19:32 ` Sebastian Moeller
2019-12-01 20:30 ` Jonathan Morton
2019-12-01 17:30 ` Rodney W. Grimes
2019-12-01 19:17 ` Sebastian Moeller
2019-12-02 5:10 ` Dave Taht
2019-12-02 7:18 ` Sebastian Moeller
2019-12-01 18:06 ` David Collier-Brown
2019-11-29 22:55 ` Rodney W. Grimes
2019-11-29 22:58 ` Rodney W. Grimes [this message]
2019-11-30 2:37 ` [Bloat] " Dave Taht
2019-11-30 3:10 ` [Bloat] [Ecn-sane] " 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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201911292258.xATMwUuu018462@gndrsh.dnsmgr.net \
--to=4bone@gndrsh.dnsmgr.net \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
/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