From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by huchra.bufferbloat.net (Postfix) with ESMTP id 071FB21F8F7 for ; Wed, 16 Dec 2015 09:22:06 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id D6782200D8237; Wed, 16 Dec 2015 09:22:05 -0800 (PST) Received: from kmnimac.local (c-50-156-111-45.hsd1.ca.comcast.net [50.156.111.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 9AEA2200D8227; Wed, 16 Dec 2015 09:22:04 -0800 (PST) To: codel@lists.bufferbloat.net References: <6545444AE21C2749939E637E56594CEA3C10FA8B@gsp-ex02.ds.swin.edu.au> From: Kathleen Nichols X-Enigmail-Draft-Status: N1110 Message-ID: <56719DBA.8020105@pollere.com> Date: Wed, 16 Dec 2015 09:22:02 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] Fwd: [aqm] An independent implementation of CoDel in FreeBSD/ipfw/dummynet X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 17:22:29 -0000 Responses in-line. On 12/16/15 4:01 AM, Dave Taht wrote: > ---------- Forwarded message ---------- > From: Rasool Al-Saadi > Date: Wed, Dec 16, 2015 at 12:35 PM > Subject: [aqm] An independent implementation of CoDel in FreeBSD/ipfw/d= ummynet > To: "aqm@ietf.org" >=20 >=20 > Hello all, >=20 > 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. >=20 > 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: >=20 > 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 =3D 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 iteration= s 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 que= ue and the min RTT was an unloaded connection tested with short packet. If t= he 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 betwe= en 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 th= ey 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. >=20 > 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 =3D (unloaded) connection RTT + 2*ta= rget. 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 =3D 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). >=20 > Regards, > Rasool >=20 > _______________________________________________ > 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 >=20