From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Control theory and congestion control
Date: Sun, 10 May 2015 21:32:38 +0300 [thread overview]
Message-ID: <1F323E22-817A-4212-A354-C6A14D2F1DBB@gmail.com> (raw)
In-Reply-To: <152DD781-725D-4DD7-AB94-C7412D92F82C@gmx.de>
> On 10 May, 2015, at 19:48, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> Congestion control looks like a simple problem too. If there is no congestion, increase the amount of data in flight; if there is, reduce it. We even have Explicit Congestion Notification now to tell us that crucial data point, but we could always infer it from dropped packets before.
>
> I think we critically depend on being able to interpret lost packets as well, as a) not all network nodes use ECN signaling, and b) even those that do can go into “drop-everything” mode if overloaded.
Yes, but I consider that a degraded mode of operation. Even if it is, for the time being, the dominant mode.
> 1) Competiton with simple greedy non-ECN flows, if these push the router into the dropping regime how will well behaved ECN flows be able to compete?
Backwards compatibility for current ECN means dropping non-ECN packets that would have been marked. That works, so we can use it as a model.
Backwards compatibility for “enhanced” ECN - let’s call it ELR for Explicit Load Regulation - would mean providing legacy ECN signals to legacy ECN traffic. But, in the absence of flow isolation, if we only marked packets with ECN when they fell into the “fast down” category (which corresponds to their actual behaviour), then they’d get a clear advantage over ELR, similar to TCP Vegas vs. Reno back in the day (and for basically the same reason).
The solution is to provide robust flow isolation, and/or to ECN-mark packets in “hold” and “slow down” states as well as “fast down”. This ensures that legacy ECN does not unfairly outcompete ELR, although it might reduce ECN traffic’s throughput.
The other side of the compatibility coin is what happens when ELR traffic hits a legacy router (whether ECN enabled or not). Such a router should be able to recognise ELR packets as ECN and perform ECN marking when appropriate, to be interpreted as a “fast down” signal. Or, of course, to simply drop packets if it doesn’t even support ECN.
> And how can the intermediate router control/check that a flow truly is well-behaved, especially with all the allergies against keeping per-flow state that router’s seem to have?
Core routers don’t track flow state, but they are typically provisioned to not saturate their links in the first place. Adequate backwards-compatibility handling will do here.
Edge routers are rather more capable of keeping sufficient per-flow state for effective flow isolation, as cake and fq_codel do.
Unresponsive flows are already just as much of a problem with ECN as they would be with ELR. Flow isolation contains the problem neatly. Transitioning to packet drops (ignoring both ECN and ELR) under overload conditions is also a good safety valve.
> Is the steady state, potentially outside of the home, link truly likely enough that an non-oscillating congestion controller will effectively work better? In other words would the intermediate node ever signal hold sufficiently often that implementing this stage seems reasonable?
It’s a fair question, and probably requires further research to answer reliably. However, you should also probably consider the typical nature of the *bottleneck* link, rather than every possible Internet link. It’s usually the last mile.
> True, but how stable is a network path actually over seconds time frames?
Stable enough for VoIP and multiplayer twitch games to work already, if the link is idle.
> Could an intermediate router actually figure out what signal to send all flows realistically?
I described a possible method of doing so, using information already available in fq_codel and cake. Whether they would work satisfactorily in practice is an open question.
- Jonathan Morton
next prev parent reply other threads:[~2015-05-10 18:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-09 19:02 Jonathan Morton
2015-05-10 3:35 ` Dave Taht
2015-05-10 6:55 ` Jonathan Morton
2015-05-10 17:00 ` [Cake] [Codel] " Sebastian Moeller
2015-05-10 14:46 ` [Cake] " Jonathan Morton
2015-05-10 17:04 ` [Cake] [Codel] " Sebastian Moeller
2015-05-10 17:48 ` Dave Taht
2015-05-10 17:58 ` Dave Taht
2015-05-10 18:25 ` Dave Taht
2015-05-10 16:48 ` [Cake] " Sebastian Moeller
2015-05-10 18:32 ` Jonathan Morton [this message]
2015-05-11 7:36 ` Sebastian Moeller
2015-05-11 11:34 ` Jonathan Morton
2015-05-11 13:54 ` [Cake] Explicit Load Regulation - was: " Jonathan Morton
2015-05-12 23:23 ` [Cake] " David Lang
2015-05-13 2:51 ` Jonathan Morton
2015-05-13 3:12 ` David Lang
2015-05-13 3:53 ` Jonathan Morton
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1F323E22-817A-4212-A354-C6A14D2F1DBB@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/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