Re: [Cake] Thinking about ingress shaping & cake

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 3804 bytes --]



> On 12 Apr 2020, at 12:02, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> 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.

Thank you.  That is really useful.

In case you all fancied a laugh at my expense and to show you what state of stir crazy I’m in due to lock down, here’s the analogy of queuing I came up with that explained to me why my queue departure rate must be less than the inbound rate.

So I imagined a farmer with a single cow only milking machine and a transporter that moves cows from the field to the milking machine(!)  As Mr Farmer turns up at the field, the cows saunter over to the gate.  The gate opens when there’s space for a cow on the transporter.  The transporter can move a single cow to the milking machine at an arbitrary 1 cow per 10 seconds (6 cows a minute).  The cows are interested at the thought of being milked so they arrive at the gate from around the field faster than 6 cows a minute.  So the cows naturally form a queue and wait their turn to go through the gate.

Mr Farmer has some special cows that must be milked in preference to standard cows.  So he installs some fencing and arranges them into two funnel shapes arriving at the gate.  The gate has been upgraded too and it can choose from which funnel to accept a cow.  If a cow is available in the special queue then it takes that cow, else it takes a standard cow.  A helper assists in directing the cows to the correct queue.

It’s at this point I realised that for the special/standard cow preference to make any difference the cows must be arriving faster than they can depart, otherwise there’s never the case that a standard cow has to wait for a special cow, they just walk on through.  I have to have a queue.

I won’t take the analogy any further since I’m aware of the ’special cow’ queue starving access to the ’normal cow’ queue and I’m not sure that controlling queue length when they all come running over (cow burst!) by culling cows is exactly ideal either :-)

Anyway welcome to my Easter madness :-)

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]