From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (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 5E48B21F16D for ; Tue, 8 Jan 2013 04:44:37 -0800 (PST) Received: by mail-bk0-f53.google.com with SMTP id j5so213284bkw.12 for ; Tue, 08 Jan 2013 04:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=O3R6ibU/maV7BzOQRnVFjrkgcNiue6So1kSawMXKN34=; b=OhZHX0Swf74IZ+kMaXpHDFwomZ/9ljZdt1QVAbLXLllxzMXDI6rqTp71VBZu8pnAZa 3Riys1LIM8DeLaWEQbN4+NbwYx/KulQZ8dCBsGIDlSiTho299iEzFC3UC3pZ26rqVpPQ qmDeNgeG1R0V43NNDUflww8uiHT5SM8Xn/U0O+z5GJ2D9bGpi5Kv5AHjAsaDdCdu8LsU ++nb36NGlUAWszFSPwETYLDz8d3x3nb7nOzW7QB4zowwf9/z348h91doUZqqMTCcwnHs weiM6rF40/7kpaFGiRNxvUIr1aYATj4B+JMAGGPaRpiKHdyqO0/U7mw/AoXwu+dGCA0D Lw9A== Received: by 10.204.143.147 with SMTP id v19mr31376871bku.32.1357649075202; Tue, 08 Jan 2013 04:44:35 -0800 (PST) MIME-Version: 1.0 Sender: winstein@gmail.com Received: by 10.204.11.141 with HTTP; Tue, 8 Jan 2013 04:44:14 -0800 (PST) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> From: Keith Winstein Date: Tue, 8 Jan 2013 07:44:14 -0500 X-Google-Sender-Auth: bVOtOgCXtGiIu7s17LwQLLTjNrU Message-ID: To: Ingemar Johansson S Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 12:44:38 -0000 Hello Ingemar, Thanks for your feedback and your own graph. This is testing the LTE downlink, not the uplink. It was a TCP download. 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. Best, Keith 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 wi= ndow, for instance at T=3D70 the thoughput is ~15Mbps and the RTT~0.8s, giv= ing a congestion window of 1.5e7/8/0.8 =3D 2343750 bytes, recalculations 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 terminal = as the packets are buffered there. > The eNodeB does not buffer up packets in UL* so I would in this particula= r case argue that the problem is best solved in the terminal. > Implementing AQM for UL in eNodeB is probably doable but AFAIK nothing th= at 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 the= n again the main problem is that packets are being queued up in the termina= ls sendbuffer. The MAC layer HARQ can too cause some delay but this is a ne= cessity 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 CUB= IC >> 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 tes= t >> (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 tr= ied >> 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 fo= r >> the uplink. For that matter I'm not sure the details of the air interfac= e (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 East= ern >> Massachusetts, the carrier is willing to queue and hold on to packets fo= r >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 ma= de >> 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 los= s 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/ >> > >> > >> > >> >