Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based, TCP solution

Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based, TCP solution

[David Collier-Brown]

On 06/05/2012 03:00 PM, Ingemar s Johansson wrote:
> 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
>
>
I wonder how the two schemes would interact, and if it would make sense
for the sender to adjust the send window in a similar manner?

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
(416) 223-8968

Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution

[Ingemar Johansson S]

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 <hqjiang1988@gmail.com>
> To: Eric Dumazet <dada1@cosmosbay.com>, Dave Taht
> 	<dave.taht@gmail.com>
> Cc: bloat@lists.bufferbloat.net
> Subject: [Bloat] Tackling bufferbloat in 3G/4G networks: A
> 	receiver-based	TCP solution.
> Message-ID:
> 	
> <CAO-4OdHYZGkqd_XHqxSBiM9+Z93gx3rFYrv6i8zeO+9U_aQACA@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>
> 
> ------------------------------
> 

Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution.

[Dave Taht]

Encouraging. High on my list has been taking a hard look at the gsm
and wifi stacks in light of fq_codel,
I was planning on picking a android phone or two to hack on in the
fairly near future. Any suggestions?

The paper shows that vegas is still not really an improvement on cubic,
and why is it nobody plays with westwood?

On Sun, Jun 3, 2012 at 11:06 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
> On 4 Jun, 2012, at 4:32 am, Haiqing Jiang wrote:
>
>> 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.
>
> I read the paper quickly, and this seems to be a good use of TCP timestamps.  It thus represents an additional way to solve (or at least mitigate) the problem in cases where the managers of bottleneck links are unwilling or unable to implement AQM.
>
> If you look far enough back in the list archives - search for "Blackpool", for example - you'll see that I implemented a somewhat cruder solution using the same basic mechanism - limiting the receive window to prevent a single TCP stream from attempting to occupy the entire buffer.  It was cruder because it simply chose a window size based on the bandwidth of the flow and an empirical relationship between bandwidth and last-mile-hop latency, and didn't attempt to use timestamps.  It made a big difference for traffic from my local cell tower to a desktop Linux machine.
>
> May I ask what happens if TCP timestamps are not available for a particular flow, particularly one that competes with a timestamped flow?  Such crude stacks are probably getting less common now, but they undoubtedly still exist.
>
> It would also be interesting to investigate what happens when your scheme competes with a number of LEDBAT based flows (eg. uTP), both with and without AQM in place.
>
>  - Jonathan Morton
>



-- 
Dave Täht
SKYPE: davetaht
http://ronsravings.blogspot.com/

Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution.

[Jonathan Morton]

On 4 Jun, 2012, at 4:32 am, Haiqing Jiang wrote:

> 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.

I read the paper quickly, and this seems to be a good use of TCP timestamps.  It thus represents an additional way to solve (or at least mitigate) the problem in cases where the managers of bottleneck links are unwilling or unable to implement AQM.

If you look far enough back in the list archives - search for "Blackpool", for example - you'll see that I implemented a somewhat cruder solution using the same basic mechanism - limiting the receive window to prevent a single TCP stream from attempting to occupy the entire buffer.  It was cruder because it simply chose a window size based on the bandwidth of the flow and an empirical relationship between bandwidth and last-mile-hop latency, and didn't attempt to use timestamps.  It made a big difference for traffic from my local cell tower to a desktop Linux machine.

May I ask what happens if TCP timestamps are not available for a particular flow, particularly one that competes with a timestamped flow?  Such crude stacks are probably getting less common now, but they undoubtedly still exist.

It would also be interesting to investigate what happens when your scheme competes with a number of LEDBAT based flows (eg. uTP), both with and without AQM in place.

 - Jonathan Morton

[Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution.

[Haiqing Jiang]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

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,

-- 
-----------------------------------

[-- Attachment #2: Type: text/html, Size: 1913 bytes --]