From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Ryan Mounce <ryan@mounce.com.au>,
Jonathan Foulkes <jfoulkes@evenroute.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] number of home routers with ingress AQM
Date: Wed, 3 Apr 2019 13:09:42 +0300 [thread overview]
Message-ID: <EB88B670-97E8-4B5C-8E13-030FBD37D4E7@gmail.com> (raw)
In-Reply-To: <C70FF9DF-5E5D-4F20-A992-27B0FE4700CE@gmx.de>
>> Fact is... ingress shaping is a hack.
>
> That is harsh, but I give you sub-optimal and approximate
As the designer of this particular hack, I would characterise it as a workaround. It *does* work, within certain assumptions which are narrower than for a conventional before-the-bottleneck deployment. Cake includes a specific shaper mode to help expand those constraints slightly.
One of the assumptions is indeed that the flows respond promptly to AQM, or are non-queue-building in the first place. Without that, the ingress shaper cannot exercise control over the contents of the dumb bottleneck queue upstream of it. There is no clear relationship between the fill levels of the two queues; the dumb one can be full but only trickling into the smart one downstream.
Conventional TCP traffic responds to a CE mark after one RTT and should clear its excess traffic from the queue well within two (assuming congestion-avoidance mode); if the AQM also has a response delay built in (as Codel does), that may result in 3 RTTs between congestion onset and establishment of control. Slow start is another matter entirely, but one I haven't analysed very throughly in this context; it's safe to say however that draining a 2x overshoot will take longer than a few-segment overshoot.
SCE would potentially remove some of that delay, as it signals immediately a queue appears, but we're still talking about one-plus RTTs delay before the dumb queue is drained. SCE also pulls the TCP out of slow-start soon enough to avoid a 2x overshoot (there's an interaction with sender-side pacing here; without pacing, slow-start is exited very early). This is the best-case scenario until the true bottleneck learns AQM.
L4S' modification of the response to CE goes in the opposite direction, unless the AQM is modified to suit. DCTCP stabilises at 2 CEs per RTT (each CE removes half a segment from the cwnd, while the Reno-linear growth function adds one segment per RTT). Codel grows its signalling frequency linearly over time; if its interval is set close to the actual path RTT (as is recommended), it will take 3 intervals/RTTs to reach the stability criterion for DCTCP, and a further 3 RTTs to control it all the way down to the true BDP.
This is not too bad in an FQ context, but how long would it take to correct a 2x overshoot from slow-start? DCTCP doesn't get a halving of cwnd per RTT until every single packet is CE-marked!
I think we need to set up a testbed with the new TCP Prague implementation to demonstrate these effects.
- Jonathan Morton
prev parent reply other threads:[~2019-04-03 10:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 11:38 Sebastian Moeller
2019-04-02 12:10 ` Mikael Abrahamsson
2019-04-02 12:35 ` Sebastian Moeller
2019-04-02 13:04 ` Mikael Abrahamsson
2019-04-02 13:28 ` Sebastian Moeller
2019-04-02 13:33 ` Ryan Mounce
2019-04-02 14:11 ` Jonathan Foulkes
2019-04-02 21:10 ` Ryan Mounce
2019-04-02 14:14 ` Jonathan Foulkes
2019-04-02 14:58 ` Sebastian Moeller
2019-04-02 13:51 ` Jonathan Foulkes
2019-04-02 14:14 ` Jonathan Foulkes
2019-04-02 16:20 ` Jonathan Morton
2019-04-02 16:38 ` Sebastian Moeller
2019-04-02 13:15 ` Ryan Mounce
2019-04-02 13:34 ` Mikael Abrahamsson
2019-04-02 13:38 ` Ryan Mounce
2019-04-02 14:02 ` Mikael Abrahamsson
2019-04-02 13:34 ` Sebastian Moeller
2019-04-02 23:23 ` Ryan Mounce
2019-04-03 8:16 ` Sebastian Moeller
2019-04-03 10:09 ` Jonathan Morton [this message]
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=EB88B670-97E8-4B5C-8E13-030FBD37D4E7@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=jfoulkes@evenroute.com \
--cc=moeller0@gmx.de \
--cc=ryan@mounce.com.au \
/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