From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x230.google.com (mail-vn0-x230.google.com [IPv6:2607:f8b0:400c:c0f::230]) (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 220B421F268 for ; Sun, 12 Apr 2015 11:57:56 -0700 (PDT) Received: by vnbf1 with SMTP id f1so14208722vnb.5 for ; Sun, 12 Apr 2015 11:57:55 -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=aqowFrmdHuPJPO/p4zEhHeYWFMP9P38DjapqekjO4zQ=; b=m85u3VvJMBdgm3Ozeuw9amI21VpJRY1LFSYKwPP84g7yBcn9aIZhVe6w+PDjVQIYZ9 agOmVGA4+Rjv/FzeoME13lYShkucGRzMZwYz2BLo1OVfbpWPSaSKU0KLE96pe/k/j3+A Ch2FuLflcUeEyvibqM/Jiiz8JZUouW4QkhwyMiPrRmpLaOuAEpdPPABbQUJYAPWSeMWq NSD/5nns+YE1LzIoeiawTebBtaIY/ntc4izV17KsQp+Kd35KX9aPRE9JsfvaaIpRzQn5 SSALepBfvkFIZ1dkbWXbcsApa2BL7pW3XoztW52Jvw1LNSGn883+BhPe9fCvlwJpqojF MqUg== MIME-Version: 1.0 X-Received: by 10.52.33.180 with SMTP id s20mr13545093vdi.35.1428865075539; Sun, 12 Apr 2015 11:57:55 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Sun, 12 Apr 2015 11:57:55 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Sun, 12 Apr 2015 11:57:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 12 Apr 2015 21:57:55 +0300 Message-ID: From: Jonathan Morton To: Adrian Popescu Content-Type: multipart/alternative; boundary=20cf3079baae4274de05138b9355 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Cake3 - source code and some questions X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 18:58:25 -0000 --20cf3079baae4274de05138b9355 Content-Type: text/plain; charset=UTF-8 This is a question worth discussing. There is a certain amount of controversy over the actual meaning, utility and constraints of the target parameter, although the interval parameter is fairly well understood as a rough (order of magnitude) estimate of the prevailing RTT. Note that even with FTTP, while the RTT to the head end may be unusually low, the RTTs to interesting servers will still be in roughly the same range as on a good quality ADSL link. This is especially true if the interesting servers tend to be at the other end of the country/continent or on the other side of an ocean. This variability is within Codel's capacity. Due to the Diffserv and flow isolation features of cake, the latency minimization feature provided by Codel also isn't as critical to tune as it is when standalone, or with a lesser flow isolation system such as fq_codel's collision prone hash function. I think this is sufficient to make further tuning unnecessary up to 1 gigabit, whether on a LAN or over the internet, and since I haven't seen any home affordable gear for more than a gigabit yet - marketing tricks by Wi-Fi vendors aside - I don't think it's worth thinking too hard about pushing that higher in the home use case. Fq_codel also works quite well on a LAN already. The difference in a datacentre is that typical native RTTs are measured in microseconds, well outside the range that Codel is by default tuned for. The bandwidths involved also mean that the standard 5ms target invokes a large amount of buffered data. Additionally, we're inherently talking about a wholly local environment, so there is no need to adapt to internet scale RTTs. For those cases where you do have a datacentre like environment connected to an internet like environment, the solution is obvious. Deploy datacentre tuned AQM (which might be fq_codel with altered parameters) within the datacentre, and put cake at the gateway(s) to the internet. Job done. - Jonathan Morton --20cf3079baae4274de05138b9355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This is a question worth discussing. There is a certain amou= nt of controversy over the actual meaning, utility and constraints of the t= arget parameter, although the interval parameter is fairly well understood = as a rough (order of magnitude) estimate of the prevailing RTT.

Note that even with FTTP, while the RTT to the head end may = be unusually low, the RTTs to interesting servers will still be in roughly = the same range as on a good quality ADSL link. This is especially true if t= he interesting servers tend to be at the other end of the country/continent= or on the other side of an ocean. This variability is within Codel's c= apacity.

Due to the Diffserv and flow isolation features of cake, the= latency minimization feature provided by Codel also isn't as critical = to tune as it is when standalone, or with a lesser flow isolation system su= ch as fq_codel's collision prone hash function. I think this is suffici= ent to make further tuning unnecessary up to 1 gigabit, whether on a LAN or= over the internet, and since I haven't seen any home affordable gear f= or more than a gigabit yet - marketing tricks by Wi-Fi vendors aside - I do= n't think it's worth thinking too hard about pushing that higher in= the home use case. Fq_codel also works quite well on a LAN already.

The difference in a datacentre is that typical native RTTs a= re measured in microseconds, well outside the range that Codel is by defaul= t tuned for. The bandwidths involved also mean that the standard 5ms target= invokes a large amount of buffered data. Additionally, we're inherentl= y talking about a wholly local environment, so there is no need to adapt to= internet scale RTTs.

For those cases where you do have a datacentre like environm= ent connected to an internet like environment, the solution is obvious. Dep= loy datacentre tuned AQM (which might be fq_codel with altered parameters) = within the datacentre, and put cake at the gateway(s) to the internet. Job = done.

- Jonathan Morton

--20cf3079baae4274de05138b9355--