From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6557621F1B0 for ; Wed, 12 Dec 2012 06:26:49 -0800 (PST) Received: from [IPv6:2001:470:96b9:1:14cb:af2e:2e24:2838] (ibis.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:1:14cb:af2e:2e24:2838]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 5A8634C320C for ; Wed, 12 Dec 2012 15:26:47 +0100 (CET) Message-ID: <50C89427.8080505@net.t-labs.tu-berlin.de> Date: Wed, 12 Dec 2012 15:26:47 +0100 From: Oliver Hohlfeld User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <54532012A5393D4E8F57704A4D55237E3CE5C5E7@CH1PRD0510MB381.namprd05.prod.outlook.com> In-Reply-To: <54532012A5393D4E8F57704A4D55237E3CE5C5E7@CH1PRD0510MB381.namprd05.prod.outlook.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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, 12 Dec 2012 14:26:49 -0000 > - 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.) 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. > - 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. This is a known fact. Even Gettys reported this issue in his first paper. > I posted the slides at http://www.bufferbloat.net/attachments/download/148/Bufferbloat-DLSLUG-Dec2012.pdf Thanks for sharing this! A few comments: - 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. - 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). - 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. Oliver