From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from web.heavenlysanctuary.com (web.heavenlysanctuary.com [74.80.207.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DD0D73B2A4 for ; Mon, 23 Sep 2019 02:57:17 -0400 (EDT) Received: from [192.168.10.101] (unknown [47.145.169.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by web.heavenlysanctuary.com (Postfix) with ESMTPSA id 63E9321E00A2; Sun, 22 Sep 2019 23:57:16 -0700 (PDT) Reply-To: marco@heavenlysanctuary.com To: Jonathan Morton Cc: cake@lists.bufferbloat.net References:

From: Marco Belmonte Message-ID: Date: Sun, 22 Sep 2019 23:57:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Thunderbird/70.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=3.0 tests=ALL_TRUSTED, NO_DNS_FOR_FROM, SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on web.heavenlysanctuary.com Subject: Re: [Cake] Frontier FIOS Framing X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 06:57:18 -0000

Thank you, Jonathan - I will add the ethernet keyword and run some tests to get a more precise reading of exactly what 1% should be in both directions and also play with the "dual-*host" settings and post back my findings or more than likely a few more questions :-)

Marco

On 9/22/2019 9:26 PM, Jonathan Morton wrote:

I have searched every nook and cranny of the bloated internet looking for any information I can find on whether Frontier/Verizon FIOS (assuming the only difference between the service offered by both Frontier and Verizon is in name only) requires any special framing parameters passed on to sch_cake's overhead settings. Most mentions of cake/fq/scm/etc and FIOS are ether very dated and inconclusive or I find messages and forum posts asking questions a lot like this one.

I don't know precisely what framing FIOS uses.  However, most provisioning shapers used by cable/fibre ISPs operate on Ethernet frames, so if you use the "ethernet" keyword you should match what the shaper is doing.  The proof of the pudding is in the eating, of course.

Currently this is what I have and am also curious if I should be using the "nat" keyword for both ingress and egress? I'm not entirely sure - see below:

If your box is doing NAT *and* you are using a flow-mode that depends on accurate internal host information, then you should have the "nat" keyboard on in both directions.  Otherwise it's more efficient to switch it off, though leaving it on does no harm otherwise.

The default flow-mode is "triple-isolate", which does use internal host information.  So do the "dual-srchost" and "dual-dsthost" modes, which are more precise but need you to specify which direction the traffic is flowing.  The "besteffort" and "flows" modes do not, but you should only use those if you're deliberately experimenting with something.

In absence of framing compensation I figured I should just go extreme by reserving more bandwidth than the qdisc needs because I also read somewhere I think that mentioned that if you don't compensate and are incorrect everything stops working as opposed to if you over compensate you might lose out on bandwidth but you'll still win in the latency department.

That's approximately correct, close enough for actual practice.  It's also why we included the "conservative" keyword, which applies the maximum amount of framing compensation that is ever likely to be seen in the wild - much more than you'd expect to see on a cable/fibre link, but only slightly more than on most ADSL lines.

The overhead compensation matters more with small packets than with the larger ones used for bulk transfers; for the latter, reserving a little more bandwidth will appear to make everything work.  For fibre I would try "ethernet" and reserve about 1% bandwidth each way, then if possible test to see whether there is any bloat.

 - Jonathan Morton