From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: "Black, David" <David.Black@dell.com>,
"tsvwg@ietf.org" <tsvwg@ietf.org>,
"ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>,
Dave Taht <dave@taht.net>,
"De Schepper,
Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts
Date: Sat, 20 Jul 2019 00:03:57 +0200 [thread overview]
Message-ID: <0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de> (raw)
In-Reply-To: <803D9CA8-220E-4F98-9B8E-6CE2916C3100@gmail.com>
Hi Jonathan,
> On Jul 19, 2019, at 22:44, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 19 Jul, 2019, at 4:06 pm, Black, David <David.Black@dell.com> wrote:
>>
>> To be clear on what I have in mind:
>> o Unacceptable: All traffic marked with ECT(1) goes into the L4S queue, independent of what DSCP it is marked with.
>> o Acceptable: There's an operator-configurable list of DSCPs that support an L4S service - traffic marked with ECT(1) goes into the L4S queue if and only if that traffic is also marked with a DSCP that is on the operator's DSCPs-for-L4S list.
>
> I take it, in the latter case, that this increases the cases in which L4S endpoints would need to detect that they are not receiving L4S signals, but RFC-3168 signals. The current lack of such a mechanism therefore remains concerning. For comparison, SCE inherently retains such a mechanism by putting the RFC-3168 and high-fidelity signals on different ECN codepoints.
>
> So I'm pleased to hear that the L4S team will be at the hackathon with a demo setup. Hopefully we will be able to obtain comparative test results, using the same test scripts as we use on SCE, and also insert an RFC-3168 single queue AQM into their network to demonstrate what actually happens in that case. I think that the results will be illuminating for all concerned.
What I really would like to see, how L4S endpoints will deal with post-bottleneck ingress shaping by an RFC3168 -compliant FQ-AQM. I know the experts here deems this not even a theoretical concern, but I really really want to see data, that L4S flows will not crowd out the more reactive RFC3168 flows in that situation. This is the set-up quite a number of latency sensitive end-users actually use to "debloat" the internet and it would be nice to have real data showing that this is not a concern.
Best Regards
Sebastian
>
> - Jonathan Morton
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
next prev parent reply other threads:[~2019-07-19 22:04 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 0:01 [Ecn-sane] " Holland, Jake
2019-06-07 18:07 ` Bob Briscoe
2019-06-14 17:39 ` Holland, Jake
2019-06-19 14:11 ` Bob Briscoe
2019-07-10 13:55 ` Holland, Jake
2019-06-14 20:10 ` [Ecn-sane] [tsvwg] " Luca Muscariello
2019-06-14 21:44 ` Dave Taht
2019-06-15 20:26 ` [Ecn-sane] [tsvwg] CoIt'smments " David P. Reed
2019-06-19 1:15 ` [Ecn-sane] [tsvwg] Comments " Bob Briscoe
2019-06-19 1:33 ` Dave Taht
2019-06-19 4:24 ` Holland, Jake
2019-06-19 13:02 ` Luca Muscariello
2019-07-04 11:54 ` Bob Briscoe
2019-07-04 12:24 ` Jonathan Morton
2019-07-04 13:43 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-04 14:03 ` Jonathan Morton
2019-07-04 17:54 ` Bob Briscoe
2019-07-05 8:26 ` Jonathan Morton
2019-07-05 6:46 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-05 8:51 ` Jonathan Morton
2019-07-08 10:26 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-08 20:55 ` Holland, Jake
2019-07-10 0:10 ` Jonathan Morton
2019-07-10 9:00 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-10 13:14 ` Dave Taht
2019-07-10 17:32 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-17 22:40 ` Sebastian Moeller
2019-07-19 9:06 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-19 15:37 ` Dave Taht
2019-07-19 18:33 ` Wesley Eddy
2019-07-19 20:03 ` Dave Taht
2019-07-19 22:09 ` Wesley Eddy
2019-07-19 23:42 ` Dave Taht
2019-07-24 16:21 ` Dave Taht
2019-07-19 20:06 ` Black, David
2019-07-19 20:44 ` Jonathan Morton
2019-07-19 22:03 ` Sebastian Moeller [this message]
2019-07-20 21:02 ` Dave Taht
2019-07-21 11:53 ` Bob Briscoe
2019-07-21 15:30 ` [Ecn-sane] Hackathon tests Dave Taht
2019-07-21 15:33 ` [Ecn-sane] [tsvwg] Comments on L4S drafts Sebastian Moeller
2019-07-21 16:00 ` Jonathan Morton
2019-07-21 16:12 ` Sebastian Moeller
2019-07-22 18:15 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-22 18:33 ` Dave Taht
2019-07-22 19:48 ` Pete Heist
2019-07-25 16:14 ` De Schepper, Koen (Nokia - BE/Antwerp)
2019-07-26 13:10 ` Pete Heist
2019-07-26 15:05 ` [Ecn-sane] The state of l4s, bbrv2, sce? Dave Taht
2019-07-26 15:32 ` Dave Taht
2019-07-26 15:37 ` Neal Cardwell
2019-07-26 15:45 ` Dave Taht
2019-07-23 10:33 ` [Ecn-sane] [tsvwg] Comments on L4S drafts Sebastian Moeller
2019-07-21 12:30 ` Bob Briscoe
2019-07-21 16:08 ` Sebastian Moeller
2019-07-21 19:14 ` Bob Briscoe
2019-07-21 20:48 ` Sebastian Moeller
2019-07-25 20:51 ` Bob Briscoe
2019-07-25 21:17 ` Bob Briscoe
2019-07-25 22:00 ` Sebastian Moeller
2019-07-26 10:20 ` [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs Sebastian Moeller
2019-07-26 14:10 ` Black, David
2019-07-26 16:06 ` Sebastian Moeller
2019-07-26 19:58 ` Black, David
2019-07-26 21:34 ` Sebastian Moeller
2019-07-26 16:15 ` Holland, Jake
2019-07-26 20:07 ` Black, David
2019-07-26 23:40 ` Jonathan Morton
2019-08-07 8:41 ` Mikael Abrahamsson
2019-08-07 10:06 ` Mikael Abrahamsson
2019-08-07 11:57 ` Jeremy Harris
2019-08-07 12:03 ` Mikael Abrahamsson
2019-08-07 12:14 ` Sebastian Moeller
2019-08-07 12:25 ` Mikael Abrahamsson
2019-08-07 12:34 ` Jeremy Harris
2019-08-07 12:49 ` Mikael Abrahamsson
[not found] ` <5D34803D.50501@erg.abdn.ac.uk>
2019-07-21 16:43 ` [Ecn-sane] [tsvwg] Comments on L4S drafts Black, David
2019-07-21 12:30 ` Scharf, Michael
2019-07-19 21:49 ` Sebastian Moeller
2019-07-22 16:28 ` Bless, Roland (TM)
2019-07-19 17:59 ` Sebastian Moeller
2019-07-05 9:48 ` Luca Muscariello
2019-07-04 13:45 ` Bob Briscoe
2019-07-10 17:03 ` Holland, Jake
[not found] <HE1PR07MB4425603844DED8D36AC21B67C2110@HE1PR07MB4425.eurprd07.prod.outlook.com>
2019-06-14 18:27 ` Holland, Jake
[not found] ` <HE1PR07MB4425E0997EE8ADCAE2D4C564C2E80@HE1PR07MB4425.eurprd07.prod.outlook.com>
2019-06-19 12:59 ` Bob Briscoe
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=0079BC6B-4792-48ED-90D3-D9A69407F316@gmx.de \
--to=moeller0@gmx.de \
--cc=David.Black@dell.com \
--cc=chromatix99@gmail.com \
--cc=dave@taht.net \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=koen.de_schepper@nokia-bell-labs.com \
--cc=tsvwg@ietf.org \
/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