From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (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 9E9FC21F0BD for ; Thu, 13 Mar 2014 02:04:57 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j15so686367qaq.2 for ; Thu, 13 Mar 2014 02:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lwJ+lokJuWOy6qtJohXYUmTfjns51ZX4etDugqZLchk=; b=RzkO2Z5GZKPqvmGo2zWwjLuAZcamN0Th+AaDXWQs0SfqTIAj0b5NxuBTrlTzt5Hu9+ AmokMRY9CHfwV4lHQHDFQyLEZ+I2/RV3+a1mOm7EXh6hj/P1GnYcIO8zvJLf95HVGYQ/ ZkXUC0EtU7eDijuVk49Xh+91+lVJyY9neuyaEtRxmVn2f+W1CNe7AWmbQ3M0D/uYOuRN l+7DKvMW1ArUpc449Kz4Gy3YPrxe3rj2lJHrKNaiuBd48J0qj+pdZgbHuH9PRhs8AvVt PBatCIjdwGDhNb1oDyrHgVrHh0EV9R4cDCSKZS6L8Rx/Gr2VWNrPdkHyOh4x5vaeDV3s I48A== MIME-Version: 1.0 X-Received: by 10.140.19.79 with SMTP id 73mr666671qgg.73.1394701496187; Thu, 13 Mar 2014 02:04:56 -0700 (PDT) Received: by 10.96.224.101 with HTTP; Thu, 13 Mar 2014 02:04:56 -0700 (PDT) Received: by 10.96.224.101 with HTTP; Thu, 13 Mar 2014 02:04:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 20:04:56 +1100 Message-ID: From: Andrew McGregor To: Sebastian Moeller Content-Type: multipart/alternative; boundary=001a1134f2563f990404f4793f7b Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] interval target relation ship question 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: Thu, 13 Mar 2014 09:04:58 -0000 --001a1134f2563f990404f4793f7b Content-Type: text/plain; charset=ISO-8859-1 My intuition suggests something like: Target = 4ms + MTU sized packet duration Interval = target * 20 (But only if the resulting interval is more than 100ms) Possibly the packet duration may need a small factor (2 or 3) to get the balance right. On 13 Mar 2014 19:41, "Sebastian Moeller" wrote: > Dear Experts, > > Codel and especially fq_codel have massively improved > snappiness/interactivity of typical residential internet connections, as > shown in the cerowrt testbed and also in the french ISP free's roll-out of > coddled xddl modems. One observation has been that at low bandwidth the > latency/bandwidth trade-off does not seem to be ideal and an empirical > solution to this problem has been to increase the target as a function of > the available bandwidth. I realize that codel tries to accommodate for > low-bandwidth links by always allowing at least one packet in the queue. > But empirically that does not seem to be enough for good behavior on slow > links (I think the issue is that the bandwidth sacrifice seems a bit to > large)... > Currently we try to model what we know about free's approach in > cerowrt, basically we increase target as a function of bandwidth and also > increase interval be the same amount as target. Now having read section > "3.2 Setpoint" of > https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text=1makes a strong point that target should be in the range of 5-10% of > interval. So would it make more sense to increase interval so that after > adjustments new_target = 0.05*new_interval still stays true? Or would you > recommend to do something along the lines of: > new_interval = 100ms + known DSL link latency (can be in the range > of dozens of ms) > new_target = new_interval * 0.05 or new_interval * 0.1 > > I guess I will try to actually test the different approaches in the near > future, but would be delighted to get help establishing a decent hypothesis > before hand which modification actually will work best. > > > Bet Regards > Sebastian > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel > --001a1134f2563f990404f4793f7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

My intuition suggests something like:
Target =3D 4ms + MTU sized packet duration
Interval =3D target * 20

(But only if the resulting interval is more than 100ms)

Possibly the packet duration may need a small factor (2 or 3= ) to get the balance right.

On 13 Mar 2014 19:41, "Sebastian Moeller&qu= ot; <moeller0@gmx.de> wrote:
Dear Experts,

Codel and especially fq_codel have massively improved snappiness/interactiv= ity of typical residential internet connections, as shown in the cerowrt te= stbed and also in the french ISP free's roll-out of coddled xddl modems= . One observation has been that at low bandwidth the latency/bandwidth trad= e-off does not seem to be ideal and an empirical solution to this problem h= as been to increase the target as a function of the available bandwidth. I = realize that codel tries to accommodate for low-bandwidth links by always a= llowing at least one packet in the queue. But empirically that does not see= m to be enough for good behavior on slow links (I think the issue is that t= he bandwidth sacrifice seems a bit to large)…
        Currently we try to model what we know about fr= ee's approach in cerowrt, basically we increase target as a function of= bandwidth and also increase interval be the same amount as target. Now hav= ing read section "3.2 Setpoint" of https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text= =3D1 makes a strong point that target should be in the range of 5-10% o= f interval. So would it make more sense to increase interval so that after = adjustments new_target =3D 0.05*new_interval still stays true? Or would you= recommend to do something along the lines of:
        new_interval =3D 100ms + known DSL link latency= (can be in the range of dozens of ms)
        new_target =3D new_interval * 0.05 or new_inter= val * 0.1

I guess I will try to actually test the different approaches in the near fu= ture, but would be delighted to get help establishing a decent hypothesis b= efore hand which modification actually will work best.


Bet Regards
        Sebastian
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/codel
--001a1134f2563f990404f4793f7b--