Dave,
I was careful to say fq_codel, not just codel.
I was assuming the scenario that fq_codel is most
pitched for; a home gateway or modem.
On Wed, 11 Dec 2013, Dave Taht wrote:
> >> In the event of a link going completely idle, and staying
> >> idle, there is hysteresis built into the code so it will retain that
> >> drop rate for a few
> >> hundred milliseconds (it's 8*interval in some versions of the code,
> >> 4 in others), before resetting count to 1 and the resulting estimation
> >> window to interval.
For fq_codel, new queues for new flows are coming
and going all the time, with instances of CoDel
coming and going as each queue comes and goes...
> >> [1] on fq_codel the values are cached,
too, but
well
I will try to explain
> >> later. yes, more work is needed in this area.
An explanation would be useful because I admit I
couldn't unpick the code enough to understand how
the learning by one Codel instance in one queue
can be picked up by another Codel instance in another queue...
Whatever, passing learning from one queue to
another won't help whenever the whole link goes
idle. And an access link is idle for the vast
majority of the time. The average percent
utilisation of a customer's link /during the peak
hour/ is in the low single digits (ie 1-3%). The
link is constantly idle for periods a lot longer
than 8*interval (about a second) even when a user
is actively using it, e.g. for browsing, and even
streaming is only active in bursts (assuming HAS).
> >> As debussy said: "Music is the *space* between the notes".
So, in the case that fq_codel is most targeted
for, the algorithm will start from scratch at the
start of the vast majority of new flows, which
means it will delay the first drop signal by
200ms. For TCP flows, this means slow-start will
tend to cause tail drop and overshoot before
fq_codel has hardly started to train. Further,
thin flows constantly re-start so they will
constantly experiencing this problem when their
idle periods are outside CoDel's brief caching time.
In the rarer case that a flow is long enough (or
enough other flows are present) for fq_codel to have trained...
> >> After that approximation of ideal
drop/mark rate is obtained, the algorithm
> >> goes quiescent until the next time the
target delay is consistently exceeded,
> >> at which point it schedules the next drop
at a little more than the stored
> >> previous drop rate. It then continually
seeks around that point up and down.
I believe "consistently exceeded" means "exceeded
for 'interval'" (100ms default). So for a long
flow, the signalling delay after crossing
threshold from below is not 200ms + RTT, but it is:
100ms + RTT + previous drop delay + a little.
Even if the previous drop delay is tiny, the
100ms interval still makes it very sluggish. E.g.
if RTT = 20ms, signalling delay = 120ms = 6 round trips. Am I right?
That doesn't matter for a bulk transfer within
its own fq_codel queue. But it does matter for a
thin stream using TCP where the delay of each
message within the stream matters. And it does matter for a r-t stream.
Further, these long flows are rare. So, given the
link frequently goes inactive, the learning from
one will rarely still be cached when another
comes along. Which is why the rate of increase in
drop frequency during training is important to
get right (that's my other thread with Van &
Kathie, which is still unanswered).
___________
I'm not saying Codel / fq_codel is particularly
worse than other AQMs in respect of this
signalling delay. My point was that all AQMs have
to introduce some signalling delay if they use
loss as a signal, but not if they use ECN. I'm
just responding on CoDel / fq_codel in particular
because that's where Jim took this conversation, which you picked up.
Bob
At 22:51 11/12/2013, Ilpo Järvinen wrote:
On Wed, 11 Dec 2013, Dave Taht wrote:
> On Wed, Dec 11, 2013 at 1:11 PM, Ilpo Järvinen
> <[email protected]> wrote:
> >
> > What this means in terms of TCP:
> >
> > The network/or you fq-queue (in case of fq_codel if you so want) won't be
> > all that busy according to CoDel once CoDel kindly "coddled" the TCPs,
> > that's the whole point of CoDel I'm told :-). This is because the queue
> > happens to be "under control" only if TCP backs off to below 5ms + RTT
> > level of utilization. ...Now remember the effect of beta here. If the
> > network remains more than "5ms busy", CoDel thinks that the queue is not
> > in control and keeps shooting again and
until eventually the network is no
> > longer "busy". The worst case beta * (5ms + RTT) is quite small
> > utilization and it takes time for a TCP to recover network busyness.
>
> You are trying to explain something to me in RED terms that doesn't
> happen in the real world.
??? This has nothing to with RED. I really don't know where you got that
one. It's all what TCP is doing, sawtooth etc. (I know Linux uses Cubic
so no need to point that out).
> packets get smoothed into the "RTT" which serves as inflight storage.
That's exactly the point here. When RTT >> threshold, you take MD beta
hit, the inflight storage will be affect as well.
> Go take a measurement please. Supplying a packet
> capture would help explain whatever you are seeing. tell us
> what kernel you are using and follow the guidelines.
That particular text snippet didn't come from any particular test, just
the algorithms (both TCP and CoDel) running in my head.
> >> In the event of a link going completely idle, and staying
> >> idle, there is hysteresis built into the code so it will retain that
> >> drop rate for a few
> >> hundred milliseconds (it's 8*interval in some versions of the code,
> >> 4 in others), before resetting count to 1 and the resulting estimation
> >> window to interval.
> >
> > True, however, it only means that you'll overshoot more or the time was
> > too short to retain the trained count in memory (and in that case CoDel
> > forgets it like you admit). Or do you think that the magic number applied
> > to count on the recall (was it "-2") works for all traffic?
>
> You are not looking at the current as-shipped code.
Heh, it was somewhat unfair to call me on that one considering how many
different variants of that particular recall have existed ;-). But you're
right, it's not exactly what would happen with that variant.
--
i.
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
