From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qw0-f43.google.com (mail-qw0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id ACFB8200051 for ; Mon, 23 May 2011 06:07:38 -0700 (PDT) Received: by qwf6 with SMTP id 6so4250659qwf.16 for ; Mon, 23 May 2011 06:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:organization :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=Q952B8ZGkG/StYkKk84RM2qtlyUGonAimjPzP8Y2Zyk=; b=rBnjxFzgGQaDVA3cc4VLI0Xa1/V4TTiy8vkAi7+gjvvfJ40icLmUpeu8tCKKevXHiD vwE5VfE4kbEBHHrWzVCp9RoYY8Psv7VZe5OovO4DCDv5+mK8A/AGqQ5zVHsn/lsYrrX1 GY2DtmE7hw51eORYuBWz9Gt3L0P2CcFeIWQyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; b=xJHDfgnthieHs/U4Lz7qDIjR0oC+4ndJUJItVmfYsJinYsPm0yn5VRSxrq/3pj4erO 24/UuyrFJW1sqS6xsrOK9H80/4rHUPUrCFXoiC6/M8rk8Bl4Inn1kU5IxW/3BTVS1adD +K9q9xax/mSFuQtr61syFABG3Xt3QvtqIEKTM= Received: by 10.224.216.136 with SMTP id hi8mr1775784qab.55.1306156833895; Mon, 23 May 2011 06:20:33 -0700 (PDT) Received: from [192.168.1.119] (c-98-229-99-32.hsd1.ma.comcast.net [98.229.99.32]) by mx.google.com with ESMTPS id c27sm3938821qck.34.2011.05.23.06.20.30 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 06:20:31 -0700 (PDT) Sender: Jim Gettys Message-ID: <4DDA5F1C.6010706@freedesktop.org> Date: Mon, 23 May 2011 09:20:28 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: bismark-devel@lists.bufferbloat.net References: <9EFCAA58-92E8-45FD-9BE4-F213564264E6@cc.gatech.edu> <5C1FCBFC-B007-4B01-A7BA-6CCD5523DC34@cc.gatech.edu> <72E30C46-3045-4FBA-A464-C7120C3FECE2@gatech.edu> <58F7BFB9-8382-427A-986C-5FAFB90A8DD4@gatech.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090109000705060101020501" Subject: Re: [Bismark-devel] about ready to do another build X-BeenThere: bismark-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: BISMark related software development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 13:07:39 -0000 This is a multi-part message in MIME format. --------------090109000705060101020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/21/2011 12:49 PM, Dave Taht wrote: > > > On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan > > wrote: > > > On May 21, 2011, at 6:08 PM, Dave Taht wrote: > > > > > > > On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan > > wrote: > > I do not have a problem with it when we know the effective > bandwidth. My question is, what when do not? We cannot rely on > volunteers to give us reliable information on that. > > > > I say we turn it *on only while testing*. That too, after we get > an idea about each user's bandwidth. THis is feature that, in its > current form needs to be tailored to each user. It is not a good > idea to give everyone a default setting - as I mentioned in my > previous email, unless we hit bulls eye (unlikely), it is either > crippling, or useless. > > > > It could potentially seriously downgrade user experience. > > > > > > What part about 800ms latencies under load without QoS isn't > about a degraded user experience? > > If the cost of reduced upload speed, which could perhaps be as > much as 30%, (if the default is 340kbps - the DSL connection here > in my B&B gets up to 450k), can't be reduced, I certainly think > that it's the higher price to pay than reduced latency. > > > I would urge you strongly to do more realistic testing, with more real > users using the network... > > ...before making that call. I am assuming you are unleashing these > devices on real users? with more than one person on the network? > > RTT times will probably get even worse than 800ms with multiple > streams running. I have not tested that, I'll get to it. > Take a look at the ISCI data on bufferbloat. The colour versions are in: http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ You can get an explanation for the structure you will see from the Netalyzr papers. The diagonal lines show the potential latency, and the "green" line of .5 seconds is already 3x telephony standards. So a high fraction of the internet has serious bloat problems. Several things: 1) the dataset *underdetected* the problem: there was a bug in Netalyzr only detected last October (and the dataset covers most of 2010 and back into 2009). So the situation is worse than that shown. How much, we don't know. 2) the amount of bloat varies *all* over; some DSL lines are up in the 6 second range. 3) the amount of buffering is fixed: so the lower the provisioning, the longer the latency on the same devices. I was seeing > 1.2 seconds on 20Mbps cable, at which point web surfing is painful indeed. 4) If the bottleneck is elsewhere, then the broadband connection bufferbloat isn't the buffers that will affect the results. So if the backhaul is lower bandwidth than the broadband/wireless connections, then the problem will be in the network routers, where RED (if enabled!) can control it. I call the problem the "Daddy, the Internet is slow today" problem: I was usually the person who was causing saturation on the line, so when my family was experiencing slowdowns, they would come to me and I'd try to debug it, and stop whatever it was that was doing them in. Who may be saturating the link most often varies from household to household: bittorrent can induce bufferbloat suffering. Now, what you do is for you to determine; just understand the bufferbloat problem is extremely common and extremely variable. Your mileage *will* vary. - Jim --------------090109000705060101020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 05/21/2011 12:49 PM, Dave Taht wrote:


On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan <srikanth@gatech.edu> wrote:

On May 21, 2011, at 6:08 PM, Dave Taht wrote:

>
>
> On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan <srikanth@gatech.edu> wrote:
> I do not have a problem with it when we know the effective bandwidth. My question is, what when do not? We cannot rely on volunteers to give us reliable information on that.
>
> I say we turn it *on only while testing*. That too, after we get an idea about each user's bandwidth. THis is feature that, in its current form needs to be tailored to each user. It is not a good idea to give everyone a default setting - as I mentioned in my previous email, unless we hit bulls eye (unlikely), it is either crippling, or useless.
>
> It could potentially seriously downgrade user experience.
>
>
> What part about 800ms latencies under load without QoS isn't about  a degraded user experience?

If the cost of reduced upload speed,  which could perhaps be as much as 30%, (if the default is 340kbps - the DSL connection here in my B&B gets up to 450k), can't be reduced, I certainly think that it's the higher price to pay than reduced latency.


I would urge you strongly to do more realistic testing, with more real users using the network...

...before making that call. I am assuming you are unleashing these devices on real users? with more than one person on the network?

RTT times will probably get even worse than 800ms with multiple streams running. I have not tested that, I'll get to it.


Take a look at the ISCI data on bufferbloat. The colour versions are in: http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/  You can get an explanation for the structure you will see from the Netalyzr papers. The diagonal lines show the potential latency, and the "green" line of .5 seconds is already 3x telephony standards.  So a high fraction of the internet has serious bloat problems.

Several things:

1) the dataset *underdetected* the problem: there was a bug in Netalyzr only detected last October (and the dataset covers most of 2010 and back into 2009).  So the situation is worse than that shown.  How much, we don't know.

2) the amount of bloat varies *all* over; some DSL lines are up in the 6 second range.

3) the amount of buffering is fixed: so the lower the provisioning, the longer the latency on the same devices.  I was seeing > 1.2 seconds on 20Mbps cable, at which point web surfing is painful indeed.

4) If the bottleneck is elsewhere, then the broadband connection bufferbloat isn't the buffers that will affect the results.  So if the backhaul is lower bandwidth than the broadband/wireless connections, then the problem will be in the network routers, where RED (if enabled!) can control it.

I call the problem the "Daddy, the Internet is slow today" problem: I was usually the person who was causing saturation on the line, so when my family was experiencing slowdowns, they would come to me and I'd try to debug it, and stop whatever it was that was doing them in.  Who may be saturating the link most often varies from household to household: bittorrent can induce bufferbloat suffering.

Now, what you do is for you to determine; just understand the bufferbloat problem is extremely common and extremely variable.  Your mileage *will* vary.
                    - Jim



--------------090109000705060101020501--