From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-ewr.dyndns.com (mxout-096-ewr.mailhop.org [216.146.33.96]) by lists.bufferbloat.net (Postfix) with ESMTP id 705C82E02E9 for ; Sun, 6 Feb 2011 06:39:56 -0800 (PST) Received: from scan-12-ewr.mailhop.org (scan-12-ewr.local [10.0.141.230]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 199A193341C for ; Sun, 6 Feb 2011 14:39:54 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 71.162.243.5 Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 76CF093327A for ; Sun, 6 Feb 2011 14:39:53 +0000 (UTC) Received: by snark.thyrsus.com (Postfix, from userid 23) id AC0CF20C22E; Sun, 6 Feb 2011 09:39:52 -0500 (EST) From: Eric Raymond To: bloat@lists.bufferbloat.net Message-Id: <20110206143952.AC0CF20C22E@snark.thyrsus.com> Date: Sun, 6 Feb 2011 09:39:52 -0500 (EST) Subject: [Bloat] Overview modifications 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: Sun, 06 Feb 2011 14:39:58 -0000 I'm trawling through the mailing list archives for bits to improve the overview document with. jg wrote: >Note that lossy wireless networks behave much better than "clean" >variable bandwidth wireless networks; packet drops due to such losses at >least cause TCP to back off sometimes.... This is an important enough point to be in the overview. Change in progress -- append to the "Hating" paragraph the following sentence: "Lossy networks such as wireless actually show less chaotic behavior under load than clean ones." Is this correct and adequate? Ah, now I've found jg's original reply on the overview. jg wrote: >1) the latency-speed connection needs to be emphasised; along with >bandwidth !=speed. You can at least start to attack the conflation of >"speed" and "bandwidth" that is in the market. *Excellent* point. New 'graph, after the one on DNS et al going kerflooey. The way these latency-sensitive services degrade illustrates a general point. From a user point of view, perceived speed of the network is much more a function of latency (time to get a response) than of bandwidth (ability to bulk-ship). Thus, bufferbloat hammers the performance characteristic users care about most. jg: >To use the highway analogy, only a few areas have carpool lanes, and >most of the highway is still jammed. Once the carpool lanes are gone >(you get to another part of the network), you're still stuck behind >miles of traffic. Yup, I'll add this to the QoS section. Jim criticized "How Hard Is It?" Rewritten section looks like this: ---------------------------------------------------------------------- == How Hard Is It? == We started by asserting that bufferbloat is easy to fix. First we'll lay out the both the reasons for optimism, then the problems: First, it's easy to detect once you understand it - and verifying that you've fixed it is easy, too. Second, the fixes are cheap and give direct benefits as soon as they're applied. You don't have to wait for other people to fix bufferbloat in their devices to improve the performance of your own. Third, you'll usually only have to fix it once per device; continual tuning isn't necessary. Fourth (and importantly!), trying to fix bufferbloat won't significantly increase your risk of a network failure. If you fumble the first time, it's reversible. The hard problems are these: First, we don't yet know how to write good buffer-management rules for networks with variable bandwidth. This is a research area, though not an especially difficult one: good results seem likely in 12 to 36 months. Second, a lot of routers (especially consumer-grade ones) are difficult enough to upgrade firmware on that they will need to be replaced. Since the IPv6 transition is bearing down on us, however, it may be possible to fold our upgrade wave into that one. ---------------------------------------------------------------------- dtaht wrote: >Both ARE useful, but can be addressed in order of reducing unmanaged >buffers, applying AQM, and then QoS. That priority list needs to be made explicit in the overview. I will now do so. End of section: Explicit QoS may a place in our overall strategy for network performance, but the right order to do things is this: first reduce unmanaged buffers, then get buffer queue management right, then implement QoS on top of that. richard wrote: >Might add a note that if equipment does need to be changed out, isn't it >nice that we also have to change it out for the IPV4->IPV6 problem too >and/or that we're hoping the device manufacturers will address the >problem in the IPV6 equipment roll out. Done, as you can see above. richard: >Here in Canada the metered billing is very high visibility at the >moment. Would love to be able to point to this from some of the >discussion areas ASAP :) This *doesn't* go in the overview. Two reasons: Here, I don't want to be topical in a way likely to go stale rapidly. Also, dtaht and jg are right that there's a political hazard in getting too far into the whole tiered-billing/usage-metering issue. I don't think we can or should avoid it entirely; the fact that fixing bufferbloat may eliminate the technical necessity is simply too important a fact to elide. On the other hand, we need to be very careful and diplomatic and not pick any fights about this. That completes my mining of the back mail. I'll expect another round of responses to this post, then I'll run an edit for conciseness and length, then I'll start transplanting the overview onto the wiki. -- Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960