From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5F389200252 for ; Fri, 6 Jan 2012 09:43:05 -0800 (PST) Received: by qcsc20 with SMTP id c20so1402292qcs.16 for ; Fri, 06 Jan 2012 09:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/Gl1IyFW95BffAuL/SWJTwbi+jnHYuzlHKQ8yk43KVE=; b=ZO2zgX1kl1JsWBpNUtXPkbq6QHhQiylOW7/v/IrEPf1APbhejOqpek2gpQXWmuemYp JdZxV6uZibCxsEI18rOo/wOLZvL7JIB5YStXaFMAEAtaB7W/rfkQNHg/cbVlBUWneyEu AFqn8vgC7ZyfunqCExHs30a60g76Ka1MKHs6g= Received: by 10.224.116.16 with SMTP id k16mr6227543qaq.28.1325871782363; Fri, 06 Jan 2012 09:43:02 -0800 (PST) Received: from [192.168.1.5] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id fe5sm97942106qab.5.2012.01.06.09.43.00 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 09:43:01 -0800 (PST) Sender: Jim Gettys Message-ID: <4F0732A3.9000000@freedesktop.org> Date: Fri, 06 Jan 2012 12:42:59 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Bob Briscoe References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> <201201051753.q05Hqx78012678@bagheera.jungle.bt.co.uk> In-Reply-To: <201201051753.q05Hqx78012678@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 06 Jan 2012 17:43:06 -0000 On 01/05/2012 12:52 PM, Bob Briscoe wrote: > Jim, Justin, > > Jumping back one posting in this thread... > > At 17:36 04/01/2012, Justin McCann wrote: >> On Wed, Jan 4, 2012 at 11:16 AM, Dave Taht wrote: >> > >> > On Wed, Jan 4, 2012 at 4:25 PM, Jim Gettys wrote: >> > >> > 1: the 'slower flows gain priority' question is my gravest concern >> > (eg, ledbat, bittorrent). It's fixable with per-host FQ. >> >> Meaning that you don't want to hand priority to stuff that is intended >> to stay in the background? > > The LEDBAT/BitTorrent issue wouldn't be fixed by per-host FQ. > LEDBAT/uTP tries to yield to other hosts, not just its own host. > > In fact, in the early part of the last decade, the whole issue of > long-running vs interactive flows showed how broken any form of FQ > was. This was why ISPs moved away from rate equality (whether > per-flow, per-host or per-customer site) to various > per-customer-volume-based approaches (or a mix of both). > > There seems to be an unspoken assumption among many on this list that > rate equality must be integrated into each AQM implementation. That's > so 2004. It seems all the developments in fairness over the last > several years have passed completely over the heads of many on this > list. This page might fill in the gaps for those who missed the last > few years: > > > To address buffer bloat, I advise we "do one thing and do it well": > bulk AQM. > > In a nutshell, bit-rate equality, where each of N active users gets > 1/N of the bit-rate, was found to be extremely _unfair_ when the > activity of different users is widely different. For example: > * 5 light users all active 1% of the time get close to 100% of a > shared link whenever they need it. > * However, if instead 2 of these users are active 100% of the time, FQ > gives the other three light users only 33% of the link whenever they > are active. > * That's pretty rubbish for a solution that claims to isolate each > user from the excesses of others. That's not how these queuing disciplines work, from what little I understand: I'll let Eric and Dave explain exactly what SFQ + QFQ etc. are doing. I think the word "fair" is getting over-used/abused and can cause us all to have terminal confusion, since "fair queuing" in the research community has a specific meaning. Eric, Dave, care to explain exactly what these queuing disciplines are doing, and how they differ? > > Since 2004, we now understand that fairness has to involve accounting > over time. That requires per-user state, which is not something you > can do, or that you need to do, within every queue. We should leave > fairness to separate code, probably on machines specialising in this > at the edge of a provider's network domain - where it knows about > users/customers - separate from the AQM code of each specific queue. In home routers we *are* at the very edge of the network (in fact beyond the ISP's domain in the case of cable), and that is the focus of the experiments that Eric and Dave have been doing. And here we can afford to keep track of per-user state in those devices. That some of these queuing disciplines have such nice effects on latency of many applications is gravy. This is the point where we go from multiple *users* to the single *customer*, which is what you see from where you sit. I think "fair queueing" (whatever fair means) is pretty orthogonal to AQM in general: we need AQM to keep the overall buffers from filling from elephant flows and running full, which is never good, and causes packet loss, which ultimately these queuing disciplines don't handle... And AQM is probably all that is needed upstream of the customer, particularly since "fairness" is entirely in the eye of the beholder. And we still need an AQM known to work presented with variable bandwidth :-(.... I think we're in agreement here. And if not, this is the time to get everyone to understand and share terminology. - Jim > > > Bob > > > > > > > > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design