From: Jonathan Morton <chromatix99@gmail.com>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Thinking about ingress shaping & cake
Date: Sun, 12 Apr 2020 14:02:39 +0300 [thread overview]
Message-ID: <43C11592-F4CF-484D-AFB7-037D1C961906@gmail.com> (raw)
In-Reply-To: <F8BBD54C-8DF3-47A7-AE3D-560DD1A34449@darbyshire-bryant.me.uk>
> On 12 Apr, 2020, at 11:23 am, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
> I’m wondering what the relationship between actual incoming rate vs shaped rate and latency peaks is? My brain can’t compute that but I suspect is related to the rtt of the flow/s and hence how quickly the signalling manages to control the incoming rate.
There are two important cases to consider here: the slow-start and congestion-avoidance phases of TCP. But in general, the bigger the difference between the link rate and Cake's shaped rate, the less latency peaks you will notice.
Slow-start basically doubles the send rate every RTT until terminated by a congestion signal. It's therefore likely that you'll get a full RTT of queued data at the moment of slow-start exit, which then has to drain - and most of this will occur in the dumb FIFO upstream of you. Typical Internet RTTs are about 80ms. You should expect a slow-start related latency spike every time you start a bulk flow, although some of them will be avoided by the HyStart algorithm, which uses increases in latency as a congestion signal specifically for governing slow-start exit.
In congestion avoidance, TCP typically adds one segment to the congestion window per RTT. If you assume the shaper is saturated, you can calculate the excess bandwidth caused by this "Reno linear growth" as 8 bits per byte * 1500 bytes * flow count / RTT seconds. For a single flow at 80ms, that's 150 Kbps. At 20ms it would be 600 Kbps. If that number totals less than the margin you've left, then the peaks of the AIMD sawtooth should not collect in the dumb FIFO and will be handled entirely by Cake.
- Jonathan Morton
next prev parent reply other threads:[~2020-04-12 11:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 13:16 Kevin Darbyshire-Bryant
2020-04-10 14:14 ` Jonathan Morton
2020-04-12 8:23 ` Kevin Darbyshire-Bryant
2020-04-12 9:47 ` Sebastian Moeller
2020-04-12 11:02 ` Jonathan Morton [this message]
2020-04-12 13:12 ` Kevin Darbyshire-Bryant
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=43C11592-F4CF-484D-AFB7-037D1C961906@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
/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