Re: bufferbloat paper

Hi

It's really happy to know that you are verifying the problem I pointed out
in my paper. It's quite urgent to pay more attentions to the bufferbloat in
CellNet in my opinion.

But because of the lack of connections inside carriers (AT&T, Verizon,
etc.), in my work I still found some limitations to figure out the
fundamental answers to 1). where the buffers exactly are; 2). how the
buffers are built up with interacting with LTE/HSPA/EVDO protocols; 3). how
common it is for large scale daily life usage the problem could lower down
user experiences..... All those problems, I hope to see deeper discussions
in this maillist. Thanks....

Best,
Haiqing Jiang

On Mon, Jan 7, 2013 at 11:35 PM, Ingemar Johansson S <
ingemar.s.johansson-IzeFyvvaP7pWk0Htik3J/[email protected]> 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/
>
>
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat-JXvr2/[email protected]
> https://lists.bufferbloat.net/listinfo/bloat
>
>


-- 
-----------------------------------
Haiqing Jiang,
Computer Science Department, North Carolina State University
Homepage:  https://sites.google.com/site/hqjiang1988/

_______________________________________________
Bloat mailing list
Bloat-JXvr2/[email protected]
https://lists.bufferbloat.net/listinfo/bloat