From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 06E1D21F2E0 for ; Thu, 21 Aug 2014 10:04:51 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id e131so6938100oig.40 for ; Thu, 21 Aug 2014 10:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rbtnSXAl+H1Mu3DlzAzMYkhzdP4q/zuoikDmm/m8ANs=; b=wQGtdBe6mzkN1wHhVWW0iZ0Lcewe2tdJRrConHfqtOQsFv0BY/zAgScbIMTNpCqLtS RzM4hTnFKn4d2t/fzENRm0J1lLld3F+B+Sel3CdLmOOvCiiLSBrGOJw1O+ZduyRJkTUs sa4o70M9i5AayBcfx1O5PX/kFi+6yQKGs+z2ro3eunNOC7pbyE5uEK5iW7dXH2sFSzHv OtQUMgrTOFNUj971wUMaoh6vZndsA/jgRWIUg6YHMDsKPu4CUStCFFEY+jmLsWTAxH+/ zTMV3H0NkKQP99W2ntUzfuemw0n4RjputE49p5RSEMi97D6gAU71079Ta7+/vyPtV5Aq d0bQ== MIME-Version: 1.0 X-Received: by 10.60.115.133 with SMTP id jo5mr56217654oeb.39.1408640690563; Thu, 21 Aug 2014 10:04:50 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Thu, 21 Aug 2014 10:04:50 -0700 (PDT) In-Reply-To: <96292B6B-F49D-4A8A-BD23-DD75399D8DA9@ifi.uio.no> References: <20140804124453.GA19478@ens-lyon.fr> <96292B6B-F49D-4A8A-BD23-DD75399D8DA9@ifi.uio.no> Date: Thu, 21 Aug 2014 12:04:50 -0500 Message-ID: From: Dave Taht To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Remy: Computer-Generated Congestion Control X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:04:52 -0000 On Thu, Aug 21, 2014 at 5:21 AM, Michael Welzl wrote: > Dave, > > About this point that I've seen you make repeatedly: > >> My biggest problem with all the work so far is that it starts with a >> constant baseline 150ms or 100ms RTT, and then try various algorithms >> over a wide range of bandwidths, and then elides that base RTT in all >> future plots. Unless you read carefully, you don't see that... >> >> The original bufferbloat experiment was at a physical RTT of 10ms, >> with bidirectional traffic flooding the queues in both directions, on >> an asymmetric network. I keep waiting for more experimenters to try >> that as a baseline experiment. > > > This sounds like a call for reality, when the point is to measure things = that matter to the system you're investigating. Heh. It is my wish, certainly, to see the remy concept extended to solving the problems I consider important. The prospect of merely warming my feet on a nice 80 core box for a week, and evaluating the results, is quite appealing. I'll gladly trade someone else's code, and someone else's compute time, for a vacation (or unemployment, if it works out!). Can arrange for a very hefty cluster to tackle this stuff also, if the code were public. I have encouraged keith to look into the netfpga.org project as a possible target for the rules being created by remy's algorithms. >E.g., if I'm investigating TCP, and I don't specifically work on ACK behav= ior (ACK congestion control or something like that), I usually don't care m= uch about the backwards traffic or the asymmetry. Yes it does influence the= measured RTT a bit, but then you argue for using a smaller base RTT where = the impact of this gets smaller too. > > What matters to the function of congestion controllers is the BDP, and th= e buffer size. Which varies based on the real physical RTT to the server. One of the biggest problems in nets today is that larger flow sources (CDNS, HAS(netflix)) keep moving closer and closer to the end node, with all the problems with tcp fairness that short RTTs induce on longer ones, like your radio flow blow. >As for real RTTs, I like pinging wwoz.org because it's a radio station in = New Orleans. I do sometimes listen to it, then I get traffic via a TCP conn= ection that has this RTT. Very real. My ping delay is consistently above 11= 0ms. I too use a low rate radio stream to measure the impact of other flows on my listening experience. I'd written this before the bufferbloat project got rolling, before I'd even met jim. http://nex-6.taht.net/posts/Did_Bufferbloat_Kill_My_Net_Radio/ ... haven't had a problem for 2 years now. :) Still do use the stream ripping thing for taking stuff on the road. > > On a side note, I can't help but mention that the "original bufferbloat e= xperiment" features ping over FQ... measuring ping all by itself, pretty mu= ch :-) Huh? The original bufferbloat experiments were against a comcast cable modem, and various other devices, lacking FQ entirely. there was a youtube video, a paper, (things like "daddy, why is the internet slow today" and various other resources. So the earliest stuff was "upload + ping + complaints about the network from the kids", and the later simultaneous up+down+ping abstraction was to get the kids out of the equation. I agree that up+down+ping is not as useful as we'd like now that FQ is on the table. I have been attempting to formalize where we are now, adding rigor based on those early benchmarks, with both netperf-wrapper's tcp_bidirectional test, the more advanced rrul and rtt_fairness tests, and a model in ns3. Given how much bloat we've killed elsewhere I would like to continue to improve these tests to properly show interactions with truly isochronous streams (there are several tests in netperf-wrapper now that leverage d-itg for that now (thx toke!), and more bursty yet rate limited flows like videoconferencing which we've been discussing the structure of with various members of the rmcat group. My complaint comes from seeing very low bandwidths and long rtts and short queue lengths used in materials used to explain bufferbloat, like this: https://www.udacity.com/wiki/cn/assignment5-buffer-bloat when the reality: 1) There is a double bump you see in tcp for example at truly excessive queue lengths). You also see truly terrible ramp up performance when competing data and ack flows. 2) the example assumes byte to packet length equivalence (100 packets =3D 150kb) which is completely untrue - 100 packets is in the range of 6.4kb-150kb - and a reason why we have much larger packet based queue lengths in the real world IS because of optimizing for acks, not data in commonly deployed equipment. If you want to test a byte based queue length, by all means (I have gradually come to the opinion that byte based packet queues are best), but test either packet or byte based queues under conditions that are ack dominated or data dominated, with both, preferably all scenarios. 3) it is at 1.5mbit, not the 5,10,100mbit speeds. Below 10mbits you see IW10 or IW4 effects, you see ssthresh not hit, and a variety of other tcp specific issues, rather than the generic bufferbloat problem. 4) the 20ms in that course is actually reasonable. :) I don't understand what the harm would have been to the student to use 1000 packets, and test up, down, and up + down, at 10 or 100Mbit. 5) I'd have liked it if the final experiment in the above course material switched to huge queue lengths (say for example, cisco's 2800 default for their 4500 line), or explained the real world situation better, so the takeaway was closer to the real size and scope of the problem. Anyway... Nearly every paper I've read make one or more of the above modifications to what I'd viewed as the original experiment, and I'd like to add rigor to the definitions of phrases floating around like "bufferbloat episode", and so on. > Michael > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article