From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 4D8F93B2A4 for ; Sun, 17 Mar 2019 14:08:28 -0400 (EDT) Received: by mail-oi1-x22e.google.com with SMTP id e22so4110788oiy.0 for ; Sun, 17 Mar 2019 11:08:28 -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=mYl0s+oZqXybQihYoSbUNm02NMS+WfiT1bypsm0WFZ8=; b=TpRRmHqE5Vd9NnpFo27+5J0TCSKOMl1Xbjs6Nt59Xpt9yV5SpeK76xNhAdzMryDMMo ajR5sHIkI6UrcblY7RJESCba98HnVO52pX90zPAghU51yy+sOideZlR0WHtgaRtBvuKA v/faPn4AKHCaao1OOBjRRanXnWSt62+CyjZL45DdVPFy9yjCOsJTVbqSbqbysKawBhYF a4IbVsOyukHPCgS9vBmhPg8X6XwuwEw47PWw4PE4Hvp2TjM4dqSXlyhRXrKHfQ9YgDaP 6sqhq92WeeHN/yuMWz026G1xt5DJldwgTjvP/nwRZ2p6pzrhtKc+HGnjdDk9y+CqxKl2 Sjvw== 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=mYl0s+oZqXybQihYoSbUNm02NMS+WfiT1bypsm0WFZ8=; b=G6QKaTOFX+ZMMcihQUOlM6EoNYanPNxz8oX0jn6/j0uUH7SeREDkBle7+x/BZahgI0 Ml+fz3pcJ6z1zVb4EsqU3LbXjDtVW8B1Bxd8rotggJOVJxsDLK5oB7Gh9HYSa9a7NNNp ezksgLwDGxl3+25AGLvUEdBtXIl6og8zyUaBC/FNoAPMXzhKpzplYxyWzLw1kAQfNyF+ 1GVk4sQleVuK7ce3Xu8VHSS2kbf8KWuqnbibvoFaV4uFRp9R7XXKy6P68OwBx/fZaO6I IjZp4YOIArtYn9oqDORtcB+iFhKG2Ah5qK8nMHG1/hfYtQpFFWsQycRsbHaHTZTSakH2 OTTQ== X-Gm-Message-State: APjAAAU+3hc1Hn1/fbPc0DZEIAeoM7Ag7+wQc8aQK0jMoqGtk739XBH7 ML06r/b9wTi2a9oXvbTl8ODDs5mtX2behhAfoSFwAg== X-Google-Smtp-Source: APXvYqzUIQL2ZxSN3VNtjG/FaQSTayBYQtYbuMUoOQOBBH2eukxhZtDkMrRR2fhzgL9Vl2h4Hx5HAM+4JoNyJ4BW00w= X-Received: by 2002:aca:430b:: with SMTP id q11mr4324533oia.99.1552846107623; Sun, 17 Mar 2019 11:08:27 -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> <1552846034.909628287@apps.rackspace.com> In-Reply-To: <1552846034.909628287@apps.rackspace.com> From: Vint Cerf Date: Sun, 17 Mar 2019 14:05:25 -0400 Message-ID: To: "David P. Reed" Cc: "Holland, Jake" , Mikael Abrahamsson , "ecn-sane@lists.bufferbloat.net" , bloat Content-Type: multipart/alternative; boundary="000000000000a33e9c05844e28af" 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: Sun, 17 Mar 2019 18:08:28 -0000 --000000000000a33e9c05844e28af Content-Type: text/plain; charset="UTF-8" thanks, David - that's the information I was looking for. v On Sun, Mar 17, 2019 at 2:07 PM David P. Reed wrote: > Vint - > > > > BBR is the end-to-end control logic that adjusts the source rate to match > the share of the bolttleneck link it should use. > > > > It depends on getting reliable current congestion information via packet > drops and/or ECN. > > > > So the proposal by these guys (not the cable guys) is an attempt to > improve the quality of the congestion signal inserted by the router with > the bottleneck outbound link. > > > > THe cable guys are trying to get a "private" field in the IP header for > their own use. > > > > > > -----Original Message----- > From: "Vint Cerf" > Sent: Saturday, March 16, 2019 5:57pm > To: "Holland, Jake" > Cc: "Mikael Abrahamsson" , "David P. Reed" < > dpreed@deepplum.com>, "ecn-sane@lists.bufferbloat.net" < > ecn-sane@lists.bufferbloat.net>, "bloat" > Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation > and experimentation of TCP Prague/L4S hackaton at IETF104 > > 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 > -- New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 --000000000000a33e9c05844e28af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks, David - that's the information I was looking f= or.

