From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gx0-f171.google.com (mail-gx0-f171.google.com [209.85.161.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 BD1C3200252 for ; Fri, 6 Jan 2012 10:09:04 -0800 (PST) Received: by ggnh4 with SMTP id h4so1204368ggn.16 for ; Fri, 06 Jan 2012 10:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5ZQ8FF9NBbqUaf0AqSsEfaS4AL8XwsRHGCCcbEFpF64=; b=YnyLRCw0rpWzKtVQze+LYb6rkObfUbaMrjdz4PporB3+SJTb0OqcDlqRXyRykhtY2R VvrrqrlXU7QybsCOdjw2jGv9rSwB5sNZ1lam/EP4GtfojV8Y2WboB3jcVso+8QCPThTu 2y8/Yf52GHwBctYF8ZMYmQNQQYnTVsTavuvYQ= MIME-Version: 1.0 Received: by 10.50.219.226 with SMTP id pr2mr8084317igc.30.1325873343633; Fri, 06 Jan 2012 10:09:03 -0800 (PST) Received: by 10.231.159.193 with HTTP; Fri, 6 Jan 2012 10:09:03 -0800 (PST) In-Reply-To: <4F0732A3.9000000@freedesktop.org> References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> <201201051753.q05Hqx78012678@bagheera.jungle.bt.co.uk> <4F0732A3.9000000@freedesktop.org> Date: Fri, 6 Jan 2012 19:09:03 +0100 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 18:09:05 -0000 On Fri, Jan 6, 2012 at 6:42 PM, Jim Gettys wrote: > On 01/05/2012 12:52 PM, Bob Briscoe wrote: > Eric, Dave, care to explain exactly what these queuing disciplines are > doing, and how they differ? Well, they are changing so fast as eric assembles pieces of the puzzle that I think doing it in a wiki page makes more sense than email. The latest piece is Eric's combination of SFQ and RED which has some very interesting properties, with a good description is described here: http://patchwork.ozlabs.org/patch/134677/ There's still some more pieces left to come (coping with time in queue for variable bandwidth), but the results thus far have been very encouraging. While I compose my thoughts, kernel bql-15 contains the above patch (and several dozen more prior - all of which besides the above are now in linux-3.3) http://huchra.bufferbloat.net/~d/bql/ and debloat-iproute2 will contain (as soon as I patch it in) stuff to exercise it (I think adaptive red is missing, too from the iproute2 tree ) https://github.com/dtaht/deBloat-iproute2 It already has code to exercise everything else that has gone in in the past few weeks for QFQ, netem, and SFQ. Stuff to exercise qfq is in deBloat Trying to write all this up comprehensively is going to take a while. Let me get some stuff patched and built first... > >> >> 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. =A0And here we can afford > to keep track of per-user state in those devices. =A0That 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. =A0And if not, this is the time to get > everyone to understand and share terminology. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim > >> >> >> Bob >> >> >> >> >> >> >> >> >> >> ________________________________________________________________ >> Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0BT Innovate & Design > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net