From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E4F0A3B29E for ; Sat, 16 Mar 2019 17:57:15 -0400 (EDT) Received: by mail-oi1-x232.google.com with SMTP id i21so6775701oib.11 for ; Sat, 16 Mar 2019 14:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4YCf4D7FYiQsRQh+RJDn3j3pP7xCdP+AnQR/XeaDrxs=; b=TK3207q4eSl88oiPFO+PZ0O4pyGYWOKeYeG/d6NrR7jwD2Lcq0pS2bXPkx0c00JZTc xBfC8zbWQZ5OJcPGxuEzJgpbko48wJHfsIui/Nmw5fsmnnNj12z9Q6Mvah1EpqzjkOAx eLhDH6BWXbeRhb7TiaUj5t894c0b1jQ8ukj7Ua3ixtx9+3si/HoTSoj+HHiNT/dcOcXn JKRhKyu/KRVe2jj4f5XvnPTrVPmBVtuB1E+CxdX/wN2TLhnive5yk50yn2G/EMWCoEVV RW5xMmr2s5OD4PgHjsZMHbGCYPR85baj7BQ05g1TEPsL91DTJ7rP/Zwsblve78EcwCj9 9d7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4YCf4D7FYiQsRQh+RJDn3j3pP7xCdP+AnQR/XeaDrxs=; b=pBeYkebhLm5Izm4kfnZO2WGPmvt/HiDEhbjOtPNal3AVw4ib0Kin12PRGIv/z3QMew 6q0vF9BXWfDwVd6GoIdS5QIvUop9SqTdOKQFf8oIg9846pNdTzV8+GybjAfh9x2fWF/B eyBOUulsRRoS/lVsDNwRgEj+JvqMXlpX2H/DVszx7p01ZStXtzFXff8tCKgv7hqcN6x8 Iw5r59HM2vkj79mISQym2pWJxxTrbkdM5P3vLApbNH/kZXNNYIwrLnHSqeJuvBXW/ULd UlwTHrZmA0wz3dtfgJtOBu5nWxUWqC6vyESeXK0l2Fj4/LeLGPIX3WGwxH36niyujrSS /zGA== X-Gm-Message-State: APjAAAUZfhrxxc3vjByqSEZ87RMKcEo/AMp0G0zebEBohXeSrdfHehLe 5XMYl7Y6t2JMtIfPRd/fDn4JHbhzx9VEDIu2cqmdDQ== X-Google-Smtp-Source: APXvYqzP8T6VjY3LRjNxqlk7TuvBmlNlxETH7HNFbkBOc4MgzyscKm/w2bjeupIbDd8Lqt0fV+cHtJKTLsAPsX+8ZVY= X-Received: by 2002:aca:aa55:: with SMTP id t82mr5710237oie.29.1552773435202; Sat, 16 Mar 2019 14:57:15 -0700 (PDT) MIME-Version: 1.0 References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> In-Reply-To: <7029DA80-8B83-4775-8261-A4ADD2CF34C7@akamai.com> From: Vint Cerf Date: Sat, 16 Mar 2019 17:57:03 -0400 Message-ID: To: "Holland, Jake" Cc: Mikael Abrahamsson , "David P. Reed" , "ecn-sane@lists.bufferbloat.net" , bloat Content-Type: multipart/alternative; boundary="00000000000006236c05843d3d6f" X-Mailman-Approved-At: Wed, 27 Mar 2019 14:44:32 -0400 Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:57:16 -0000 --00000000000006236c05843d3d6f Content-Type: text/plain; charset="UTF-8" where does BBR fit into all this? v On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake wrote: > On 2019-03-15, 11:37, "Mikael Abrahamsson" 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. > > > > 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 --00000000000006236c05843d3d6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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, &q= uot;Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
=C2=A0 =C2=A0 L4S has a much better possibility of actually getting deploym= ent into the
=C2=A0 =C2=A0 wider Internet packet-moving equipment than anything being ta= lked about
=C2=A0 =C2=A0 here. Same with PIE as opposed to FQ_CODEL. I know it's m= ight not be as
=C2=A0 =C2=A0 good, but it fits better into actual silicon and it's bei= ng proposed by
=C2=A0 =C2=A0 people who actually have better channels into the people sett= ing hard
=C2=A0 =C2=A0 requirements.

=C2=A0 =C2=A0 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<= br> 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.)=C2=A0 I'm thinking maybe there= 9;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<= br> seems to me there's reasonably obvious answers to all (or almost all) o= f
those detail questions, and because the semantics are so much cleaner,
it's much easier to tell it's non-harmful.

<aside regarding=3D"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 ren= der
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.=C2=A0 (&= quot;The
last unicorn", IIRC.)=C2=A0 How much does it matter if there's a f= eature that
has value today, but only until RACK is widely deployed?=C2=A0 If you were<= br> 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.=C2=A0 I think at its core, it provides the same thing L4S do= es
(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.=C2=A0 But it seems to me L4S co= mes
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.=C2=A0 I'm not c= ertain, 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, an= d 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.=C2=A0 We only have the one internet.

Just my 2c.=C2=A0

-Jake


_______________________________________________
Ecn-sane mailing list
Ecn-san= e@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane


--
New postal address:
Google<= br>
1875 Explorer Street, 10th Floor
Reston, VA 20190
--00000000000006236c05843d3d6f--