From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 936653BA8E for ; Sun, 17 Dec 2017 17:35:16 -0500 (EST) Received: from hms-beagle2.lan ([79.210.203.204]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LsTDk-1fAfOq3uo4-0123CB; Sun, 17 Dec 2017 23:35:13 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <0FF17103-0A62-4645-98AC-E1680C4711E8@darbyshire-bryant.me.uk> Date: Sun, 17 Dec 2017 23:35:11 +0100 Cc: Mark Captur , "cake@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <76EA61D6-85DB-487E-A57F-6605D410EACF@gmx.de> References: <73C84EA7-2ADD-4914-BBDE-92E8408C106F@gmx.de> <0FF17103-0A62-4645-98AC-E1680C4711E8@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:V1Dz8+VJgAq2k7AtNjiiSSLde9gbis0+N28xUV0GOUuEuvebi1L iMo2ak0F0GYGiEGTjqyoZ8nMTCzWThBYX4Q9IvlGEFojF1lB63KbkBG13Rj/6Qfu6CIZA/c 8oL7U2hLNDz5ie4iYehb/4lbBvk76IW7rGySBoNp2PUC5ijwGKt7Hhu0CzbY1AU252oQCJY oXJ3etsXC7HaN4Qc6h5bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yoWPRs79f3M=:mJKmWSxTbSVj3R2NhQcpf5 6YpU897NJo8ncskHiebazjY3jr3WGVARp/ZbblhnkOmCHF7rWfmwhXBldB5hBzmSCmxiMke7V avcXKBe2Y7OLYK1rY6fBCStt/2h+z317njdVEgtlkK+ovxI7+byrLxyFmz0d/jBhDGAaRwWRB 74xwB3aPWq9ZcEcU7CkCJHg60sUZgzN4jIoA/wGgdmdIlbfVMPdQJfCzJLj1ZeJpQWtu82bbM 3EU/1TRN9bZnlvUne12pYDswEi110zEWRrUWIQ5fYCtobjlL7faiaEHgh0+DH/kgvk3CPP2hS ggyughIOaueTVNlK7BnPek2f9+9V4FVV+t7SXEuRVnvTCkjCHAA2pekBTyAjb9yKXDr0LXqe0 FjyGoE+7zd3d+lFSDXCkDtOjTTo2P5hN5EuJIkp/wEPcrUMTGAZ39rCjBC2AfA4joBG8GLBdj m4/1XQKCjKEoKVM2sfInOOQCI0oXMiymnW2hjsrbmT9oGqM9eQd4laPYsvyRzkbgrM2ubr1fG 4akGjoAIRBdDa1T5E73BAjhjEVm3xj0pdtiWdtPjzhIcpIz3o3NXuPpueS4Qc9ux6qvwRqdmo JpuzGGRxructNZIAm41W7/sDSahPeJRlo/xtN+Td6qD87ILJ7lVyLVczbI7ggPNQojufqV7O/ Io0/pdRjoC5LB5uP1YHW7noa4Vm4QBStbYgKlFUfaLW8+IXmJQ/atybclxw9vppToqgnsJXVo H/aZqvlDkae466cFazPsfkAuhzyHaYRVd+V1RqG/UheX4JIgdnAp3suEIJ+zt4UrkjixnzoyL 77UXDBpoIRMHqUZhhVO1dL5igdOHeo5+2oqexvawfdpMMSpOM4= Subject: Re: [Cake] overhead for double nat VDSL2 connection 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: Sun, 17 Dec 2017 22:35:16 -0000 Hi Kevin, hi Mark, Kevin is 100% right! > On Dec 17, 2017, at 20:23, Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 >> On 17 Dec 2017, at 15:23, Sebastian Moeller wrote: >>=20 >> Hi Mark, >>=20 >>> On Dec 17, 2017, at 11:45, Mark Captur = wrote: >>>=20 >>> My setup is as follows >>>=20 >>> vdsl2 modem doing pppoe itself and nat to 10.x.x.x -> lede master = eth0.2 (wan static ip in modem's DMZ) eth0.1 (lan) doing nat to = 192.168.1.x >>>=20 >>> Here is my current SQM config >>> config queue 'eth1' >>> option debug_logging '0' >>> option verbosity '5' >>> option qdisc 'cake' >>> option qdisc_advanced '1' >>> option ingress_ecn 'ECN' >>> option egress_ecn 'NOECN' >>> option qdisc_really_really_advanced '1' >>> option script 'layer_cake.qos' >>> option interface 'eth0.2' >>> option enabled '1' >>> option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-srchost = diffserv4' >>> option upload '2400' >>> option linklayer 'ethernet' >>> option overhead '8' >>> option squash_dscp '1' >>> option squash_ingress '1' >>> option iqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost' >>> option download '0' >>>=20 >>> config queue >>> option debug_logging '0' >>> option verbosity '5' >>> option download '0' >>> option qdisc 'cake' >>> option script 'layer_cake.qos' >>> option qdisc_advanced '1' >>> option squash_dscp '0' >>> option squash_ingress '0' >>> option ingress_ecn 'ECN' >>> option qdisc_really_really_advanced '1' >>> option egress_ecn 'ECN' >>> option interface 'eth0.1' >>> option enabled '1' >>> option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost = diffserv4' >>> option upload '30000' >>> option linklayer 'ethernet' >>> option overhead '8' >>>=20 >>> Is the overhead correct? should i use the bridged-ptm keyword (or = should i use pppoe-ptm). >=20 >=20 > Beware of using option linklayer =E2=80=98ethernet=E2=80=99 without = option linklayer_advanced =E2=80=981=E2=80=99 & option = linklayer_adaptation_mechanism =E2=80=98default=E2=80=99. Or use = linklayer =E2=80=98none=E2=80=99. =20 I guess "linklayer cake" would be better than none... > Failure to do so will make sqm-scripts use STAB for the link = accounting (in essence it lies to cake about the size of packets being = passed through it). Better to use cake=E2=80=99s built-in compensation = - fewer modules, less code. I agree, even though for ptm this is less dire than for ATM; = still use linklayer default or linklayer cake. >=20 > I was bitten by this myself very recently, lost 4 hours of my life & = many recompiles before I realised an innocent looking setting = (linklayer_advanced) was messing with the packet size (seen by looking = at max_len from tc) I am beginning to wonder whether the attempt to hide complexity = behind linklayer_advanced is not simply misguided and should be = jettisoned... >=20 >>=20 >> The overhead certainly seems confusing. Personally, I dislike = the overhead related compound keywords like *-ptm and would recommend = the following: >> 1) remove the bridged-ptm from the eqdisc/iqdisc fields >> 2) add "mpu 64" to the eqdisc/iqdisc fields >> 3) set overhad to 8+18+4 =3D 30 bytes (you will need to account for = everything added on the bottleneck, so your packets will be MTU 1492, to = leave room for the PPPoE header that the modem adds). > MTU 1492 ain=E2=80=99t necessarily so - some vdsl modems in bridge = mode support RFC 4638 with baby jumbo frames, thus supporting the normal = ethernet MTU of 1500 (and obviating the need to TCP MSS clamping) - ie. = if you can do it, you should ;-). You still need to account for the 8 = byte PPPOE overhead of course. And again, Kevin is correct; my rationale might have been faulty = but the recommendation still was correct though ;)... >> 4) DO not set the ptm keyword at all, instead make sure to set the = shaper bandwidth to <=3D sync bandwidth * 64/65 =3D sync bandwidth * = 0.984615384615 (to account for ptm's 64/65 encoding _without_ incurring = needless operations per packet). >>=20 >> 4) tell us about your ISP and plan ;) >>=20 > Cheers, >=20 > Kevin D-B Thanks for your input, as always very much appreciated! Best Regards Sebastian >=20 > GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A