From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F05B321F91D for ; Wed, 16 Dec 2015 07:25:36 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u65so49298066qkh.2 for ; Wed, 16 Dec 2015 07:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7zcMgOeLUtT9Hyij//MtE7Y+7EFticWFGRH37ahyc8k=; b=VzP96cXmnQLNmVmzoAwGx4IHrEV1409t2NoFjT32mUtjfnVJB7TqTtEh59QFlxAG2N MrWDsQa/t/g28ew+hy8qTI6MbWPAsT5KwHWcwTQZ9x2GGgXTw4kyVqIis+ryZEUZY0ZH EFs27C+iMqUl5LjbX9A0tfZgcZLeO879g/7g/SfHzYJUTay3sEivok2wDoospmyp/pYH LdwgN5RF6NxMwubPag16Pdk+aS+evW7xJZl2rsvoFPflvSDZZdULkMOUJ9mKU6YSMps2 T2a1Aj7ajhpRcoMatN+KQKsjl2KxOgyP6UbcUYSIF6owLXhazc8RsDwFfqtYJ84w+U5i nt8Q== MIME-Version: 1.0 X-Received: by 10.129.99.195 with SMTP id x186mr27602063ywb.345.1450279535251; Wed, 16 Dec 2015 07:25:35 -0800 (PST) Received: by 10.37.112.6 with HTTP; Wed, 16 Dec 2015 07:25:35 -0800 (PST) Date: Wed, 16 Dec 2015 16:25:35 +0100 Message-ID: From: Dave Taht To: Rasool Al-Saadi , "codel@lists.bufferbloat.net" , "aqm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] [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 15:25:59 -0000 On Wed, Dec 16, 2015 at 12:35 PM, Rasool Al-Saadi wr= ote: > Hello all, > > I am Rasool Al-Saadi, a PhD student at Centre for Advanced Internet Archi= tectures - Swinburne University of Technology. I and my supervisor Grenvill= e 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. groovy. I assume you are aware that there is already a bsd version of codel derived from the bsd-licensed codel linux sources? Certainly approve of doing one from the draft or paper or ns2 or ns3 models.... one of the reasons why cake is dual gpl/bsd licensed is to make it easier to produce a bsd version one day. I am delighted to see comcast funding independent work here (I would love to see a "qfq-codel" developed by someone as the bsd sources for QFQ are a bit easier to understand than the linux ones) > 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-co= de is straightforward to create functional CoDel code. However, we have som= e questions/confusion regarding CoDel I-D: yea! > > 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) ...", whi= le 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." yes.... that is the basic intent... but I agree it's confusing.... it's the inverse of the math - 5ms spent over target + 100ms =3D 1.05 times the interval. do you have a suggestion that would make it more clear? > > 2- In section 3.2 and 4.4, the text says the ideal setpoint is 5-10% of t= he interval (connection RTT). So, should we allow the user to specify the t= arget value as a percentage of the interval or an absolute value? I would argue for a percentage nowadays if I were to argue for anything, bu= t... the thing is, despite much fiddling with various aspects of the algorithm (I will let you know the list if you want and share the extensive test results) there seems to be very little reason to allow for the setpoint to be modified at all at any but the lowest bandwidths or shortest or longest RTTs. We outlined an existing problem in the fq_codel draft with setting the target at less than the actual link rate (1mbit needing 13ms for a big packet seems to need at >13ms target), but that is still at a folklore stage rather than thoroughly examined (which we are examining now in variants of "cake") - it would be really nice to obsolete target and just declare it to be, say interval >> 4, and just fiddle with the interval. We're trying out a few assumptions like that at *really* low rates, like 64k, now... with very mixed traffic from various flent tests. =3D=3D Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi > > Regards, > Rasool > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm