From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm20.access.bullet.mail.mud.yahoo.com (nm20.access.bullet.mail.mud.yahoo.com [66.94.237.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id CFEC721F0F0 for ; Tue, 27 Nov 2012 16:56:49 -0800 (PST) Received: from [66.94.237.201] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Nov 2012 00:56:48 -0000 Received: from [98.139.221.70] by tm12.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Nov 2012 00:56:48 -0000 Received: from [127.0.0.1] by smtp107.rog.mail.bf1.yahoo.com with NNFMP; 28 Nov 2012 00:56:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1354064208; bh=9T488BGxSRAFISYiXTw5Yw/zFTWhrrcdl099qsWOKnI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=c9/A0z9CANZ2XtJy7ztsSkVE/YP4WiYTm7NgofhyCtArsqVl8HycWnTzLHlrtimDM7m15ddVFd89q/9SIRFCAcxFlHBl1o8dI+wj3Y1XS6RJiJnMJKsK17LrhXVq23q3aYVzMePoLWzTyCFDkOvJxxIEhyohG4beO91gmJ35AR4= X-Yahoo-Newman-Id: 190249.54116.bm@smtp107.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HPoJx2sVM1nise7jtGTtvlxqvxNGdjlCD0xQmGcCuylqmGx horpgtfYGvIqIuD1q3kOgfqLaRkPNWT8ZbVnoJAqh416NisOPUQ41W6DQd8I tuZhXXYta1D0P92qUJifAyNlHds5aJB4xEcevi.QRLK93Gul7olAOYLigVow TQITCERDncSMwByBOqRb1HSnPxOLwGXomEw61Jqy_V0f.w2dqVuaDJXktlWp 4IScQxr72Bi3jtHwPB1U4V.Df3kJP_Fnzx.4THa8n0sFs7nZG8xU3puc1VWJ 9.sAhJm8jzgv.n3Ywhi.cor6QfqAUz6EJepEDdKbwqLYi4X61f5ygThCmzjf Iw4FfUabMwCv_1ARcj8icRiwddVemJmnpNT431nayF1l76b7pfdAJjiM03YP 0QoxtoSiAhxsA4iy0xhM_o.W8hgixeJtnxBeCYhC4g1zgHKbpy2lAsuI_O2C 6i8QMviG4k7gIo2DQ3FGVvJRNqyHtYv1VDj.NMjXENOGt6B6Oh7u5sWUNjuj iRT_IEdf3AwwBhNbPi6yh X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Received: from [192.168.1.105] (davec-b@99.225.204.110 with plain) by smtp107.rog.mail.bf1.yahoo.com with SMTP; 27 Nov 2012 16:56:48 -0800 PST Message-ID: <50B56207.7030905@rogers.com> Date: Tue, 27 Nov 2012 19:59:51 -0500 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Bloat] Cascading proportionality, not fairness. X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 00:56:50 -0000 Jim Gettys wrote: > at an ISP, you must to be "fair" between customers; it is best to leave > the judgement of "fairness" at finer granularity (e.g. host and TCP flows) > to the points closer to the customer's systems, so that they can enforce > whatever definition of "fair" they need to themselves. I too hate the overloaded term, and would argue it's just wrong. Instead, we are discussing /proportionality/, and what we know about the ISP is very generally applicable. The ISP deliver proportional amounts of latency (or freedom from latency) to a community of customer devices, one of which might be a home router. The router delivers the upstream services proportionally to a kid's machine, to dad and mom, and to the TV or perhaps the dedicated skype phone. The latter two devices have some fixed requirements: a certain number of frames per second, a certain number of seconds of audio and the like. This is the hardest, but it has limits. Delivering much more than X frames a second over a long period is wasted effort. Delivering less than X for a short period yields dropouts. Therefor such a service can be statically provisioned, and rejected if there are already too many sessions to leave enough resources meet its needs. Fq_codel only has to deliver its usual guarantees: statically oversubscribing the link isn't its problem. The router does have to have the smarts to not commit logical suicide, or over-commit too greatly in cases where an over-commitment is allowable, but that's a different problem than fq addresses. That's an issue of capacity planning. Similarly, delivering a guaranteed minimum of service to each subscriber isn't a fair queuing or a fairness problem. It's one of setting a policy and enforcing it. It, like the audio/video problem is one of capacity planning, and proportionality. The parents can say "same service to anyone", or they can say "no A/V during homework hours". Outside of homework hours, they can say "gaming takes precedence over the PVR, but not over skype", and so on. On the kid's machine, we still want to use fq to keep downloads from messing up gaming and A/V, but the kid has to set the policy as to who ultimately wins. Jim is right: this really isn't fairness. I'd reserve that term for fq_codel and friends, call all the capacity planning considerations "proportionality". I'd also assume every node in the net thinks like an ISP and wants to start off by handing out equal response times to its entire set of "customers", and change that only if explicitly told to. --dave