From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (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 4B0E63B25E for ; Tue, 20 Sep 2016 16:27:43 -0400 (EDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1E0E2C04EE; Tue, 20 Sep 2016 16:27:43 -0400 (EDT) Received: from app10.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0DB7AC03E1; Tue, 20 Sep 2016 16:27:43 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app10.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.7); Tue, 20 Sep 2016 16:27:43 -0400 Received: from reed.com (localhost [127.0.0.1]) by app10.wa-webapps.iad3a (Postfix) with ESMTP id EE908C1959; Tue, 20 Sep 2016 16:27:42 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Tue, 20 Sep 2016 16:27:42 -0400 (EDT) Date: Tue, 20 Sep 2016 16:27:42 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" Cc: "Jonathan Morton" , "cerowrt-devel@lists.bufferbloat.net" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <1474146692.035424358@mobile.rackspace.com> X-Auth-ID: dpreed@reed.com Message-ID: <1474403262.975213436@apps.rackspace.com> X-Mailer: webmail/12.5.3-RC Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 20:27:43 -0000 I constantly see the claim that >50% of transmitted data on the Internet ar= e streaming TV. However, the source seems to be as hard to nail down as the= original claim that >50% of Internet traffic was pirated music being sent = over bittorrent.=0A=0AYou recently repeated that statistic as if it were a = verified fact.=0A=0AI remember that in the early days of WiFi DSSS availabi= lity the claim was repeatedly made from podiums at conferences I attended t= hat "the amount of WiFi in parking lots on Sand Hill Road [then the locatio= n of most major Silicon Valley VC firms] had made it so that people could n= ot open their car doors with their remote keys". This was not intended as = hyperbole or a joke - I got into the habit of asking the speakers how they = knew this, and they told me that their VC friends had all had it happen to = them...=0A=0APropaganda consists of clever stories that "sound plausible" a= nd which are spread by people because they seem to support something they *= wish* were true for some reason.=0A=0AI suspect that this 70% number is mor= e propaganda of this sort.=0A=0AIn case it is not obvious, the beneficiarie= s of this particular propaganda are those who want to claim various things = - that the Internet is now just TV broadcasting and thus should be treated = that way (Internet Access Providers should select "channels", charge for al= lowing them through to customers, improving the "quality of programming" an= d censoring anything offensive, as just one example)=0A=0ASo I am extremely= curious as to an actual source of such a number, how it was measured, and = how its validity can be tested reproducibly.=0A=0ASome may remember that th= e original discovery of "bufferbloat" was due to the fact that Comcast depl= oyed Sandvine gear in its network to send RST packets for any connections t= hat involved multiple concurrent TCP uploads (using DPI technology to guess= what TCP connections to RST and the right header data to put on the RST pa= ckets).=0A=0ATheir argument for why they *had* to do that was that they "ha= d data" that said that their network was being overwhelmed by bittorrent pi= rates.=0A=0AIn fact, the problem was bufferbloat - DOCSIS 2.0 gear that was= designed to fail miserably under any intense upload. The part about bitto= rrent piracy was based on claimed measurements that apparently were never i= n fact performed about the type of packets that were causing the problem.= =0A=0AHence: I know it is a quixotic thing on my part, but the scientist in= me wants to see the raw data and see the methods used to obtain it.=0A=0AI= have friends who actually measure Internet traffic (kc claffy, for example= ), and they do a darn good job. The difficulty in getting data that could = provide the 70% statistic is *so high* that it seems highly likely that no = such measurement has ever been done, in fact.=0A=0ABut if someone has done = such a measurement (directly or indirectly), defining their terms and metho= dology sufficiently so that it is a reproducible result, it would probably = merit an award for technical excellence.=0A=0AOtherwise, please, please, pl= ease don't lend your name to promulgating nonsense, even if it seems useful= to argue your case. Verify your sources.=0A=0A=0A=0AOn Monday, September = 19, 2016 4:26pm, "Dave Taht" said:=0A=0A> ok, I got B= BR built with net-next + v2 of the BBR patch. If anyone=0A> wants .deb file= s for ubuntu, I can put them up somewhere. Some quick=0A> results:=0A> =0A>= http://blog.cerowrt.org/post/bbrs_basic_beauty/=0A> =0A> I haven't got aro= und to testing cubic vs bbr in a drop tail=0A> environment, my take on matt= ers is with fq (fq_codel) in place, bbr=0A> will work beautifully against c= ubic, and I just wanted to enjoy the=0A> good bits for a while before teari= ng apart the bad... and staying on=0A> fixing wifi.=0A> =0A> I had to go an= d rip out all the wifi patches to get here... as some=0A> code landed to th= e ath10k that looks to break everything there, so=0A> need to test that as = a baseline first - and I wanted to see if=0A> sch_fq+bbr did anything to ma= ke the existing ath9k driver work any=0A> better.=0A> =0A> =0A> =0A> =0A> O= n Sat, Sep 17, 2016 at 2:33 PM, Dave Taht wrote:=0A>>= On Sat, Sep 17, 2016 at 2:11 PM, wrote:=0A>>> The assum= ption that each flow on a path has a minimum, stable RTT fails in=0A>>> wi= reless and multi path networks.=0A>>=0A>> Yep. But we're getting somewhere = serious on having stabler RTTs for=0A>> wifi, and achieving airtime fairnes= s.=0A>>=0A>> http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png= =0A>>=0A>>>=0A>>>=0A>>>=0A>>> However, it's worth remembering two things: b= uffering above a certain level is=0A>>> never an improvement,=0A>>=0A>> whi= ch BBR recognizes by breaking things up into separate bandwidth and=0A>> RT= T analysis phases.=0A>>=0A>>>and flows through any shared router come and g= o quite frequently on the real=0A>>> Internet.=0A>>=0A>> Very much why I re= main an advocate of fq on the routers is that your=0A>> congestion algorith= m for your particular flow gets more independent of=0A>> the other flows, a= nd ~0 latency and jitter for sparse flows is=0A>> meaningful.=0A>>=0A>>> Th= us RTT on a single flow is not a reasonable measure of congestion. ECN mark= ing=0A>>> is far better and packet drops are required for bounding time to = recover after=0A>>> congestion failure.=0A>>=0A>> Aww, give the code a chan= ce, it's only been public for a day! I=0A>> haven't even got it to compile = yet!=0A>>=0A>> I think it is a *vast* improvement over cubic, and possibly = the first delay=0A>> sensitive tcp that can compete effectively with it. I'= m dying to test=0A>> it thoroughly,=0A>> but have a whole bunch other patch= es for wifi in my queue.=0A>>=0A>>>=0A>>> The authors suffer from typical n= aivete by thinking all flows are for file=0A>>> transfer and that file tran= sfer throughput is the right basic perspective,=0A>>> rather than end to en= d latency/jitter due to sharing, and fair sharing=0A>>> stability.=0A>>=0A>= > While I agree *strongly* that lots of short flows is how the internet=0A>= > mostly operates, (I used to cite a paper on this a lot)=0A>>=0A>> a huge = number of bulk flows exist that has been messing up the short=0A>> flows. I= think the number was something 70% of internet traffic has=0A>> become net= flix-like. *anything* e2e that can reduce the negative=0A>> impact of the b= ig fat flows on everything else is a win.=0A>>=0A>>=0A>>>=0A>>>=0A>>>=0A>>>= -----Original Message-----=0A>>> From: "Jonathan Morton" =0A>>> Sent: Sat, Sep 17, 2016 at 4:11 pm=0A>>> To: "Maciej Soltysiak= " =0A>>> Cc: "Maciej Soltysiak" ,=0A>>> "cerowrt-devel@lists.bufferbloat.net" =0A>>> Subject: Re: [Cerowrt-devel] BBR congestion control algorit= hm for TCP=0A>>> innet-next=0A>>>=0A>>>=0A>>>> On 17 Sep, 2016, at 21:34, M= aciej Soltysiak wrote:=0A>>>>=0A>>>> Cake and fq_codel work on all packets= and aim to signal packet loss early to=0A>>>> network stacks by dropping; = BBR works on TCP and aims to prevent packet loss.=0A>>>=0A>>> By dropping, = *or* by ECN marking. The latter avoids packet loss.=0A>>>=0A>>> - Jonatha= n Morton=0A>>>=0A>>> _______________________________________________=0A>>> = Cerowrt-devel mailing list=0A>>> Cerowrt-devel@lists.bufferbloat.net=0A>>> = https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A>>>=0A>>>=0A>>> ____= ___________________________________________=0A>>> Cerowrt-devel mailing lis= t=0A>>> Cerowrt-devel@lists.bufferbloat.net=0A>>> https://lists.bufferbloat= .net/listinfo/cerowrt-devel=0A>>=0A>>=0A>>=0A>> --=0A>> Dave T=C3=A4ht=0A>>= Let's go make home routers and wifi faster! With better software!=0A>> htt= p://blog.cerowrt.org=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4ht=0A> Let's go = make home routers and wifi faster! With better software!=0A> http://blog.ce= rowrt.org=0A>