From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu1sys200aog106.obsmtp.com (eu1sys200aog106.obsmtp.com [207.126.144.121]) (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 71AE521F175 for ; Wed, 19 Dec 2012 02:21:06 -0800 (PST) Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP ID DSNKUNGVD7+HeAvGUcMGAQS+43SEaZtgyrE1@postini.com; Wed, 19 Dec 2012 10:21:06 UTC Received: from ba6-office.pnsol.com ([172.20.5.199]) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1TlGlr-00056Q-B4; Wed, 19 Dec 2012 10:21:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Neil Davies In-Reply-To: <50C89427.8080505@net.t-labs.tu-berlin.de> Date: Wed, 19 Dec 2012 10:21:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54532012A5393D4E8F57704A4D55237E3CE5C5E7@CH1PRD0510MB381.namprd05.prod.outlook.com> <50C89427.8080505@net.t-labs.tu-berlin.de> To: Oliver Hohlfeld X-Mailer: Apple Mail (2.1499) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Bufferbloat at LUG talk - Meeting Report 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: Wed, 19 Dec 2012 10:21:07 -0000 Oliver=20 Every TCP transfer (which may be collection of web page accesses) that = reaches an instantaneous packet rate in-excess of the capacity of the = most constrained network element on the path causes such problems.=20 This is a measurable phenomena, it is equipment/configuration dependant = - but the non-stationarity introduced is of the order of several 100ms = to seconds - we've got measurements that cover that range. Such phenomena are a natural emergent consequence of the statistical = packet sharing of *any* resource. Neil On 12 Dec 2012, at 14:26, Oliver Hohlfeld = wrote: >> - Attempting to Skype with a bunch of web browser tabs open gives bad = results. Closing the tabs made things better. (They been blaming the = browser for "using too much memory". Now it's possible to think that = it's a network problem.) >=20 > Sorry to be nitpicking on this, but what evidence / indications tells > this is a networking problem? Why would the pages in the open tabs > constantly sent large bulks of data that fill up the buffers? While > there is certainly asynchronous communication over HTTP (Ajax etc.), = I'm > talking about traffic demands that can interfere with VoIP. This seems > highly unlikely. Correlating every possible problem with bufferbloat > without further investigation doesn't make any sense to me. >=20 >> - Another person reported that his network connection (wireless ISP, = two hops to a wired network) seemed to work OK as long as his household = was mostly downloading. But uploading much of anything really made = things bad. >=20 > This is a known fact. Even Gettys reported this issue in his first = paper. >=20 >> I posted the slides at = http://www.bufferbloat.net/attachments/download/148/Bufferbloat-DLSLUG-Dec= 2012.pdf >=20 > Thanks for sharing this! >=20 > A few comments: >=20 > - Slide 12 reads wired to me. It assumes that the entire main memory = is > allocated to packet memory. How will the home router then run an OS = and > any sort of application on top of it? The argument is flawed. >=20 > - Codel and SFQ are not the only solutions to improve bad FIFO queues. > Simple QoS mechanisms will do the trick as well (briefly mentioned on > slide 12). >=20 > - Slide 14 presents a long list of devices that lack of = implementations. > While the problem has been demonstrated for the first half of the = list, > I'd be interested to see if Codel could improve DSLAMs and cable > headends, that, to the best of my knowledge, hardly queue traffic and = do > not induce significant queuing delays. >=20 > Oliver > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat