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.
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
