From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.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 40A00200D4F for ; Tue, 8 Nov 2011 01:20:47 -0800 (PST) Received: by vws13 with SMTP id 13so271811vws.16 for ; Tue, 08 Nov 2011 01:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=/86QBeAR0RoCB1lzPWlLYGEsayMcGFJNR+iRBz9M05o=; b=B4uF8683xIp/QjvZ99Ctl4GUUiyylSj4I9CQkLOyp/V7HiT5hb4GH2Rpt984lqkPxa ZzuI033iPATxL62VmeOXaA72ZW3KENgqOfLdzyxxWS0a03BSQ1MfsfuaNh666q/E2tFO E2JW+LrmhTuQZUYS9hAm632QRRIhfOXJ/j6rY= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr8716510obq.37.1320744045137; Tue, 08 Nov 2011 01:20:45 -0800 (PST) Received: by 10.182.15.40 with HTTP; Tue, 8 Nov 2011 01:20:45 -0800 (PST) Date: Tue, 8 Nov 2011 10:20:45 +0100 Message-ID: From: Dave Taht To: bloat , rbt@broughturner.com Content-Type: multipart/alternative; boundary=14dae93b62c8a6508304b135af15 Subject: [Bloat] bloat, 3G networks and switch behavior 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 Nov 2011 09:20:47 -0000 --14dae93b62c8a6508304b135af15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable just stumbled across this old piece which links to some of the original discussions around what has become called bufferbloat since, and also had some links to papers I hadn't read. http://blogs.broughturner.com/2009/10/is-att-wireless-data-congestion-selfi= nflicted.html I'm curious as to who is monitoring 3G performance and latency to the extent mentioned in this piece. Would love trendlines going back a couple years.... this three parter was also pretty good: http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/09/29/app= lication-analysis-using-tcp-retransmissions-part-1.aspx The conclusion shows what happens when you start overrunning buffers in a high speed switch. http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/02/ret= hinking-interface-error-reports.aspx Money quote on that: "So I went back to the network assessment tools that I used and found that the interfaces that were reported by my tools all had much higher percentage errors, but had very low data rates. The high-throughput interfaces that I found in the CLI output had error percentages that kept them from appearing in the top few pages of interfaces with high error percentages. While it is important to identify the high-percentage error interfaces (which also had low traffic volumes), it was the high volume interfaces that were impacting the applications that communicated across the network backbone. The interfaces that I was investigating had very high traffic volume, had hundreds of thousands of errors, and were key interfaces in the infrastructure. Now I had a clear understanding of my misconception in looking for interface errors. I had always thought that I should look for high percent errors. But here were key infrastructure interfaces that were exhibiting high errors, but because of the total volume transiting the interfcaes, their percentage was low, relative to other, low-volume interfaces. How should I handle this case?" --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --14dae93b62c8a6508304b135af15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable just stumbled across this old piece which links to some of the original dis= cussions around what has become called bufferbloat since, and also had some= links to papers I hadn't read.

http:/= /blogs.broughturner.com/2009/10/is-att-wireless-data-congestion-selfinflict= ed.html

I'm curious as to who is monitoring 3G performance and latency to t= he extent mentioned in this piece. Would love trendlines going back a coupl= e years....

this three parter was also pretty good:
htt= p://www.netcordia.com/community/blogs/terrys_blog/archive/2011/09/29/applic= ation-analysis-using-tcp-retransmissions-part-1.aspx

The conclusion shows what happens when you start overrunning buffers in= a high speed switch.

http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/02= /rethinking-interface-error-reports.aspx

Money quote on that:

"So I went back to the network assessm= ent tools that I used and found=20 that the interfaces that were reported by my tools all had much higher=20 percentage errors, but had very low data rates. The high-throughput=20 interfaces that I found in the CLI output had error percentages that=20 kept them from appearing in the top few pages of interfaces with high=20 error percentages. While it is important to identify the high-percentage error interfaces (which also had low traffic volumes), it was the high=20 volume interfaces that were impacting the applications that communicated across the network backbone.

The interfaces that I was=20 investigating had very high traffic volume, had hundreds of thousands of errors, and were key interfaces in the infrastructure. Now I had a=20 clear understanding of my misconception in looking for interface errors. I had always thought that I should look for high percent errors. But=20 here were key infrastructure interfaces that were exhibiting high=20 errors, but because of the total volume transiting the interfcaes, their percentage was low, relative to other, low-volume interfaces. How=20 should I handle this case?"

--
Dave T=E4ht
SKYPE: daveta= ht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--14dae93b62c8a6508304b135af15--