From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 E84FB3B2A4 for ; Mon, 23 Sep 2019 03:44:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569224646; bh=wnglEFdX21ntICFDdG6KZj3utGLFBXe+0kSUN0PCs1Y=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=khSwfjTdKoENEvjzt0QHjdi5+saa8GaoVYRyo9P9zdoIvfCQIDOV25OPL0VYSXSGH QNPzIirL2qPUOTDnbKxOSrctoqA6sKpWcJY9P2HLRgCkTDHbp2v4hDt7XRq3J5mYqL 6pOFY2qTd9PbXdW1w9R7K3RbGu2l4G+AqdFtUVLg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MdebB-1hdWEB1miX-00ZdyY; Mon, 23 Sep 2019 09:44:06 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 23 Sep 2019 09:44:05 +0200 Cc: marco@heavenlysanctuary.com, cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <310A6A0A-04F6-4EB9-B9AA-912B8E66C4BF@gmx.de> References: To: Jonathan Morton X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:g0W09AYdNpbVd30lN4gl8MTHMb5IAmq1GPAFgMHdCXA5rhG4IBE 1ZRf0q9DfROBlOBM593CmmTyt5/QTfrneXE1ozeCkCf5DBWgot9oD4Sh/14AoeIbgRUOCIB 0vcQcjpLNHf72vDC46GMFAYwCHGGrbX+QTCxKNpltB/xROuw2vAZf5ssDs8ac/qKbTt1l4J BwOhK7qM4Q61fzew0sxog== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:INFOwLHfv4o=:KpDCTPMZuLQRkT3Dq9nf3x j0hMrqKLadIHRQt7fskatLUG2Xy+onJQBmgoYzZwseuK888UNYevB5fOqdd9SJ8FcU7yJ6ex6 pM9HIfd+XxEtBZHZRvDIgbCuxGPhi0G1DIovzcf8UFOVXt+jbNaIuoVlfDfYntWG1rNSbrgFx GyIYPBwb+JuZrxPI5QXEgorKpn0ezevVeVO0ymJNJ10Qp5Xlv8auLxbRUn6WUQVvvZWOj3dD8 5rHvL/d+PQW9fWGUIGwmEUJO0jedGUgsmcQ96TYrmNefWICuQ+YBgkzYwQcGrr1pQOGU9WYWD 7LGuraVicdcuVH/Rxn9ndcRZLEJSII0orO4hka1YkJcpY5hsIvkIA0AHDvUEWy7pOdYFOtycK RRdzCq5v1IJMTLXzmt3e1LAmmnUgTJHaRs6kThY4euR0xSsl4h2wcV860TdFajNgkKp8pimoo krk8+5Jr4ENggwQJa38QcIYlEZ+F8D2DSJ+sYKVksA1KETD1CzsNpVYYTJ+SYhG5kcIs64NHZ TQRWoYUZELG7OogoQSoljtkEmvxobCVbKLsyhtjrMBLdKNnxvqyU/RotjQrMBeKVo85NETyV9 KO9HBnYeovMTw5Qqdh2xUrIcgL3OcDe/iX/s2NX4vwNFssUdWkiWSb+lzSZVwUqnSbUQea4eq FQUBh8rTMobLsXWdKySm2n3LFAOLb34LxJraQn7qjSa1pbxmYrZT/80a0rHvK2K40W0OfD+95 IC7kF/lQKwZxUzZ3HN9kY4DuHJuynRCsx9M1PPif0PBY9cCrBgSkhs4a+T9GFk5KyfefbjltZ b1pDI3o82WXwHzVhINyyU7nbJSXgZRaZBdXY53U+eXlFExl/w0dcrFQ2O4oVbQqEwo6zFDTNY UvJ/VBDd/woAyP776l5F1JPe7xTuh0WPcHSgjYSzvqtGXtKEkVtksF977ECSgkrRAEw3T+o0a XS4gU86nQqm2kbrpOPVhiBHYHE4YVdqR6z5Yuruerax8SjOSYuGCRbay1dF0AP5/lSshe4tpK qjGWBNC5hxo6NH7+vKuJI1s6gexIhwWBVdlIo4QfH2fwZcgc+ggGPrIzYSF0fr7o5YgqlBW0y xvSB8epRlA1OR0KSH+YNXB8nfVcXUhKKYAQE5n8ixnDpgiKslK+nru4CWAPlICLbrWDQ5LzW8 gSEaP5jafuvl9yXxIGAIauOrZmFi2NU7WMX5SPpW6TKcESGGC+ky9748rEn2U6GENWh3HmFFJ JFAfXRA70RnhA74ABSKDEwgoBPYh1SnYD02nXz2e7PZNbaEbkU6UedmRQoSM= 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 07:44:14 -0000 > On Sep 23, 2019, at 06:26, Jonathan Morton = wrote: >=20 >> 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. >=20 > 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. Ethernet will assume 38 bytes of overhead, including the = "silent" inter-frame-gap overhead (which essentially is a gap in = transmission sized so that one could transmit 12 octets instead), for = real active ethernet over fiber that should be correct (maybe it needs = another 4 bytes if a vlan tag is used). But according to = https://www.lightreading.com/gigabit/fttx/verizon-preps-next-major-broadba= nd-upgrade/d/d-id/722062 verizon uses GPON, and all we know about GPON = is that is uses a 5 byte GEM header which replaces parts of the ethernet = overhead (IFG, Preamble, SFD, -> 12+7+1 =3D 20Bytes) for an estimated = per packet overhead of 38-20+5 =3D 23 Bytes. But I do not know how much = additional "hidden" overhead GPON adds to each packet. So "ethernet's" = 38 bytes should be a decent safe bet (it is always better to = over-estimate per-packet-overhead, as otherwise small packets will fool = the shaper). >=20 >> 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: >=20 > 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. >=20 > 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. >=20 >> 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. >=20 > 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. I am not 100% sure the "likely to be seen in the wild" = assumption still holds, ds-lite will easily add another 40 bytes of = overhead for IPv4 packets (as will other IPv4 in IPv6 encapsulations)... >=20 > 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. =20 +1, for any given packet-size under-estimation of either = gross-shaper-rate or per-packet-overhead can be compensated by = over-estimating the other, and since most speedtests employ large = packets that can lead to under-estimation of the overhead which will = cause bufferbloat if there are enough small packets in flight (for which = effective transmit duration estimation will be too small with too little = overhead leading to observable bufferbloat). > For fibre I would try "ethernet" and reserve about 1% bandwidth each = way, then if possible test to see whether there is any bloat. First the iteration, perform a speedtest and plug the resulting = goodput numbers into cake as gross-shaper-rates, and then you can slowly = increase these limits until you see latency under load increase more = than you are willing to accept. I would first keep the ingress/download = rate at goodput number and optimize egress/upload and then do the same = for the ingress rate. Ideally use a bidirectionally saturating speedtest = (like flent's RRUL or RRUL_CS8), as that will typically be more = sensitive and show a higher magnitude of latency under load increase for = the same settings than doing the up-/downloading tests sequentially.=20 Best Regards Sebastian >=20 > - Jonathan Morton > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake