From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by huchra.bufferbloat.net (Postfix) with ESMTP id 51022200588 for ; Sat, 14 Jan 2012 03:07:41 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Jan 2012 11:07:38 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Jan 2012 11:07:38 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1326539257136; Sat, 14 Jan 2012 11:07:37 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.80.91]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q0EB7YI9020577; Sat, 14 Jan 2012 11:07:35 GMT Message-Id: <201201141107.q0EB7YI9020577@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 14 Jan 2012 11:06:46 +0000 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> <201201051753.q05Hqx78012678@bagheera.jungle.bt.co.uk> <201201090538.q095cYa4031441@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jan 2012 11:07:38.0713 (UTC) FILETIME=[BA34C490:01CCD2AC] Cc: bloat Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired! 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: Sat, 14 Jan 2012 11:07:41 -0000 Dave, [There's a lot in yr email, but I have to finish=20 day job-stuff (well actually that's a misnomer -=20 it's now become day, night and weekend job). So here's a v quick response: ] Yes, FQ can (and generally does) improve matters,=20 particularly when the AQM isn't good*. But FQ=20 prevents all attempts by end-systems to do a lot=20 better (e.g. uTP). uTP is only the start of what=20 could be done. FQ aims for isolation between=20 flows, and consequently removes the signals hosts=20 would need to be able to do a lot better. The catch-22 is that a network node can't rely on=20 hosts to do a lot better. The upshot: FQ does a=20 not-so-good job in case hosts don't do any job at=20 all, but it completely prevents hosts doing a brilliant job... ...unless FQ starts making exceptions using DPI,=20 then we start down an ultimately fruitless cul de=20 sac where apps identify themselves as a protocol=20 that is brilliant, without actually behaving=20 brilliantly, just to take advantage of the=20 exceptions built into the HG,.. yada yada. I need to understand your points about why=20 wireless is different - will read closer, think=20 and respond again when I have more time. Bob * (can you clarify what experiment the plot you=20 linked to is illustrating - you've not made it=20 clear what you're comparing between) At 07:26 11/01/2012, Dave Taht wrote: >On Mon, Jan 9, 2012 at 6:38 AM, Bob Briscoe wrote: > > Dave, > > > You're conflating removal of standing queues with bandwidth allocation.= The > > former is a problem in HGs and hosts. The latter isn't a problem in HGs= and > > hosts. > >I've been trying to understand your point here more fully. > >1) removal of standing queues is a problem in HGs and hosts > >On the host side, the standing queue problem is something that happens= often >in wireless in particular. > >Additionally you ship packets around in aggregates, and those >aggregates can be delayed, lost, or rescheduled. > >FQ reduces the damage done when packets are being bulk shipped in this >way. > >http://www.teklibre.com/~d/bloat/ping_log.ps > >(This graph also shows that the uncontrolled > device driver queue depth totals about 50ms in this case) > >In the benchmarks I've been running against wireless, even on fairly light >loads, FQ reduces bursty packet loss, tcp resets, and the like.= Statistically >it's difficult to 'see', and I'm trying to come=20 >up with better methods to do so >besides double-blind A/B testing and *most importantly* > >trying to convince more people to discard their biases and >actually try the code. > >Or take a look at some packet captures. > >As for the AP side, you have both a bandwidth allocation and FQ problem >with wireless, compounded by the packet aggregation problem. > >Still a big problem in either wireless case is a=20 >need to expire old packets and >manage the depth of the queue based on the actual bandwidth between >two devices actually available at that instant of time. Otherwise you >get nonsense like 10+ second ping times. > >So as for managing the the overall length of the standing queues, >conventional AQM techniques, such as RED, blue, etc... apply but >as for coping with the bursty nature of wireless in particular (and TSO'd >streams) FQ helps break up the container-loads into manageable pieces. > >2) Bandwidth allocation isn't a problem in HGs and hosts. > >On hosts, on wired, it is not a problem. On wireless, see above. > >On home gateways, which run uplinks at anywhere between 128KB/sec >in parts of the world, to 1Mbit in others, & 4Mbit fairly typical on cable, >it's a huge problem. Regardless of any level of queue management >as applied above (fq and aqm), the only decent way known to deal with >'bufferbloat' on bad devices beyond the HG, is to limit your own bandwidth >to what you've measured as below what the messed up edge provider >is providing.... > >and manage it from there across the needs of your site, where various >AQM and FQ technologies can make a dent in your own problems. > >So perhaps I misunderstood your point here? > >Certainly the use model of the internet has changed significantly >and TCP is in dire need of viable complementary protocols such >as ledbat, etc. I also happen to like hipl, and enjoy but am befuddled >by the ccn work on-going. > >And certainly I look forward to seeing less edge devices misbehaving >with excessive buffering and lack of AQM. > >I'd like in particular, a contractual model - I mean, you are typically= buying >'x bandwidth' as part of your ISP contract - >made available to correctly, and automatically provision downstream= devices. > >something as simple as a extension to dhcp would nice, >or something like parsable data for 'http://whatsmydarnbandwidth.myisp.com' >would help. > >Having to infer the available bandwidth and amount of buffering >with tools such as shaperprobe is useful but a poor second to >a contractual model for a baseline and tighter feedback loops >for ongoing management. > >-- >Dave T=E4ht >SKYPE: davetaht >US Tel: 1-239-829-5608 >FR Tel: 0638645374 >http://www.bufferbloat.net ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20