From: Dave Taht <dave.taht@gmail.com>
To: Vint Cerf <vint@google.com>
Cc: "Holland, Jake" <jholland@akamai.com>,
bloat <bloat@lists.bufferbloat.net>,
"ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104
Date: Sat, 16 Mar 2019 15:03:15 -0700 [thread overview]
Message-ID: <CAA93jw5_upJi16jO_sxTi05LWKqszv5UAMdg-0zTp_Ps0aYf-g@mail.gmail.com> (raw)
In-Reply-To: <CAHxHggfPCqf9biCDmHMqA38=4y6gY6pFtRVMjMrrzYfLyRBf-g@mail.gmail.com>
Dear Vint:
BBR, along with all "non ect_1 sending L4S compatable" transports,
gets relegated to the dualpi "Classic" queue.
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/
On Sat, Mar 16, 2019 at 2:57 PM Vint Cerf <vint@google.com> wrote:
>
> where does BBR fit into all this?
>
> v
>
>
> On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake <jholland@akamai.com> wrote:
>>
>> On 2019-03-15, 11:37, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>> L4S has a much better possibility of actually getting deployment into the
>> wider Internet packet-moving equipment than anything being talked about
>> here. Same with PIE as opposed to FQ_CODEL. I know it's might not be as
>> good, but it fits better into actual silicon and it's being proposed by
>> people who actually have better channels into the people setting hard
>> requirements.
>>
>> I suggest you consider joining them instead of opposing them.
>>
>>
>> Hi Mikael,
>>
>> I agree it makes sense that fq_anything has issues when you're talking
>> about the OLT/CMTS/BNG/etc., and I believe it when you tell me PIE
>> makes better sense there.
>>
>> But fq_x makes great sense and provides real value for the uplink in a
>> home, small office, coffee shop, etc. (if you run the final rate limit
>> on the home side of the access link.) I'm thinking maybe there's a
>> disconnect here driven by the different use cases for where AQMs can go.
>>
>> The thing is, each of these is the most likely congestion point at
>> different times, and it's worthwhile for each of them to be able to
>> AQM (and mark packets) under congestion.
>>
>> One of the several things that bothers me with L4S is that I've seen
>> precious little concern over interfering with the ability for another
>> different AQM in-path to mark packets, and because it changes the
>> semantics of CE, you can't have both working at the same time unless
>> they both do L4S.
>>
>> SCE needs a lot of details filled in, but it's so much cleaner that it
>> seems to me there's reasonably obvious answers to all (or almost all) of
>> those detail questions, and because the semantics are so much cleaner,
>> it's much easier to tell it's non-harmful.
>>
>> <aside regarding="non-harmful">
>> The point you raised in another thread about reordering is mostly
>> well-taken, and a good counterpoint to the claim "non-harmful relative
>> to L4S".
>>
>> To me it seems sad and dumb that switches ended up trying to make
>> ordering guarantees at cost of switching performance, because if it's
>> useful to put ordering in the switch, then it must be equally useful to
>> put it in the receiver's NIC or OS.
>>
>> So why isn't it in all the receivers' NIC or OS (where it would render
>> the switch's ordering efforts moot) instead of in all the switches?
>>
>> I'm guessing the answer is a competition trap for the switch vendors,
>> plus "with ordering goes faster than without, when you benchmark the
>> switch with typical load and current (non-RACK) receivers".
>>
>> If that's the case, it seems like the drive for a competitive advantage
>> caused deployment of a packet ordering workaround in the wrong network
>> location(s), out of a pure misalignment of incentives.
>>
>> RACK rates to fix that in the end, but a lot of damage is already done,
>> and the L4S approach gives switches a flag that can double as proof that
>> RACK is there on the receiver, so they can stop trying to order those
>> packets.
>>
>> So point granted, I understand and agree there's a cost to abandoning
>> that advantage.
>> </aside>
>>
>> But as you also said so well in another thread, this is important. ("The
>> last unicorn", IIRC.) How much does it matter if there's a feature that
>> has value today, but only until RACK is widely deployed? If you were
>> convinced RACK would roll out everywhere within 3 years and SCE would
>> produce better results than L4S over the following 15 years, would that
>> change your mind?
>>
>> It would for me, and that's why I'd like to see SCE explored before
>> making a call. I think at its core, it provides the same thing L4S does
>> (a high-fidelity explicit congestion signal for the sender), but with
>> much cleaner semantics that can be incrementally added to congestion
>> controls that people are already using.
>>
>> Granted, it still remains to be seen whether SCE in practice can match
>> the results of L4S, and L4S was here first. But it seems to me L4S comes
>> with some problems that have not yet been examined, and that are nicely
>> dodged by a SCE-based approach.
>>
>> If L4S really is as good as they seem to think, I could imagine getting
>> behind it, but I don't think that's proven yet. I'm not certain, but
>> all the comparative analyses I remember seeing have been from more or
>> less the same team, and I'm not convinced they don't have some
>> misaligned incentives of their own.
>>
>> I understand a lot of work has gone into L4S, but this move to jump it
>> from interesting experiment to de-facto standard without a more critical
>> review that digs deeper into some of the potential deployment problems
>> has me concerned.
>>
>> If it really does turn out to be good enough to be permanent, I'm not
>> opposed to it, but I'm just not convinced that it's non-harmful, and my
>> default position is that the cleaner solution is going to be better in
>> the long run, if they can do the same job.
>>
>> It's not that I want it to be a fight, but I do want to end up with the
>> best solution we can get. We only have the one internet.
>>
>> Just my 2c.
>>
>> -Jake
>>
>>
>> _______________________________________________
>> Ecn-sane mailing list
>> Ecn-sane@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/ecn-sane
>
>
>
> --
> New postal address:
> Google
> 1875 Explorer Street, 10th Floor
> Reston, VA 20190
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
next prev parent reply other threads:[~2019-03-16 22:03 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM0PR07MB48198660539171737E4CCAB1E0730@AM0PR07MB4819.eurprd07.prod.outlook.com>
[not found] ` <d91a6a71-5898-9571-2a02-0d9d83839615@bobbriscoe.net>
2019-03-15 10:46 ` [Bloat] " Dave Taht
2019-03-15 13:01 ` Sebastian Moeller
2019-03-15 14:06 ` Dave Taht
2019-03-15 15:52 ` Sebastian Moeller
2019-03-15 17:01 ` [Bloat] [Ecn-sane] " David P. Reed
2019-03-15 17:45 ` Sebastian Moeller
2019-03-15 18:36 ` Mikael Abrahamsson
2019-03-15 19:23 ` Sebastian Moeller
2019-03-15 19:32 ` Jonathan Morton
2019-03-15 19:44 ` David P. Reed
2019-03-15 20:13 ` Jonathan Morton
2019-03-15 23:43 ` David P. Reed
2019-03-16 1:26 ` Jonathan Morton
2019-03-16 7:38 ` Sebastian Moeller
2019-03-16 18:56 ` Michael Richardson
2019-03-15 20:28 ` Jonathan Foulkes
2019-03-15 20:31 ` Dave Taht
2019-03-15 23:45 ` David P. Reed
2019-03-16 9:42 ` Michael Welzl
2019-03-16 10:08 ` Sebastian Moeller
2019-03-16 10:23 ` Nils Andreas Svee
2019-03-16 14:55 ` Jonathan Foulkes
2019-03-16 21:38 ` Holland, Jake
2019-03-16 21:57 ` Vint Cerf
2019-03-16 22:03 ` Dave Taht [this message]
2019-03-16 22:05 ` Holland, Jake
2019-03-17 18:07 ` David P. Reed
2019-03-17 18:05 ` Vint Cerf
2019-03-19 1:06 ` Bob Briscoe
2019-03-19 3:18 ` Dave Taht
2019-03-20 19:04 ` Holland, Jake
2019-03-20 19:58 ` Stephen Hemminger
2019-03-20 20:05 ` Holland, Jake
[not found] ` <5C9296E1.4010703@erg.abdn.ac.uk>
2019-03-20 20:00 ` [Bloat] [tsvwg] " Holland, Jake
2019-03-20 20:05 ` Jonathan Morton
2019-03-20 20:55 ` Greg White
2019-03-20 22:12 ` Sebastian Moeller
2019-03-20 22:31 ` Jonathan Morton
2019-03-20 22:56 ` Sebastian Moeller
2019-03-20 23:03 ` Jonathan Morton
2019-03-20 23:11 ` Holland, Jake
2019-03-20 23:28 ` Jonathan Morton
2019-03-21 8:15 ` [Bloat] [Ecn-sane] [tsvwg] " Mikael Abrahamsson
2019-03-21 8:31 ` Mikael Abrahamsson
2019-03-20 23:30 ` [Bloat] [tsvwg] [Ecn-sane] " Sebastian Moeller
2019-03-21 0:15 ` Holland, Jake
2019-03-21 0:41 ` Holland, Jake
2019-03-20 21:48 ` [Bloat] " Greg White
2019-03-20 21:56 ` Jonathan Morton
2019-03-20 22:38 ` Holland, Jake
2019-03-20 22:56 ` Greg White
2019-03-20 23:29 ` Bob Briscoe
2019-03-20 23:51 ` Jonathan Morton
2019-03-21 6:04 ` Bob Briscoe
2019-03-21 7:46 ` Jonathan Morton
2019-03-21 8:02 ` Bob Briscoe
2019-03-21 8:49 ` Bless, Roland (TM)
2019-03-21 13:24 ` Bob Briscoe
2019-03-22 12:53 ` Bless, Roland (TM)
2019-03-25 2:47 ` Bob Briscoe
2019-03-21 8:45 ` Sebastian Moeller
2019-03-24 20:15 ` alex.burr
2019-03-25 1:34 ` Bob Briscoe
2019-03-27 17:52 ` Alex Burr
2019-03-19 4:44 ` Greg White
2019-03-19 5:35 ` Jonathan Morton
2019-03-19 5:52 ` Greg White
2019-03-19 7:10 ` Jonathan Morton
2019-03-19 8:07 ` Sebastian Moeller
2019-03-19 8:50 ` Sebastian Moeller
2019-03-19 23:59 ` Dave Taht
2019-03-20 10:17 ` Sebastian Moeller
2019-03-16 22:03 ` Jonathan Morton
2019-03-16 22:09 ` Sebastian Moeller
2019-03-17 14:06 ` Mikael Abrahamsson
2019-03-17 17:37 ` Loganaden Velvindron
2019-03-17 17:40 ` Toke Høiland-Jørgensen
2019-03-17 17:44 ` Mikael Abrahamsson
2019-03-17 18:00 ` Dave Taht
2019-03-17 19:38 ` Rodney W. Grimes
2019-03-17 20:50 ` Luca Muscariello
2019-03-17 21:51 ` Toke Høiland-Jørgensen
2019-03-18 4:26 ` Mikael Abrahamsson
2019-03-16 4:04 ` Jonathan Morton
2019-03-16 4:51 ` Dave Taht
2019-03-15 18:07 ` Mikael Abrahamsson
2019-03-15 14:27 ` [Bloat] " Jonathan Morton
2019-03-15 14:44 ` Sebastian Moeller
2019-03-15 15:49 ` Jonathan Morton
2019-03-15 21:34 ` Wesley Eddy
2019-03-22 18:28 [Bloat] [Ecn-sane] " Victor Hou
2019-03-23 8:02 ` Roland Bless
2019-03-23 8:54 ` Luca Muscariello
2019-03-23 10:02 ` Mikael Abrahamsson
2019-03-23 15:03 ` Jonathan Morton
2019-03-23 19:52 ` Roland Bless
2019-03-23 15:19 ` Roland Bless
2019-03-23 17:16 ` Mikael Abrahamsson
2019-03-23 19:45 ` Roland Bless
2019-03-23 17:48 ` Michael Welzl
2019-03-23 18:31 ` Luca Muscariello
2019-03-23 18:40 ` Mikael Abrahamsson
2019-03-23 19:11 ` Michael Welzl
2019-03-23 21:04 ` Luca Muscariello
2019-03-23 19:55 ` Roland Bless
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=CAA93jw5_upJi16jO_sxTi05LWKqszv5UAMdg-0zTp_Ps0aYf-g@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=jholland@akamai.com \
--cc=vint@google.com \
/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