From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B1B5A3B2DA for ; Fri, 23 Sep 2016 07:54:53 -0400 (EDT) Received: by mail-wm0-x236.google.com with SMTP id w84so26976082wmg.1 for ; Fri, 23 Sep 2016 04:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ieZDJRKgfCg5wF5IeGv2JQYOBgxzhAd9vpBTjPMWAMc=; b=aaWs7FywLWW+T/ip0QqIv+Avf1whQO3dSGUMbXgmAdnVgiLb4nW/TbeOxlnHzYnmWx Ba1NftYRFGESnE7PCvgSs59P4AaIJ9oNs8hSMtN6X3WaOvzrGXBIgXnSngd+rMCaCt5g qLQd4cOFBujzwvUci0hmmpaT2qhRvCR26X44TO3ULFeWGu3We3wQdsSyDZ8Iwi8sUQSm WkgwKmoJ5MmI2wkpN/Gh1iEjhkzGetnM1h5TvbOKVGh6ZvNBX8n3CF8HDJbxOypC3nus MNI+p3rZCcocY6qovPmIoo4/LC6/Q/4HP191ivTzHF17Yi8DlecQAFlfza/Z/hLOe/2a D+tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ieZDJRKgfCg5wF5IeGv2JQYOBgxzhAd9vpBTjPMWAMc=; b=j9V8fCm3g+MdXx92W1kURxk1tsSTad5LM4PfaR3etrWdhTFdlUDxfvkTG2MYndmWS0 2Ly5zjoUadfXYVLsBGgO96FFXOiCsk4Q+c1V+/G5GSceddafS2lzvsUalibskD8cnq7u LqlJkr00CdeHdWghZvi1KUTfIQLDKWTJjJa1qNFjEqIqzcWp9E+i7OzLF3PaErJBV3Zb qFaG6psx2xzhFxjtShez8qCZjXjNbMbujVMxLCtqzFTCBnUVaZWoPbf9HO5isNyw1P6m Ts1hvpCakLysCGz/nQblYnw66kJQR8bInfQaYXIaFvT3REXJYOSFHAR5qw7LqS3R9Y5q YKjQ== X-Gm-Message-State: AE9vXwMq2T8/4Bng4TOUadtdQTrVpCviLvzbKIx4+te9Wach5ALAgercoeCTDeY/v0JqqQ== X-Received: by 10.194.178.130 with SMTP id cy2mr6536391wjc.138.1474631692796; Fri, 23 Sep 2016 04:54:52 -0700 (PDT) Received: from [192.168.72.54] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id n131sm2782099wmd.3.2016.09.23.04.54.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Sep 2016 04:54:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phineas Gage In-Reply-To: <75B6F546-894B-4257-95F6-5329273B07D1@gmail.com> Date: Fri, 23 Sep 2016 13:54:51 +0200 Cc: codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> <75B6F546-894B-4257-95F6-5329273B07D1@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] Using fq_codel with a WiFi uplink to the Internet X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 11:54:53 -0000 > On Sep 21, 2016, at 1:38 PM, Jonathan Morton = wrote: >> On 21 Sep, 2016, at 12:59, Phineas Gage wrote: >>=20 >> Question #1: Is it still effective to run fq_codel on our edge router = when I have a WiFi uplink to the Internet, instead of a cabled = connection like ADSL? And related to that, is a high quality = point-to-point WiFi connection indistinguishable from a cabled = connection as far as fq_codel is concerned? >>=20 >> Question #2: Assuming the answer to Question #1 is an overall "yes", = is it then better to have a guaranteed speed from the ISP, instead of = having a variable but potentially higher speed, so that I can control = the queue and have fq_codel and HTB prioritization work effectively? >=20 > This is actually a pretty interesting pair of questions. We=E2=80=99ve = just been doing quite a lot of work related to integrating fq_codel (or = something very like it) into the Linux wifi stack, where it has more = information about aggregation and other things, and can therefore make = smarter queuing decisions. >=20 > The very best solution would be for your WISP to integrate this work = into their hardware at each end of the link. It may take a little more = time until that can happen, as the code is very very fresh and still a = little raw. >=20 > Until then, I think something like what you=E2=80=99re already doing = should work well. Normally, fq_codel interacts badly with = high-performsnce wifi because it tends to distribute packets alternately = to different stations, which tends to prevent effective aggregation, but = this is not a concern for a point-to-point link where all your traffic = goes to and from one station to another. So, for example, if one runs fq_codel on a regular AP accessed by = multiple stations (using =E2=80=9Ctc=E2=80=9D, above the driver level), = this is not necessarily a good idea? And once the driver work is done = and the queues are managed at a lower level, will this no longer be the = case? >> Option A: We can choose a maximum of 40/40 Mbit with 1:5 aggregation, = meaning we could get 40 Mbit, but we could also get a lot less at times = (8 Mbit I assume), depending on other network load. >=20 > The 1:5 aggregation is worth exploring a bit more deeply. Usually = this refers to the ratio between the total bandwidth provisioned across = all customers (in some region and some service class) and the minimum = backhaul capacity within and at the far edge of the ISP=E2=80=99s = network. The theory is that customers tend not to use all of their = bandwidth all of the time, though they do tend to use all of it some of = the time. This theory works fairly well in practice as long as the = traffic patterns are not too correlated and are distributed over a = sufficient number of customers. >=20 > In order to be dragged down to 8Mbps, you would have to see all the = other customers sharing your backhaul trying to use 8Mbps or more (on = average) at the same time. This is unlikely to occur often; consider = major sportsball championship final matches, or national disasters such = as one we recently had an anniversary of, as the most likely triggers. = Under such circumstances, you=E2=80=99ll need to step in and manually = experiment to find out what works, but shaping at 8Mbps would be a = reasonable default reaction. >=20 > Of more concern to you is how much external load is needed to pull = your share of the backhaul significantly below 40Mbps - or, = alternatively, below the 20Mbps you can get with the more expensive = uncontended service. This will vary depending on how many customers the = 5:1 average is spread over - you can=E2=80=99t actually calculate it = from the information given. >=20 > So the question is whether they have a 40/40 backhaul shared among 5 = customers, or a 1G/1G backhaul which they plan to share among up to 125 = customers, each with 40/40 service. I think the latter is a perfectly = reasonable possibility, and would be much more robust than the former = option which would give you a reduction in throughput as soon as *any* = of the other customers on the same backhaul segment did *anything*. >=20 > It=E2=80=99s a question worth asking your WISP. Be ready to point out = that you don=E2=80=99t plan to actually *use* 40Mbps full-time, but that = your AQM solution depends on knowing how much bandwidth is available for = when *your* customers randomly demand it. Thanks a lot for this great information, I=E2=80=99ll ask them more = about what=E2=80=99s behind their aggregation ratio. As I mentioned in = one reply earlier, I may ask for flexibility in our contract, try the = aggregated service, then switch to guaranteed service depending on the = actual performance of their network. If I can rate limit to 30/30 and = fq_codel, and it=E2=80=99s 99% effective, I=E2=80=99d rather take that = than settle for a guaranteed 20/20 on-season and 6/6 off-season to get = to the same annual contract price. I see that this is a great place for helpful info about fq_codel. I = probably should have =E2=80=9Caggregated=E2=80=9D (word of the day) my = replies to reduce list traffic, so will do so next time if needed.