Hi And thanks for an interesting report. I must say that this resembles LEDBAT quite a lot, with the exception that LEDBAT is a (mainly) sender based modification and may thus be easier to deploy. Like commented on this list (by Jonathan Morton for instance) it could be interesting to see how they compare. One flaw with delay based algos (which LEDBAT tries to solve) is the sensitivity to reverse path delay (similar issue with Vegas I believe), I guess your algorithm can have the same problem or. Does not mean that LEDBAT is free of problem...
Regards /Ingemar Johansson > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 3 Jun 2012 18:32:49 -0700 > From: Haiqing Jiang <[email protected]> > To: Eric Dumazet <[email protected]>, Dave Taht > <[email protected]> > Cc: [email protected] > Subject: [Bloat] Tackling bufferbloat in 3G/4G networks: A > receiver-based TCP solution. > Message-ID: > > <cao-4odhyzgkqd_xhqxsbim9+z93gx3rfyrv6i8zeo+9u_aq...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, All, > > Recently the researchers from Networking Research Group of > North Carolina State University (NCSU) have proposed an > interesting receiver-based TCP solution to tackle bufferbloat > in 3g/4g networks. > > They conducted extensive measurements in four major carriers > in US and the largest carrier in Korea to verify the severe > bufferbloat problem in currently commercial cellular > networks. They cited the work from Bufferbloat group and > further extended the work to cellular networks. Furthermore, > they revealed the untold implementation of TCP, an ad-hoc > solution to mitigate bufferbloat, in smartphone's network > stack (Android platform). The ad-hoc solution is sub-optimal > in many scenarios. > Actually it merely mitigate bufferbloat problem in some scenarios. > Therefore, the guys from NCSU propose a "Dynamic Receive > Window Adjustment" > scheme to tackle bufferbloat problem. The extensive > experiment results prove that the scheme is efficient and > light-weight. > > It's really excited to find the new direction to tackle > bufferbloat, on TCP layer instead of routers (like AQM). The > bufferbloat problem actually seems to be the most prominent, > comparing with other networks. > Therefore, we suggest the more efforts to tackling > bufferbloat problem in cellular networks and seeking a good > solution in TCP layer space. > > The link is attached: > ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2012/TR > -2012-6.pdf > > Thanks, > > -- > ----------------------------------- > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.bufferbloat.net/pipermail/bloat/attachments/201 > 20603/e71887b8/attachment-0001.html> > > ------------------------------ > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