v


On Sun, Mar 17, 2019 at 2:07 P= M David P. Reed <dpreed@deepplum.= com> wrote:

Vint -

=C2=A0=

BBR is= the end-to-end control logic that adjusts the source rate to match the sha= re of the bolttleneck link it should use.

=C2=A0=

It dep= ends on getting reliable current congestion information via packet drops an= d/or ECN.

=C2=A0=

So the= proposal by these guys (not the cable guys) is an attempt to improve the q= uality of the congestion signal inserted by the router with the bottleneck = outbound link.

=C2=A0=

THe ca= ble guys are trying to get a "private" field in the IP header for= their own use.

=C2=A0=

=C2=A0=

-----O= riginal Message-----
From: "Vint Cerf" <vint@google.com>
Sent: Saturday= , March 16, 2019 5:57pm
To: "Holland, Jake" <jholland@akamai.com>
C= c: "Mikael Abrahamsson" <swmike@swm.pp.se>, "David P. Reed" <dpreed@deepplum.com<= /a>>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.ne= t>, "bloat" <bloat@lists.bufferbloat.net>
Subject: Re: = [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentat= ion of TCP Prague/L4S hackaton at IETF104

where does BBR fit into all this?
v

On Sat, Mar 16, 2019 at 5:39 PM Holla= nd, Jake <jholl= and@akamai.com> wrote:
On 2019-03-15, 11:37, &qu= ot;Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
=C2=A0 =C2=A0 L4S has a muc= h better possibility of actually getting deployment into the
=C2=A0 = =C2=A0 wider Internet packet-moving equipment than anything being talked ab= out
=C2=A0 =C2=A0 here. Same with PIE as opposed to FQ_CODEL. I know i= t's might not be as
=C2=A0 =C2=A0 good, but it fits better into ac= tual silicon and it's being proposed by
=C2=A0 =C2=A0 people who a= ctually have better channels into the people setting 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
about the OLT= /CMTS/BNG/etc., and I believe it when you tell me PIE
makes better sens= e 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 fina= l rate limit
on the home side of the access link.)=C2=A0 I'm thinki= ng maybe there's a
disconnect here driven by the different use case= s for where AQMs can go.

The thing is, each of these is the most li= kely congestion point at
different times, and it's worthwhile for e= ach of them to be able to
AQM (and mark packets) under congestion.
<= br> One of the several things that bothers me with L4S is that I've see= n
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= 9;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 t= he 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 t= rying to make
ordering guarantees at cost of switching performance, bec= ause 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 wh= y 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?<= br>
I'm guessing the answer is a competition trap for the switch ve= ndors,
plus "with ordering goes faster than without, when you benc= hmark the
switch with typical load and current (non-RACK) receivers&quo= t;.

If that's the case, it seems like the drive for a competiti= ve advantage
caused deployment of a packet ordering workaround in the w= rong 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 t= hat
RACK is there on the receiver, so they can stop trying to order tho= se
packets.

So point granted, I understand and agree there'= s a cost to abandoning
that advantage.
</aside>

But a= s you also said so well in another thread, this is important.=C2=A0 ("= The
last unicorn", IIRC.)=C2=A0 How much does it matter if there&#= 39;s a feature that
has value today, but only until RACK is widely depl= oyed?=C2=A0 If you were
convinced RACK would roll out everywhere within= 3 years and SCE would
produce better results than L4S over the followi= ng 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 does
(a high= -fidelity explicit congestion signal for the sender), but with
much cle= aner semantics that can be incrementally added to congestion
controls t= hat 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 comes
with some problems that have = not yet been examined, and that are nicely
dodged by a SCE-based approa= ch.

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 certain, but
all the comparative analyses I remember seeing= have been from more or
less the same team, and I'm not convinced t= hey don't have some
misaligned incentives of their own.

I u= nderstand a lot of work has gone into L4S, but this move to jump it
fro= m interesting experiment to de-facto standard without a more critical
r= eview that digs deeper into some of the potential deployment problems
h= as 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 t= hat it's non-harmful, and my
default position is that the cleaner s= olution 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 en= d up with the
best solution we can get.=C2=A0 We only have the one inte= rnet.

Just my 2c.=C2=A0

-Jake


________________= _______________________________
Ecn-sane mailing list
Ecn-sane@lists.buffer= bloat.net
https://lists.bufferbloat.net/listin= fo/ecn-sane

--
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190


--
New postal address= :
Google
1875 Explorer Street, 10th Floor
Reston, VA = 20190
--000000000000a33e9c05844e28af--