From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 9AAF321F16D for ; Mon, 7 Jan 2013 18:25:27 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id r082PPi2002785; Mon, 7 Jan 2013 18:25:25 -0800 Date: Mon, 7 Jan 2013 18:24:09 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Mark Watson In-Reply-To: <09F59659-62CD-4D14-A3F9-5223CCD274DD@netflix.com> Message-ID: References: <20130107233732.GE3635@nuttenaction> <09F59659-62CD-4D14-A3F9-5223CCD274DD@netflix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-330814633-1357611849=:2496" Cc: bloat Subject: Re: [Bloat] Bufferbloat Paper 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: Tue, 08 Jan 2013 02:25:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-330814633-1357611849=:2496 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 8 Jan 2013, Mark Watson wrote: > On Jan 7, 2013, at 4:33 PM, Dave Taht wrote: > >> "We use a packet trace collection taken from the Case Con- >> nection Zone (CCZ) [1] experimental fiber-to-the-home net- >> work which connects roughly 90 homes adjacent to Case >> Western Reserve University’s campus with **bi-directional 1 Gbps >> links**. " >> >> Aside from their dataset having absolutely no reflection on the >> reality of the 99.999% of home users running at speeds two or three or >> *more* orders of magnitude below that speed, it seems like a nice >> paper. > > Actually they analyze the delay between the measurement point in CCZ and the > *remote* peer, splitting out residential and non-residential peers. 57% of the > peers are residential. Sounds like a lot of the traffic is p2p. You could > argue that the remote, residential p2p peers are not on "typical" connections > and that this traffic doesn't follow the time-of-day usage patterns expected > for applications with a live human in front of them. But if the "remote peer" is on a 1Gbps link, that hardly reflects normal conditions. typical conditions are 1G 1M desktop -----firewall ---- Internet it's this transition from 1G to 1M that causes data to be buffered. If you have 1G on both sides of the home firewall, then it's unlikely that very much data is going to be buffered there. David Lang --680960-330814633-1357611849=:2496--