From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailgw7.ericsson.se", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B28C321F16D for ; Tue, 8 Jan 2013 04:19:21 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-f1-50ec0ec63130 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.6D.04318.6CE0CE05; Tue, 8 Jan 2013 13:19:19 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.166]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:19:18 +0100 From: Ingemar Johansson S To: Keith Winstein Thread-Topic: [e2e] bufferbloat paper Thread-Index: AQHN7Yzk6V9DQIB5R0ugEZ+j7weArJg/VCXg Date: Tue, 8 Jan 2013 12:19:17 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje5xvjcBBpPnM1n0/7rParH73FQW i5Mdt5gspq2ZxuTA4vHv0E1mj+0XzzB5NJ05yuzRcXwDcwBLFJdNSmpOZllqkb5dAlfGrivT mAt26Fb8bF/D3sD4W7mLkZNDQsBEYs7HmawQtpjEhXvr2boYuTiEBA4xStx8+pQdwlnMKPFn yW1mkCo2ARuJlYe+M4LYIgLKEjfWL2cFKWIWWM4o8eXAVrCEsICKxIPZE1ggilQl5p5+DtVg JHHp5U6gBg4OFqCayROCQUxeAW+J+ZcSIHZNYpQ4PrMRrJxTIFDi+ItOMJtRQFbi/vd7YCOZ BcQlbj2ZzwRxtYDEkj3nmSFsUYmXj/9BfaMo8fHVPkaIej2JG1OnsEHY2hLLFr4Gq+cVEJQ4 OfMJywRGsVlIxs5C0jILScssJC0LGFlWMbLnJmbmpJebb2IERtPBLb8NdjBuui92iFGag0VJ nDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbDqe2rpyxNPXNVZ1Nr7bJXfi9dGO5p f3fe476rujJW+E+1tQODb/s/rn3aiZEnt/rk/u83P8ic3nf46nOHfQcZjmbFf2nyk3q45Fp1 pPSj/AvGAdtFnqnIqUv5xOd+fjTtneDfrHsdUjFSGm2V4gsfZaRkqP547FBX/v3z7H3P/x56 eyW7zlCJpTgj0VCLuag4EQD2m/ZGdAIAAA== Cc: "mallman@icir.org" , "end2end-interest@postel.org" , "bloat@lists.bufferbloat.net" Subject: Re: [Bloat] [e2e] 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 12:19:22 -0000 Hi Interesting graph, thanks for sharing it. It is likely that the delay is only limited by TCPs maximum congestion wind= ow, for instance at T=3D70 the thoughput is ~15Mbps and the RTT~0.8s, givin= g a congestion window of 1.5e7/8/0.8 =3D 2343750 bytes, recalculations at o= ther time instants seems to give a similar figure.=20 Do you see any packet loss ? The easiest way to mitigate bufferbloat in LTE UL is AQM in the terminal as= the packets are buffered there.=20 The eNodeB does not buffer up packets in UL* so I would in this particular = case argue that the problem is best solved in the terminal. Implementing AQM for UL in eNodeB is probably doable but AFAIK nothing that= is standardized also I cannot tell how feasible it is. /Ingemar BTW... UL =3D uplink * RLC-AM retransmissions can be said to cause delay in the eNodeB but then = again the main problem is that packets are being queued up in the terminals= sendbuffer. The MAC layer HARQ can too cause some delay but this is a nece= ssity to get an optimal performance for LTE, moreover the added delay due t= o HARQ reTx is marginal in this context. > -----Original Message----- > From: winstein@gmail.com [mailto:winstein@gmail.com] On Behalf Of Keith > Winstein > Sent: den 8 januari 2013 11:42 > To: Ingemar Johansson S > Cc: end2end-interest@postel.org; bloat@lists.bufferbloat.net; > mallman@icir.org > Subject: Re: [e2e] bufferbloat paper >=20 > I'm sorry to report that the problem is not (in practice) better on LTE, = even > though the standard may support features that could be used to mitigate t= he > problem. >=20 > Here is a plot (also at http://web.mit.edu/keithw/www/verizondown.png) > from a computer tethered to a Samsung Galaxy Nexus running Android > 4.0.4 on Verizon LTE service, taken just now in Cambridge, Mass. >=20 > The phone was stationary during the test and had four bars (a full > signal) of "4G" service. The computer ran a single full-throttle TCP CUBI= C > download from one well-connected but unremarkable Linux host (ssh > hostname 'cat /dev/urandom') while pinging at 4 Hz across the same > tethered LTE interface. There were zero lost pings during the entire test > (606/606 delivered). >=20 > The RTT grows to 1-2 seconds and stays stable in that region for most of = the > test, except for one 12-second period of >5 seconds RTT. We have also tri= ed > measuring only "one-way delay" (instead of RTT) by sending UDP datagrams > out of the computer's Ethernet interface over the Internet, over LTE to t= he > cell phone and back to the originating computer via USB tethering. This g= ives > similar results to ICMP ping. >=20 > I don't doubt that the carriers could implement reasonable AQM or even a > smaller buffer at the head-end, or that the phone could implement AQM for > the uplink. For that matter I'm not sure the details of the air interface= (LTE vs. > UMTS vs. 1xEV-DO) necessarily makes a difference here. >=20 > But at present, at least with AT&T, Verizon, Sprint and T-Mobile in Easte= rn > Massachusetts, the carrier is willing to queue and hold on to packets for= >1 > second. Even a single long-running TCP download (>15 > megabytes) is enough to tickle this problem. >=20 > In the CCR paper, even flows >1 megabyte were almost nonexistent, which > may be part of how these findings are compatible. >=20 > On Tue, Jan 8, 2013 at 2:35 AM, Ingemar Johansson S > wrote: > > Hi > > > > Include Mark's original post (below) as it was scrubbed > > > > I don't have an data of bufferbloat for wireline access and the fiber > connection that I have at home shows little evidence of bufferbloat. > > > > Wireless access seems to be a different story though. > > After reading the "Tackling Bufferbloat in 3G/4G Mobile Networks" by > > Jiang et al. I decided to make a few measurements of my own (hope that > > the attached png is not removed) > > > > The measurement setup was quite simple, a Laptop with Ubuntu 12.04 > with a 3G modem attached. > > The throughput was computed from the wireshark logs and RTT was > measured with ping (towards a webserver hosted by Akamai). The location i= s > Lule=E5 city centre, Sweden (fixed locations) and the measurement was mad= e > at lunchtime on Dec 6 2012 . > > > > During the measurement session I did some close to normal websurf, > including watching embedded videoclips and youtube. In some cases the > effects of bufferbloat was clearly noticeable. > > Admit that this is just one sample, a more elaborate study with more > samples would be interesting to see. > > > > 3G has the interesting feature that packets are very seldom lost in > downlink (data going to the terminal). I did not see a single packet loss= in this > test!. I wont elaborate on the reasons in this email. > > I would however believe that LTE is better off in this respect as long = as > AQM is implemented, mainly because LTE is a packet-switched architecture. > > > > /Ingemar > > > > Marks post. > > ******** > > [I tried to post this in a couple places to ensure I hit folks who > > would be interested. If you end up with multiple copies of the > > email, my apologies. --allman] > > > > I know bufferbloat has been an interest of lots of folks recently. > > So, I thought I'd flog a recent paper that presents a little data on > > the topic ... > > > > Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer > > Communication Review, 43(1), January 2013. > > http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf > > > > Its an initial paper. I think more data would be great! > > > > allman > > > > > > -- > > http://www.icir.org/mallman/ > > > > > > > >