From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) (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 DC05321F159 for ; Tue, 8 Jan 2013 05:19:44 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-47-50ec1cedf769 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.DB.10459.DEC1CE05; Tue, 8 Jan 2013 14:19:42 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.166]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 14:19:41 +0100 From: Ingemar Johansson S To: Keith Winstein Thread-Topic: [e2e] bufferbloat paper Thread-Index: AQHN7Yzk6V9DQIB5R0ugEZ+j7weArJg/VCXg///7uACAABeOcA== Date: Tue, 8 Jan 2013 13:19:41 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA08050D@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA080493@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+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje47mTcBBjv+clv0/7rParH73FQW i5Mdt5gspq2ZxuTA4vHv0E1mj+0XzzB5NJ05yuzRcXwDcwBLFJdNSmpOZllqkb5dAldG2/pF TAUfrCp2fnjD1MA4U6+LkZNDQsBEYsPmzawQtpjEhXvr2UBsIYFDjBJPZut3MXIB2YsZJY4/ 7GABSbAJ2EisPPSdEcQWEVCWuLF+OStIEbPAckaJLwe2giWEBVQkHsyewAJRpCox9/RzqAYn ic3H1gI1cHCwANU8XBsOYvIKeEtMP6cDsWs2k8TPqX/AyjkFAiUutdwAG8MoICtx//s9MJtZ QFzi1pP5TBBHC0gs2XOeGcIWlXj5+B/UM4oSH1/tY4So15O4MXUKG4StLbFs4Wuwel4BQYmT M5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZgLB3c8lt3B+OpcyKHGKU5WJTE ecNcLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHQvf1Iq5T0383CB/kkpw1nvJB1mZlYV rFRJvRd93m522HQ7/1g1gSJrpb8dpwwjvlQbT7A7PXUev+urL4vFztXP8Zp83aL3n1zy89tf ajM2Nd968cs8c0OZUlBt1smKLTUzPdNuquY7tgXe7ilQPjdVKrCNNWyPArfNE6v/20Pc7Nvk 1TVOKbEUZyQaajEXFScCAK+sFTBzAgAA Cc: "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 13:19:45 -0000 OK... Likely means that AQM is not turned on in the eNodeB, can't be 100% sure th= ough but it seems so. At least one company I know of offers AQM in eNodeB. However one problem s= eems to be that the only thing that counts is peak throughput, you have pro= bably too seen these "up to X Mbps" slogans. Competition is fierce snd for= this reason it could be tempting to turn off AQM as it may reduce peak thr= oughput slightly. I know and most people on these mailing lists knows that = peak throughput is the "mexapixels" of the internet, one need to address ot= her aspects in the benchmarks. /Ingemar > -----Original Message----- > From: winstein@gmail.com [mailto:winstein@gmail.com] On Behalf Of Keith > Winstein > Sent: den 8 januari 2013 13:44 > To: Ingemar Johansson S > Cc: end2end-interest@postel.org; bloat@lists.bufferbloat.net; > mallman@icir.org > Subject: Re: [e2e] bufferbloat paper >=20 > Hello Ingemar, >=20 > Thanks for your feedback and your own graph. >=20 > This is testing the LTE downlink, not the uplink. It was a TCP download. >=20 > There was zero packet loss on the ICMP pings. I did not measure the TCP > flow itself but I suspect packet loss was minimal if not also zero. >=20 > Best, > Keith >=20 > On Tue, Jan 8, 2013 at 7:19 AM, Ingemar Johansson S > wrote: > > Hi > > > > Interesting graph, thanks for sharing it. > > It is likely that the delay is only limited by TCPs maximum congestion > window, for instance at T=3D70 the thoughput is ~15Mbps and the RTT~0.8s, > giving a congestion window of 1.5e7/8/0.8 =3D 2343750 bytes, recalculatio= ns at > other time instants seems to give a similar figure. > > Do you see any packet loss ? > > > > The easiest way to mitigate bufferbloat in LTE UL is AQM in the termina= l as > the packets are buffered there. > > The eNodeB does not buffer up packets in UL* so I would in this particu= lar > 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 necessity to get an optimal performance for LTE, moreover the > added delay due to 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 > >> > >> 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 the problem. > >> > >> 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. > >> > >> 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 > >> CUBIC 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). > >> > >> 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 tried 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 the cell phone and back to the originating > >> computer via USB tethering. This gives similar results to ICMP ping. > >> > >> 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. > >> > >> But at present, at least with AT&T, Verizon, Sprint and T-Mobile in > >> Eastern 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. > >> > >> In the CCR paper, even flows >1 megabyte were almost nonexistent, > >> which may be part of how these findings are compatible. > >> > >> 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 is Lule=E5 city centre, Sweden (fixed locations) and the > >> measurement was made 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/ > >> > > >> > > >> > > >> >