From touch at isi.edu Tue Jan 1 15:49:12 2013 From: touch at isi.edu (Joe Touch) Date: Tue, 1 Jan 2013 15:49:12 -0800 Subject: [e2e] Regarding blocked posts In-Reply-To: <50E0BC6F.9050300@web.de> References: <1348085253.52094.YahooMailClassic@web163003.mail.bf1.yahoo.com> <50D8EBE7.1090300@web.de> <1356405568.01746958@apps.rackspace.com> <50DB7ED7.5090008@web.de> <1356562906.75320908@apps.rackspace.com> <50DC0F60.9020803@web.de> <50DC6DBE.5050603@web.de> <1356644915.637229905@apps.rackspace.com> <50DD983F.5070004@web.de> <1356704890.01121623@apps.rackspace.com> <50DDCA81.2000302@web.de> <1356714754.081314280@apps.rackspace.com> <50E05388.7080608@web.de> <1356899459.767631954@apps.rackspace.com> <50E0BC6F.9050300@web.de> Message-ID: <132F8172-039C-4719-867A-A65FD718466B@isi.edu> > Am 30.12.2012 21:30, schrieb dpreed at reed.com: >> One other point... you all probably don't know this, but shortly after I posted my first results, Joe Touch decided that I should be "banned" for arguing with the well-known troll, Richard Bennett, on this list. Apperently, disagreement with a troll is not OK. I am still moderated (are you), and my every post scrutinzed for disagreement with Joe Touch's views, apparently. >> For those who do not already know, Mr. Reed does remain blocked from posting to this list due to his violation of list policies prohibiting ad hominem attacks several years ago, which was decided in coordination with the IRTF E2E RG chairs at that time (when the list was part of that RG). The list has been run independently since the RG was closed, and is managed in coordination with an Advisory Group, as listed on our info web page. Mr. Reed has yet to acknowledge his violation, nor to assure us he would avoid such violations in the future. He remains blocked until that time. Joe (list admin) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130101/e6b00b41/attachment.html From detlef.bosau at web.de Wed Jan 2 03:18:08 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 02 Jan 2013 12:18:08 +0100 Subject: [e2e] Delivery Times .... was Re: Bandwidth, was: Re: Free Internet & IPv6 In-Reply-To: <20130102024321.057AC8E0090@frontend1.nyi.mail.srv.osa> References: <20130102024321.057AC8E0090@frontend1.nyi.mail.srv.osa> Message-ID: <50E41770.1090907@web.de> Am 02.01.2013 03:43, schrieb Clark Gaylord: > Don't be daft: there's no mystery about how you get 4 sec latencies. > Someone is holding it! Really! Why didn't I see this before..... > That's the point -- drop the damn packet already! Absolutely. We should always discard slow packets. Latencies become so neat that way. > If the service time for your queue is beyond some small-ish.number -- > measured in maybe tens of ms, you aren't doing anyone(*) any favors. > I strongly think, that your perspective is a bit oversimplified here.... > --ckg > > (*) except your router vendor, who already is chuckling all the way to > the bank for the over-engineered crap you force him to sell you > That's the other extreme of course. The truth will be - as often - in between. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130102/7168165a/attachment.html From mallman at icir.org Mon Jan 7 10:36:07 2013 From: mallman at icir.org (Mark Allman) Date: Mon, 07 Jan 2013 13:36:07 -0500 Subject: [e2e] bufferbloat paper Message-ID: <20130107183607.F196E59344E@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130107/a60fde8a/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130107/a60fde8a/attachment.bin From keithw at mit.edu Mon Jan 7 23:30:49 2013 From: keithw at mit.edu (Keith Winstein) Date: Tue, 8 Jan 2013 02:30:49 -0500 Subject: [e2e] bufferbloat paper In-Reply-To: <20130107183607.F196E59344E@lawyers.icir.org> References: <20130107183607.F196E59344E@lawyers.icir.org> Message-ID: Thank you, I thought this was a very interesting paper (and shared it with my labmate Katrina LaCurts, who I think was tickled to be acknowledged in an Internet measurement paper before Vern Paxson...). I had a few initial reactions: - I'm a little concerned with the use of Spamhaus PBL to classify residential IP addresses. For example, Amazon EC2, Rackspace Cloud, and some other Web hosting services are on the PBL. I realize this did not make a big difference to the paper's findings. - Reading the earlier technical report, I'm not surprised to see that most of the outgoing traffic from the CCZ users is either BitTorrent or a wireless security camera that's part of the CCZ experiment. I am surprised that less than 1% is UDP -- my understanding had been that BitTorrent had largely moved over to LEDBAT-over-UDP with NAT traversal (uTP) as their preferred transport whenever possible. Apparently I was wrong. - From what I understand, the RTT traces collected here principally measure the RTT on TCP data transfers *from* 90 users in Cleveland, who are on an experimental 1 Gbps home Internet connection, to peers across the Internet. In other words (to a first approximation) this is a study of the effect of BitTorrent uploads by the CCZ home users on the people who download from them. - I do wonder to what degree the RTT results here are dominated by BitTorrent downloads and would be different if typical HTTP traffic were also sampled. (Web traffic being much less likely to come from a CCZ home user, or even an ICSI or LBL user, to an Internet peer.) - In my experience bufferbloat is much more acute on a commodity home (or cellular) Internet link in the uplink direction, meaning that the traces with this method aren't the ones where one would find the worst standing queues. E.g. the home user behind a commodity cable modem or LTE client device who does an sustained TCP upload to YouTube while also talking on Skype. With a Samsung Galaxy Nexus smartphone sending a single unlimited elephant outgoing TCP CUBIC flow over Verizon LTE service with good reported signal strength, we have observed RTT going to > 60 seconds (in fact it keeps going up until the device apparently runs out of memory and crashes). We don't observe anything nearly this bad in the downlink direction. I see similar results on my own home commodity cable modem -- the problem of an elephant CUBIC flow is much worse in the uplink direction. (This might simply be that the buffer capacity is the same in each direction but the throttled throughput is much smaller in uplink -- I have not measured carefully.) - The finding that 73% of TCP downloads by CCZ, ICSI and LBL users fit entirely within the 3-segment initial window was new to me. I wonder if this was also the case in the previous ICSI and LBL traces discussed in RFC 6298 appx. A? Best regards, Keith On Mon, Jan 7, 2013 at 1:36 PM, Mark Allman wrote: > > [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/ > > > From ingemar.s.johansson at ericsson.com Mon Jan 7 23:35:30 2013 From: ingemar.s.johansson at ericsson.com (Ingemar Johansson S) Date: Tue, 8 Jan 2013 07:35:30 +0000 Subject: [e2e] bufferbloat paper Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> 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? 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Bufferbloat-3G.png Type: image/png Size: 267208 bytes Desc: Bufferbloat-3G.png Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130108/baa2f950/Bufferbloat-3G-0001.png From keithw at mit.edu Tue Jan 8 02:42:21 2013 From: keithw at mit.edu (Keith Winstein) Date: Tue, 8 Jan 2013 05:42:21 -0500 Subject: [e2e] bufferbloat paper In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> Message-ID: 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? 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/ > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: verizondown.png Type: image/png Size: 17545 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130108/97ee8844/verizondown-0001.png From ingemar.s.johansson at ericsson.com Tue Jan 8 04:19:17 2013 From: ingemar.s.johansson at ericsson.com (Ingemar Johansson S) Date: Tue, 8 Jan 2013 12:19:17 +0000 Subject: [e2e] bufferbloat paper In-Reply-To: References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> 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=70 the thoughput is ~15Mbps and the RTT~0.8s, giving a congestion window of 1.5e7/8/0.8 = 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 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 = 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 at gmail.com [mailto:winstein at gmail.com] On Behalf Of Keith > Winstein > Sent: den 8 januari 2013 11:42 > To: Ingemar Johansson S > Cc: end2end-interest at postel.org; bloat at lists.bufferbloat.net; > mallman at 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? 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/ > > > > > > > > From keithw at mit.edu Tue Jan 8 04:44:14 2013 From: keithw at mit.edu (Keith Winstein) Date: Tue, 8 Jan 2013 07:44:14 -0500 Subject: [e2e] bufferbloat paper In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> Message-ID: 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 window, for instance at T=70 the thoughput is ~15Mbps and the RTT~0.8s, giving a congestion window of 1.5e7/8/0.8 = 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 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 = 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 at gmail.com [mailto:winstein at gmail.com] On Behalf Of Keith >> Winstein >> Sent: den 8 januari 2013 11:42 >> To: Ingemar Johansson S >> Cc: end2end-interest at postel.org; bloat at lists.bufferbloat.net; >> mallman at 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? 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/ >> > >> > >> > >> > From ingemar.s.johansson at ericsson.com Tue Jan 8 05:19:41 2013 From: ingemar.s.johansson at ericsson.com (Ingemar Johansson S) Date: Tue, 8 Jan 2013 13:19:41 +0000 Subject: [e2e] bufferbloat paper In-Reply-To: References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA080493@ESESSMB205.ericsson.se> Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA08050D@ESESSMB205.ericsson.se> OK... Likely means that AQM is not turned on in the eNodeB, can't be 100% sure though but it seems so. At least one company I know of offers AQM in eNodeB. However one problem seems to be that the only thing that counts is peak throughput, you have probably 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 throughput slightly. I know and most people on these mailing lists knows that peak throughput is the "mexapixels" of the internet, one need to address other aspects in the benchmarks. /Ingemar > -----Original Message----- > From: winstein at gmail.com [mailto:winstein at gmail.com] On Behalf Of Keith > Winstein > Sent: den 8 januari 2013 13:44 > To: Ingemar Johansson S > Cc: end2end-interest at postel.org; bloat at lists.bufferbloat.net; > mallman at icir.org > Subject: Re: [e2e] bufferbloat paper > > 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 > window, for instance at T=70 the thoughput is ~15Mbps and the RTT~0.8s, > giving a congestion window of 1.5e7/8/0.8 = 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 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 = 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 at gmail.com [mailto:winstein at gmail.com] On Behalf Of > >> Keith Winstein > >> Sent: den 8 januari 2013 11:42 > >> To: Ingemar Johansson S > >> Cc: end2end-interest at postel.org; bloat at lists.bufferbloat.net; > >> mallman at 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? 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/ > >> > > >> > > >> > > >> > From mallman at icir.org Tue Jan 8 08:40:26 2013 From: mallman at icir.org (Mark Allman) Date: Tue, 08 Jan 2013 11:40:26 -0500 Subject: [e2e] bufferbloat paper In-Reply-To: <1357658975.013413296@apps.rackspace.com> Message-ID: <20130108164026.367FC5AAAAC@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130108/8d52c214/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130108/8d52c214/attachment-0001.bin From akella at cs.wisc.edu Wed Jan 9 17:40:58 2013 From: akella at cs.wisc.edu (Aditya Akella) Date: Wed, 9 Jan 2013 19:40:58 -0600 Subject: [e2e] Call for Presentations: Research Track at the Open Networking Summit 2013 Message-ID: <1C27D221-7EFD-41B0-B169-7C082056D85F@cs.wisc.edu> We apologize if you receive multiple copies of this note. ************************************************************************* Call for Presentations: Research Track at the Open Networking Summit 2013 ************************************************************************* Software Defined Networking (SDN) refactors the relationship between network devices and the software that controls them. Open interfaces to network switches enable more flexible and predictable network control, and they make it easier to extend network function. Several router vendors have introduced software development kits for programming their network devices, and many commercial devices support the emerging OpenFlow standard. Open Networking Summit (ONS) has emerged as the premier OpenFlow and SDN event. The first two ONS events were very well received. The events showcased invited presentations on SDN from industry and academic leaders; 20+ exhibits that demonstrated SDN technologies and products; and, two day-long tutorials for engineers and managers. The research community is actively pursuing a variety of important open issues in SDN. Examples include switch design and APIs that balance flexibility and performance; new applications to capitalize on the programmability of the network; transitioning an existing network to SDN, and many others. ONS 2013 will feature a new **Research Track** where researchers can present their cutting edge SDN work. The Research Track is designed to leverage the strong industry presence at ONS to bring to focus research problems that are highly relevant to the larger SDN community, to allow a free exchange of ideas, and to help build a focused community effort to explore and realize the potential of SDN. We encourage interested presenters to submit a two-page extended abstract describing their SDN research. While we are particularly interested in early stage work, we also welcome submissions that summarize published results. Submissions will be selected based on originality of the work, likelihood of spawning insightful discussion, and technical merit. Each accepted submission would be granted a long (20 minutes) or short (10 minutes) presentation slot. We solicit submissions on topics including, but not limited to, the following: - Applications of SDN in home, wireless, cellular, enterprise, data-center, and backbone networks - Application of SDN to network management, performance monitoring, security, etc. - Virtual appliances (e.g., firewalls, intrusion detection systems, load balancers, etc.) on SDN - Virtualization support in software-defined networks - Switch designs for SDN - Control and management software stack for SDN - Programming languages, verification techniques, and tools for SDN - Performance evaluation of SDN network elements and controllers - Hybrid SDN approaches (integration with other control planes) - Transitioning existing networks to SDN - SDN control plane abstractions Important dates Submission deadline: Feb 11, 2013 Acceptance notifications: Mar 1, 2013 Final version due: Mar 15, 2013 Research Track dates: Apr 16 and 17, 2013 Program Committee Aditya Akella, UW-Madison (Co-chair) Martin Casado, Nicira/VMWare Nate Foster, Cornell Albert Greenberg, Microsoft Guru Parulkar, Stanford Nick Feamster, Georgia Tech Atsushi Iwata, NEC Jeffrey Mogul, HP Labs Vijoy Pandey, IBM Jennifer Rexford, Princeton Prodip Sen, Verizon Amin Vahdat, Google/UCSD (Co-chair) For further details, please see http://opennetsummit.org/research-track.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130109/a10cef36/attachment.html From keithw at mit.edu Wed Jan 9 23:37:41 2013 From: keithw at mit.edu (Keith Winstein) Date: Thu, 10 Jan 2013 02:37:41 -0500 Subject: [e2e] [Bloat] bufferbloat paper In-Reply-To: <1354.1357740450@sandelman.ca> References: <81564C0D7D4D2A4B9A86C8C7404A13DA0801AF@ESESSMB205.ericsson.se> <1354.1357740450@sandelman.ca> Message-ID: Hello Michael, On Wed, Jan 9, 2013 at 9:07 AM, Michael Richardson wrote: > Have you considered repeating your test with two phones? Yes, we have tried up to four phones at the same time. > Can the download on phone1 affect the latency seen by a second phone? In our experience, a download on phone1 will not affect the unloaded latency seen by phone2. The cell towers appear to use a per-UE (per-phone) queue on uplink and downlink. (This is similar to what a commodity cable modem user sees -- I don't get long delays just because my neighbor is saturating his uplink or downlink and causing a standing queue for himself.) However, a download on phone1 can affect the average throughput seen by phone2 when it is saturating its link, suggesting that the two phones are contending for the same limited resource (timeslices and OFDM resource blocks, or possibly just backhaul throughput). > Obviously the phones should be located right next to each other, with > some verification that they are actually associated to the same tower. This is harder than we thought it would be -- the phones have a tendency to wander around rapidly among cell IDs (sometimes switching several times in a minute). We're not sure if the different cell IDs really represent different towers (we doubt it) or maybe just different LTE channels or logical channels. I understand in LTE it is possible for multiple towers to cooperate to receive one packet, so the story may be more complicated. In practice it is possible to get four phones to "hold still" on the same cell ID for five minutes to do a test, but it is a bit like herding cats and requires some careful placement and luck. Best regards, Keith From detlef.bosau at web.de Mon Jan 14 03:31:18 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 14 Jan 2013 12:31:18 +0100 Subject: [e2e] bufferbloat paper In-Reply-To: <20130107183607.F196E59344E@lawyers.icir.org> References: <20130107183607.F196E59344E@lawyers.icir.org> Message-ID: <50F3EC86.6050303@web.de> Am 07.01.2013 19:36, schrieb Mark Allman: in his paper; > As queues grow so does delay through the net- > work. While delay does not have an appreciable impact on > bulk TCP transfers it can degrade delay-sensitive traffic such > as Internet telephony conversations. Seems to me as if we were not talking about networks but about money pumping and the ? crisis. However, I have to thank for this statement. At least one aspect in TCP congestion control, particularly in equation based flavours, is the frequently written nonsense of estimating possible rates by the "latency bandwidth product", which should be called "latency throughput product". So, the higher the latencies are, the higher the "bandwidth estimators" will be => full buffers cause rates to increase. Sounds to me like a prime example for a iatrogenic problem. A second remark: > This phenomenon is > caused by a general over-buffering in router queues that hold > traffic that cannot be immediately forwarded. Is this the correct diagnosis? (Excuse me, I always have in mind ? and the most powerful women in the world. Our divine leader always wants to earn (!) money by austerity. Let the poor starve to death - so the rich get rich as they deserve.) What causes a queue to overrun? Is the reason ALWAYS, that traffic cannot be immediately forwarded? (I strongly believe, that there ARE such cases. However, these are very particular cases and we should have a very careful look at them.) Or could it bee, that we simply put too much data into our buffers? So, we should not only have a look at the SERVICE patterns - but at the ARRIVAL patterns as well. Detlef BTW: For those who do not believe me in my first statement, I strongly recommend to read > @article{ meyer, > author ="Michael Meyer and Joachim Sachs and Markus Holzke", > title ="{Performance Evaluation of A TCP Proxy in WCSMA Networks}", > journal ="IEEE Wireless Communications", > year = "2003", > month = "October" > } an impressive example of HOW BADLY delays in networks can be misunderstood. Recovery delays (i.e. there are endless retransmissions of the same data along the radio link) are mistaken as "delay" used in the "delay bandwidth product" and to make things worth the "bandwidth" is given by the gross data rate. Yes, I was strongly advised not to criticize colleagues in this way. However, as computer scientists take a published theorem for a proven theorem, it must be possible to say that a paper is crap when the paper is crap. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ From detlef.bosau at web.de Mon Jan 14 06:07:55 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 14 Jan 2013 15:07:55 +0100 Subject: [e2e] bufferbloat paper In-Reply-To: <50F3EC86.6050303@web.de> References: <20130107183607.F196E59344E@lawyers.icir.org> <50F3EC86.6050303@web.de> Message-ID: <50F4113B.4090201@web.de> Am 14.01.2013 12:31, schrieb Detlef Bosau: > At least one aspect in TCP congestion control, particularly in > equation based flavours, is the frequently written nonsense of > estimating possible rates by the "latency bandwidth product", which > should be called "latency throughput product". > > So, the higher the latencies are, the higher the "bandwidth > estimators" will be => full buffers cause rates to increase. ^^^^^^^^^^^^^^^^^correction: CWND estimators. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de ------------------------------------------------------------------ The nonsense that passes for knowledge around wireless networking, even taught by "professors of networking" is appalling. It's the blind leading the blind. (D.P. Reed, 2012/12/25) ------------------------------------------------------------------ From toke at toke.dk Thu Jan 17 15:50:22 2013 From: toke at toke.dk (=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=) Date: Fri, 18 Jan 2013 00:50:22 +0100 Subject: [e2e] Comparing Linux qdiscs in lab conditions (paper) Message-ID: <87bocnfjy9.fsf@toke.dk> Hello I've recently written and defended this university project report on bufferbloat as part of my masters programme: http://rudar.ruc.dk/handle/1800/9322 (or http://akira.ruc.dk/~tohojo/bufferbloat/bufferbloat-final.pdf if the first link doesn't work). The paper compares four different Linux qdiscs in a simple lab setup, and demonstrates bufferbloat, and the mitigation provided by fq_codel, quite well. The first couple of sections on how TCP and the Linux network stack work are probably known material to most people here, so feel free to skip to the experimental setup and results in sections 5 and 6. I hope you will find this interesting; feel free to comment and/or ask questions. :) -Toke -- Toke H?iland-J?rgensen toke at toke.dk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130118/414f320a/attachment.bin From ashwin.shirvanthe at gmail.com Thu Jan 31 10:13:21 2013 From: ashwin.shirvanthe at gmail.com (Ashwin Rao) Date: Thu, 31 Jan 2013 19:13:21 +0100 Subject: [e2e] Dataset on network characteristics of video streaming traffic made available Message-ID: Hello, We just made publicly available to the community the datasets we used for our paper Network Characteristics of Video Streaming Traffic. Ashwin Rao, Yeon-sup Lim, Chadi Barakat, Arnaud Legout, Don Towsley, and Walid Dabbous. In Proc. of ACM CoNEXT'11, Dec. 6--9, 2011, Tokyo, Japan. This dataset contains detail traffic logs of packets exchanged during YouTube and Netflix streaming sessions. For each streaming session, we used tcpdump to capture the packets exchanged between the streaming server(s) and our client. We then parsed these pcap files to log the packet timestamp, the tcp sequence number, and packet length of each packet exchanged between the streaming server(s) and the client. This dataset contains these logs along with other auxiliary information that we used to better understand the observed traffic patterns. The dataset can be downloaded from http://www-sop.inria.fr/members/Arnaud.Legout/Projects/streaming.html All details on this dataset are available in our CoNEXT'11 paper. Feel free to contact me for any questions regarding this dataset. Regards, Ashwin