From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 9E6B621F3ED for ; Thu, 16 Apr 2015 05:14:11 -0700 (PDT) Received: by qgeb100 with SMTP id b100so4367466qge.3 for ; Thu, 16 Apr 2015 05:14:10 -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=dSTrkfPywZaO90Yb3edZBYUjHrBURQz9z7ndq2pdSDE=; b=DQyPlR/lDPKm3hRtAH3On6gyF8w17eoMuAkSKDdAdMCeHWNlPx7YK7BE1tMJneoPxM 8Dh3R+uKioUeuldvOuW9VQqLyUuGwxuvh0MPhoYg368Jby5Nc/eg6LJOFk+feKmO+Vtj fF1lDMMptN4e1eNXaIC44xbc1KWnvLbuqhrIWgD5ce2Ug4AxXdGL4XvcxxSVY2KoD0Eh xaplu/kWfjAETePe+gtvyOfkz0qE42DV7wfd+gnibZu3BuBMm47cvOX0cy/u8uMy1++J PPHv8Ypbf77TRn5bVh+PxXpljArnhgMBHg3f1iRlcqMHxfn/oFi3A7G3vcNrqhSV4y91 900w== MIME-Version: 1.0 X-Received: by 10.55.48.16 with SMTP id w16mr61901101qkw.13.1429186450171; Thu, 16 Apr 2015 05:14:10 -0700 (PDT) Received: by 10.140.30.52 with HTTP; Thu, 16 Apr 2015 05:14:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Apr 2015 15:14:10 +0300 Message-ID: From: Adrian Popescu To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 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: Thu, 16 Apr 2015 12:14:39 -0000 That answers my question. Will the changes to codel made by cake be put into fq_codel? On Sun, Apr 12, 2015 at 9:57 PM, Jonathan Morton wrote: > 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