* Re: [Codel] Fwd: [aqm] An independent implementation of CoDel in FreeBSD/ipfw/dummynet
2015-12-16 12:01 ` [Codel] Fwd: [aqm] An independent implementation of CoDel in FreeBSD/ipfw/dummynet Dave Taht
@ 2015-12-16 17:22 ` Kathleen Nichols
0 siblings, 0 replies; 2+ messages in thread
From: Kathleen Nichols @ 2015-12-16 17:22 UTC (permalink / raw)
To: codel
Responses in-line.
On 12/16/15 4:01 AM, Dave Taht wrote:
> ---------- Forwarded message ----------
> From: Rasool Al-Saadi <ralsaadi@swin.edu.au>
> Date: Wed, Dec 16, 2015 at 12:35 PM
> Subject: [aqm] An independent implementation of CoDel in FreeBSD/ipfw/dummynet
> To: "aqm@ietf.org" <aqm@ietf.org>
>
>
> Hello all,
>
> I am Rasool Al-Saadi, a PhD student at Centre for Advanced Internet
> Architectures - Swinburne University of Technology. I and my
> supervisor Grenville Armitage are implementing CoDel (and eventually
> PIE, FQ_CoDel and FQ_PIE) in FreeBSD targeting ipfw/dummynet framework
> as a small project funded by Comcast Corporation, USA.
>
> We used CoDel I-D
> (https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/) as the main
> source to implement CoDel and we believe that the information in the
> latest draft (draft-ietf-aqm-codel-02) sufficient and the pseudo-code
> is straightforward to create functional CoDel code. However, we have
> some questions/confusion regarding CoDel I-D:
>
> 1- There is little confusion in the text. In section 3.3, the text
> says "... the initial drop spacing SHOULD be set to the estimator's
> interval plus twice the target (i.e., initial drop spacing = 1.1 *
> interval) ...", while in section 4.1, the text says "As discussed in
> section 3.3, the initial next drop spacing is intended to be long
> enough to give the endpoints time to react to the single drop so
> SHOULD be set to a value of 1.0 to 1.1 times the interval."
Some of this is a result of our sloppy editing over a couple of iterations
with lots of time in between. But, the initial idea of the interval was
that it should be long enough to permit reaction by the endpoints under
"normal" operating conditions. This means at least the "unloaded" or
minimum RTT which includes the transit time of packets on intermediate
links but also includes reasonable queuing time at both ends. Because a
lot of early testing by ourselves and others was done with simulations,
setting RTT
values is exact (unlike real life) so you will see a drop off in
performance (and
an increase in unwarranted drops) if the interval is set to be the link
delay time
without taking into account any extra, reasonable delays. For example,
if both
ends of the connection have 5 ms (or 5% of a 100ms interval) worth of queue
and the min RTT was an unloaded connection tested with short packet. If the
initial drop interval is taken to be exactly the min RTT, there will be
drops that
shouldn't happen (this should be easy to figure out and also can be
tested in a
simulation). As always, the setting of the interval is a compromise between
keeping it long enough to avoid making unnecessary drops and short enough
to permit a quick reaction. And the terminology here IS confusing because
early on we had a "drop interval" and an "interval" before we realized they
should be the same thing. So the above should probably read that the
interval
should be set to the usual or expected RTT times 1.0 to 1.1. In the real
world,
if the RTT is taken from traffic, a factor of 1.0 or slightly more is
probably okay but in the simulation world where the RTT is being _set_,
then you need to move it toward the 1.1 factor. And the usual or
expected RTT is really the upper bound of the connections you expect to
be most prevalent.
>
> 2- In section 3.2 and 4.4, the text says the ideal setpoint is 5-10%
> of the interval (connection RTT). So, should we allow the user to
> specify the target value as a percentage of the interval or an
> absolute value?
This is sort of consistent with the above. But take away inteval and
leave in connection RTT. So interval = (unloaded) connection RTT + 2*target.
The 1.0 to 1.1 factor is including the target at both ends.
So, no, you would not normally let the user set the target value. You
get the "usual RTT" from the expected use of the device. We were
initially focused on a solution for the consumer edge though CoDel's
mechanisms have proven to be quite general. So for US
homes, perhaps a value of interval = 1.1 * 50ms would be good. If you
use 1.1 *100ms you are a bit slower to drop which might be okay. Given
that so many homes in the US
are attached to the internet via cable modem, it's good to give this a
bump because of
the extra delay of their MACs.
What I've been saying all along is that CoDel can do a pretty good job
over a robust range. But if I were looking for a way to make
improvements and contributions, I'd
think about looking at how to make the interval self adjusting (the
target can be adapted
accordingly).
>
> Regards,
> Rasool
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
^ permalink raw reply [flat|nested] 2+ messages in thread