Re: bufferbloat paper

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 <[email protected]> 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/
>
>
>