From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: bloat@lists.bufferbloat.net, Eric Dumazet <dada1@cosmosbay.com>
Subject: Re: [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based TCP solution.
Date: Mon, 4 Jun 2012 05:01:33 -0400 [thread overview]
Message-ID: <CAA93jw7Wp86T+9i1EmaL45HWJMSWTNpVpgfRvc5XY4EkQAVUCw@mail.gmail.com> (raw)
In-Reply-To: <970EA2AB-A3C0-4B7F-837C-F4723A1388F7@gmail.com>
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/
next prev parent reply other threads:[~2012-06-04 9:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 1:32 Haiqing Jiang
2012-06-04 3:06 ` Jonathan Morton
2012-06-04 9:01 ` Dave Taht [this message]
[not found] <mailman.5.1338836403.6573.bloat@lists.bufferbloat.net>
2012-06-05 14:32 ` Ingemar Johansson S
[not found] <mailman.1.1338922801.461.bloat@lists.bufferbloat.net>
2012-06-06 12:30 ` [Bloat] Tackling bufferbloat in 3G/4G networks: A receiver-based, " David Collier-Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw7Wp86T+9i1EmaL45HWJMSWTNpVpgfRvc5XY4EkQAVUCw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dada1@cosmosbay.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox