* Re: [Cake] perhaps pursuing sqrt(flows) one day?
2015-06-02 6:47 [Cake] perhaps pursuing sqrt(flows) one day? Dave Taht
@ 2015-06-03 15:47 ` Jonathan Morton
0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Morton @ 2015-06-03 15:47 UTC (permalink / raw)
To: Dave Taht; +Cc: cake
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
It's important to draw the right conclusions from a paper like that. They
ran their experiments using Reno and single drop-tail queues. As we know,
FQ and AQM both change those dynamics considerably. I'm also suspicious of
any approach which asks me to take a number of flows as an a priori
constant; we always need to handle the single flow case unless we can prove
otherwise.
It is however encouraging to see that the "imperfect" behaviour of a real
network (versus a virtual clocked simulator) erases the main argument
against pacing, that of synchronisation. Also that the primary throughput
benefits are seen in the early phases of a connection, which is where we
currently see the biggest bursts (from slow start) and the biggest queues
under AQM.
They do conclude that a queue sized to BDP/sqrt(flows) is adequate. The
corollary, which is probably more practically valid, is that N^2 flows are
required to achieve maximum sustained throughput, given Reno and a dumb
buffer sized to BDP/N.
For FQ, that corresponds to BDP*(flows^-1.5) per queue. Since throughput is
also divided evenly between flows, that in turn corresponds to
RTT/sqrt(flows) sojourn time. Since I now track the number of active flows
directly in cake, it is possible to calculate this correction factor to the
Codel parameters when that number changes, using the existing inverse
square root code (and, for small numbers of flows, the cache).
Before I actually try that, however, I'd like to know whether the
"fishcake" iteration of cake works better in the cases you were concerned
about.
- Jonathan Morton
[-- Attachment #2: Type: text/html, Size: 1733 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread