From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Prateesh Goyal <g.pratish@gmail.com>,
Hari Balakrishnan <hari@csail.mit.edu>,
ECN-Sane <ecn-sane@lists.bufferbloat.net>,
Mohammad Alizadeh <alizadeh@csail.mit.edu>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] abc congestion control on time varying wireless links
Date: Thu, 12 Dec 2019 13:31:01 -0800 [thread overview]
Message-ID: <CAA93jw5YD9eONNV746k8oQgo0bKj7Fw5eja2RoYqFCo9DRo3zw@mail.gmail.com> (raw)
In-Reply-To: <2CC1F0FF-4447-4860-BFE6-0C4CA3312953@gmail.com>
On Wed, Dec 11, 2019 at 12:12 PM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> > On 11 Dec, 2019, at 9:54 pm, Dave Taht <dave.taht@gmail.com> wrote:
> >
> > The DC folk want a multibit more immediate signal, for which L4S is
> > kind of targetted, (and SCE also
> > applies). I haven't seen any data on how well dctcp or SCE -style can
> > work on wildly RTT varying links as yet, although it's been pitched at
> > the LTE direction, not at wifi.
>
> It turns out that a Codel marking strategy for SCE, with modified parameters of course, works well for tolerating bursty and aggregating links. The RED-ramp and step-function strategies do not - and they're equally bad if the same test scenario is applied to DCTCP or TCP Prague.
That matches my preliminary observations. thx.
>
> The difference is not small; switching from RED to Codel improves goodput from 1/8th to 80% of nominal link capacity, when a rough model of wifi characteristics is inserted into our usual Internet-path scenario.
While I'm the author of the netem slotting code that does this bursty
wifi emulation, and delighted you are using it, it would better to
additionally use the delay distribution modelling feature added
shortly therafter by members of the stadia team. The distributions of
wifi delay with just slotting did not resemble the real world enough
for my taste after I fiddled with it extensively. There is a very,
very long tail.
(or conversely: making wifi retry algos match a sane model better
would be good - it makes no sense to have 30 dumb retries in the mac
layer! mac retries really dominate my pdv data at these vastly lower
levels of queuing)
I would love it if google were to publish the wifi distribution tables
they have developed since then for inclusion in iproute2.
>
> We're currently exploring how best to set the extra set of Codel parameters involved.
One of my thoughts after reading about the abc idea is that there is
an underused 4th state, in taking away both ect(1) and ect(0) on a
previously marked ect(0) stream as a sign you could accellerate. This
would only work if you were the only bottleneck router, of course, and
not with tcp as we know it.
I really like the idea of paced chirping in genera, as it could better
fill a wifi aggregate, and perhaps mitigate some of the exponential
overshoot problems in slow start (and this is separate from fiddling
with abc or other abc states)
> - Jonathan Morton
>
--
Make Music, Not War
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
next prev parent reply other threads:[~2019-12-12 21:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-11 19:17 Dave Taht
2019-12-11 19:19 ` Prateesh Goyal
2019-12-11 19:54 ` Dave Taht
2019-12-11 20:10 ` Dave Taht
2019-12-11 20:12 ` Jonathan Morton
2019-12-12 21:31 ` Dave Taht [this message]
2019-12-11 21:18 ` [Bloat] [Ecn-sane] " David P. Reed
2019-12-11 21:30 ` David P. Reed
2019-12-18 19:43 ` Dave Taht
2019-12-22 0:21 ` [Bloat] " Dave 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=CAA93jw5YD9eONNV746k8oQgo0bKj7Fw5eja2RoYqFCo9DRo3zw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=alizadeh@csail.mit.edu \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=g.pratish@gmail.com \
--cc=hari@csail.mit.edu \
/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