From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 6BA3F3B2A4 for ; Mon, 23 Sep 2019 00:26:40 -0400 (EDT) Received: by mail-lf1-x131.google.com with SMTP id w67so9008022lff.4 for ; Sun, 22 Sep 2019 21:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Df3pEO3cNCft4LJ3fkAjxOiiXfNtrJGSEIB9oaRBThI=; b=OZMPGeBooOdHPfI1w5XwG3ajvvFCqmduAubx9lwDo8p6ELLbyyc/57oiQUdf1R7Smf pAeEr89nZJaLQDm1KFcxIP494pzCBd7aTI7DX0gmrKFa2V37rXr5ah1MU9EHkDMb3oXK 2hE1JRfVn5w2ixy2IE5zO3JrFdT8smljhupnsezA1tH6DmRThnSsw4evmCAC7wTm/lzZ v+EpXJR348Xm1Cu1yn23ngKlwepVJB4KM2hIi1aKVkS69eFW6euG6ex/bsZigGRpCq1i BSmme3XHsX4BuKUwVsUwehbx1D+WesFG9/m0tDDJUSXT50UBQ0qomaVOEYL7GsCibrTM B0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Df3pEO3cNCft4LJ3fkAjxOiiXfNtrJGSEIB9oaRBThI=; b=YRnNC/xBitTr+RKsMS43bN4GUrjykGbCHnfVEgkxCunzamYI4+vFt8LQnSsS7uzaNl W+Y3RahRZjtaLU2wOF6GwZao7os9Jlrz0zX6s3E3VXZLUHAZTskjKuyHF4o0a3OIM2Id axOtdMahlSkJtV7AjBAbYGgOuPeYvPeYgdLfmqwd10XGDfokmCfNJa0KDBGtJEu8BYQJ XcU2VZ1amDfdegSiOiOpc2In9vtldM79RN0db9MEkwqKqvtl4L4rO+AEGQHubLBD2UDD KOJHM594uPfpRRphzpaReV2xalkDmmQRKfNNiwo6TJHHIpktS58gZh6PpD8UVeWa/GwQ uJ0w== X-Gm-Message-State: APjAAAVkAePUbkeOM+YTI+TAYTlFoL4rc3/0JAmxaPF3c0ROIKIfioeE Ljal9Pfh8aub0mAtf9fc1eUddWMA X-Google-Smtp-Source: APXvYqwhv4nml/3/3G3H1oc+UcZ0bOA0l68wCXpjxdtvd9niQgBpSWHDYPT8nBBge1dssloEi5nRug== X-Received: by 2002:ac2:5965:: with SMTP id h5mr15377101lfp.129.1569212798880; Sun, 22 Sep 2019 21:26:38 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-236-164-nat-p.elisa-mobile.fi. [83.245.236.164]) by smtp.gmail.com with ESMTPSA id 28sm1958959lfy.47.2019.09.22.21.26.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2019 21:26:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Mon, 23 Sep 2019 07:26:36 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: marco@heavenlysanctuary.com X-Mailer: Apple Mail (2.3445.9.1) 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 04:26:40 -0000 > 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=