From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp106.iad3a.emailsrvr.com (smtp106.iad3a.emailsrvr.com [173.203.187.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6BA563B2A4 for ; Sun, 17 Mar 2019 14:07:15 -0400 (EDT) Received: from smtp30.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp30.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 314AB38AC; Sun, 17 Mar 2019 14:07:15 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp30.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp30.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 29B3B38AE; Sun, 17 Mar 2019 14:07:15 -0400 (EDT) Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp30.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F16C938AC; Sun, 17 Mar 2019 14:07:14 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sun, 17 Mar 2019 14:07:15 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app17.wa-webapps.iad3a (Postfix) with ESMTP id DEACEE0049; Sun, 17 Mar 2019 14:07:14 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 17 Mar 2019 14:07:14 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sun, 17 Mar 2019 14:07:14 -0400 (EDT) From: "David P. Reed" To: "Vint Cerf" Cc: "Holland, Jake" , "Mikael Abrahamsson" , "ecn-sane@lists.bufferbloat.net" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190317140714000000_23746" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: 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> Message-ID: <1552846034.909628287@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC 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:07:15 -0000 ------=_20190317140714000000_23746 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AVint -=0A =0ABBR is the end-to-end control logic that adjusts the source= rate to match the share of the bolttleneck link it should use.=0A =0AIt de= pends on getting reliable current congestion information via packet drops a= nd/or ECN.=0A =0ASo the proposal by these guys (not the cable guys) is an a= ttempt to improve the quality of the congestion signal inserted by the rout= er with the bottleneck outbound link.=0A =0ATHe cable guys are trying to ge= t a "private" field in the IP header for their own use.=0A =0A =0A-----Orig= inal Message-----=0AFrom: "Vint Cerf" =0ASent: Saturday, M= arch 16, 2019 5:57pm=0ATo: "Holland, Jake" =0ACc: "Mik= ael Abrahamsson" , "David P. Reed" ,= "ecn-sane@lists.bufferbloat.net" , "bloat"= =0ASubject: Re: [Ecn-sane] [Bloat] [iccrg] Fw= d: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackato= n at IETF104=0A=0A=0A=0Awhere does BBR fit into all this?=0Av=0A=0A=0AOn Sa= t, Mar 16, 2019 at 5:39 PM Holland, Jake <[ jholland@akamai.com ]( mailto:j= holland@akamai.com )> wrote:On 2019-03-15, 11:37, "Mikael Abrahamsson" <[ s= wmike@swm.pp.se ]( mailto:swmike@swm.pp.se )> wrote:=0A L4S has a much = better possibility of actually getting deployment into the =0A wider In= ternet packet-moving equipment than anything being talked about =0A her= e. Same with PIE as opposed to FQ_CODEL. I know it's might not be as =0A = good, but it fits better into actual silicon and it's being proposed by = =0A people who actually have better channels into the people setting ha= rd =0A requirements.=0A=0A I suggest you consider joining them inst= ead of opposing them.=0A=0A=0A Hi Mikael,=0A=0A I agree it makes sense that= fq_anything has issues when you're talking=0A about the OLT/CMTS/BNG/etc.,= and I believe it when you tell me PIE=0A makes better sense there.=0A=0A B= ut fq_x makes great sense and provides real value for the uplink in a=0A ho= me, small office, coffee shop, etc. (if you run the final rate limit=0A on = the home side of the access link.) I'm thinking maybe there's a=0A disconn= ect here driven by the different use cases for where AQMs can go.=0A=0A The= thing is, each of these is the most likely congestion point at=0A differen= t times, and it's worthwhile for each of them to be able to=0A AQM (and mar= k packets) under congestion.=0A=0A One of the several things that bothers m= e with L4S is that I've seen=0A precious little concern over interfering wi= th the ability for another=0A different AQM in-path to mark packets, and be= cause it changes the=0A semantics of CE, you can't have both working at the= same time unless=0A they both do L4S.=0A=0A SCE needs a lot of details fil= led in, but it's so much cleaner that it=0A seems to me there's reasonably = obvious answers to all (or almost all) of=0A those detail questions, and be= cause the semantics are so much cleaner,=0A it's much easier to tell it's n= on-harmful.=0A=0A =0A=0A But as you also said so well in anot= her thread, this is important. ("The=0A last unicorn", IIRC.) How much do= es it matter if there's a feature that=0A has value today, but only until R= ACK is widely deployed? If you were=0A convinced RACK would roll out every= where within 3 years and SCE would=0A produce better results than L4S over = the following 15 years, would that=0A change your mind?=0A=0A It would for = me, and that's why I'd like to see SCE explored before=0A making a call. I= think at its core, it provides the same thing L4S does=0A (a high-fidelity= explicit congestion signal for the sender), but with=0A much cleaner seman= tics that can be incrementally added to congestion=0A controls that people = are already using.=0A=0A Granted, it still remains to be seen whether SCE i= n practice can match=0A the results of L4S, and L4S was here first. But it= seems to me L4S comes=0A with some problems that have not yet been examine= d, and that are nicely=0A dodged by a SCE-based approach.=0A=0A If L4S real= ly is as good as they seem to think, I could imagine getting=0A behind it, = but I don't think that's proven yet. I'm not certain, but=0A all the compa= rative analyses I remember seeing have been from more or=0A less the same t= eam, and I'm not convinced they don't have some=0A misaligned incentives of= their own.=0A=0A I understand a lot of work has gone into L4S, but this mo= ve to jump it=0A from interesting experiment to de-facto standard without a= more critical=0A review that digs deeper into some of the potential deploy= ment problems=0A has me concerned.=0A=0A If it really does turn out to be g= ood enough to be permanent, I'm not=0A opposed to it, but I'm just not conv= inced that it's non-harmful, and my=0A default position is that the cleaner= solution is going to be better in=0A the long run, if they can do the same= job.=0A=0A It's not that I want it to be a fight, but I do want to end up = with the=0A best solution we can get. We only have the one internet.=0A=0A= Just my 2c. =0A=0A -Jake=0A=0A=0A _______________________________________= ________=0A Ecn-sane mailing list=0A[ Ecn-sane@lists.bufferbloat.net ]( mai= lto:Ecn-sane@lists.bufferbloat.net )=0A[ https://lists.bufferbloat.net/list= info/ecn-sane ]( https://lists.bufferbloat.net/listinfo/ecn-sane )=0A-- =0A= =0A=0ANew postal address:=0AGoogle=0A=0A1875 Explorer Street, 10th Floor=0A= Reston, VA 20190 ------=_20190317140714000000_23746 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Vint -

=0A

 

=0A

BBR is the end-to-end contro= l logic that adjusts the source rate to match the share of the bolttleneck = link it should use.

=0A

 

=0A

It depends on getting reliable current congestion information via pac= ket drops and/or ECN.

=0A

 

=0A

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 t= he bottleneck outbound link.

=0A

 

=0A

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

=0A

 

=0A

 

=0A

-----Original Message-----From: "Vint Cerf" <vint@google.com>
Sent: Saturday, March 16= , 2019 5:57pm
To: "Holland, Jake" <jholland@akamai.com>
Cc:= "Mikael Abrahamsson" <swmike@swm.pp.se>, "David P. Reed" <dpreed@= deepplum.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.buffe= rbloat.net>, "bloat" <bloat@lists.bufferbloat.net>
Subject: R= e: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimen= tation of TCP Prague/L4S hackaton at IETF104

=0A
=0A
where does BBR fit into all this?= =0A
v
=0A
=0A
=0A
=0A
On Sat, Mar 16, 2019 at 5:39 PM Holland, Jake = <jholland@akamai.com> wrot= e:
=0A
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
  &= nbsp; wider Internet packet-moving equipment than anything being talked abo= ut
    here. Same with PIE as opposed to FQ_CODEL. I know = it's might not be as
    good, but it fits better into act= ual silicon and it's being proposed by
    people who actu= ally have better channels into the people setting hard
   = requirements.

    I suggest you consider joining the= m instead of opposing them.


Hi Mikael,

I agre= e it makes sense that fq_anything has issues when you're talking
abou= t 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 rea= l 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.)&n= bsp; I'm thinking maybe there's a
disconnect here driven by the diffe= rent use cases for where AQMs can go.

The thing is, each of the= se is the most likely congestion point at
different times, and it's w= orthwhile 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 becaus= e 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 det= ails 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 que= stions, and because the semantics are so much cleaner,
it's much easi= er to tell it's non-harmful.

<aside regarding=3D"non-harmful= ">
The point you raised in another thread about reordering is most= ly
well-taken, and a good counterpoint to the claim "non-harmful rela= tive
to L4S".

To me it seems sad and dumb that switches e= nded up trying to make
ordering guarantees at cost of switching perfo= rmance, 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.
<= br /> So why isn't it in all the receivers' NIC or OS (where it would rende= r
the switch's ordering efforts moot) instead of in all the switches?=

I'm guessing the answer is a competition trap for the switch v= endors,
plus "with ordering goes faster than without, when you benchm= ark the
switch with typical load and current (non-RACK) receivers".
If that's the case, it seems like the drive for a competitive ad= vantage
caused deployment of a packet ordering workaround in the wron= g 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 d= one,
and the L4S approach gives switches a flag that can double as pr= oof that
RACK is there on the receiver, so they can stop trying to or= der those
packets.

So point granted, I understand and agr= ee there's a cost to abandoning
that advantage.
</aside><= br />
But as you also said so well in another thread, this is importa= nt.  ("The
last unicorn", IIRC.)  How much does it matter i= f there's a feature that
has value today, but only until RACK is wide= ly deployed?  If you were
convinced RACK would roll out everywhe= re within 3 years and SCE would
produce better results than L4S over = the following 15 years, would that
change your mind?

It w= ould for me, and that's why I'd like to see SCE explored before
makin= g 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 L= 4S, and L4S was here first.  But it seems to me L4S comes
with s= ome problems that have not yet been examined, and that are nicely
dod= ged by a SCE-based approach.

If L4S really is as good as they s= eem to think, I could imagine getting
behind it, but I don't think th= at's proven yet.  I'm not certain, but
all the comparative analy= ses 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 mo= ve to jump it
from interesting experiment to de-facto standard withou= t a more critical
review that digs deeper into some of the potential = deployment problems
has me concerned.

If it really does t= urn 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 positio= n 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 f= ight, 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=0A
=0A
--
=0A
= =0A
New postal address:=0A
Google
=0A
1875 Exp= lorer Street, 10th Floor
=0A
Reston, VA 20190
=0A
=0A=0A
=0A
 ------=_20190317140714000000_23746--