From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B93153B260 for ; Tue, 23 Aug 2016 10:27:22 -0400 (EDT) Received: from [172.17.3.48] ([134.76.241.253]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MhQju-1bpruU3tli-00MeXu; Tue, 23 Aug 2016 16:27:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Tue, 23 Aug 2016 16:27:10 +0200 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "techicist@gmail.com" X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:+ZHg0f4iCDclIkpsHBR1JCZF3WhUbq+rFU85XO17ODNU9rZKrC+ UyWLrY0PwSjCx1jqPPEaIeFKGpYXvI35X78XC8Vh0fqGACjXhRS/qraMyievkJv1Xj0aFxp WPLaEqe38cJDlFPA/yxh9/eecxVwUQsYgRz1/7c89C61PV/LbP9XcivgYynp90aM/vS0r2I 6XC1m8sJBjcNa/luofmVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:N3a34nWPsQc=:TtLKxJZRO9jKOJt9mJuIvy 0Kav6ZOhPPb9AxfTFkjBltwRWoSJGfZFsh9YXAAn60odkfWmnqzrZIDH+RQJCYYaQ0utBn7EP +jIcEQRTzQkBUxiOBeNLCPTJUwGrB44grzw6ekEoon1SVXB44e4lq/iLgb2Jz/lRFFP8214qr PvDm1JGO/9Flqmtgsx8P6i0bEF6gUeGFnzX/gcBAo5GM75ptbhD7aq0LD2vyNqpp0IKYYtJKb RNNyoSChipW+HgDmwGC4VB0OFdN4BqzyXJlyb0+r7tiXGqXsCP14ArjL+lv8B+IP6Ss6peVsT pWflwjNQTP6n3EDShRVsyDUUpztJgZ02dz/+hkisPLt4c+EM7DSn05wfvjbPk4TGSUgyshrcJ FgFCRp47M2VHVn0Oniq4+1VhDx9iAHxmDbrAlTiHEU0e24toAa6MStEGYRmQ0zhGPI0do5PD5 JGvO7Da9mCuUXeE91MxqfE261nxWyloAHt0r8zGDlmHz1PbI8O+acfO9Z09jiaRmhrOfovBM7 +nKCqkKG63e8kHkDYbaKiomaCfLltNj9tc3fJl/fp7vOH5OAQtp6CeV+HNhoHDpLTAB/7vDxO YFUqJAOGlJLCefbr3KAmB3zjY3JIedxtFm9vkk8pGkCdqbOwpF4zKVU0IUzEtHFpwKEcMA7dB AakXA/WgKmn1QPQ515ipX48dlOWEUMKoSRHbOuY/aXfDO6vaRnhPsPUYUkgTu6DjbAjmh1dvg ci5kF0x1BffsBrvLxnp7j3lULC5dHH5FOrfnTaUVxoZ+GalUtRZaAXpHS4vgKVLPGFuruULoi uADqxxq Subject: Re: [Cake] Configuring cake for VDSL2 bridged 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: Tue, 23 Aug 2016 14:27:23 -0000 Hi techicist, > On Aug 23, 2016, at 15:44 , techicist@gmail.com wrote: >=20 > I am using a TalkTalk (UK) VDSL2 connection via bridged PTM to my = TP-LINK Archer C7 V2. I am running LEDE. >=20 > TalkTalk uses DHCP to obtain an IP address and not DHCP as most other = ISPs do. I take it that one of the DHCPs should read PPPoE? >=20 > I am trying to configure cake and I see these options on = bufferbloat.net: >=20 > There are eight new keywords which deal with the basic ADSL = configurations. These switch on ATM cell-framing compensation, and set = the overhead based on the raw IP packet as a baseline. >=20 > ipoa-vcmux (8) > ipoa-llcsnap (16) > bridged-vcmux (24) > bridged-llcsnap (32) > pppoa-vcmux (10) > pppoa-llc (14) > pppoe-vcmux (32) > pppoe-llcsnap (40)bvn >=20 > How do I go about using these with OpenWRT? (C) None of the above ;) Really, all f the above keywords only deal with encapsulations used on = ATM links, not PTM links. All of these will automatically enable ATM = cell accounting and hence will not do the right thing on PTM links even = if the per-packet overhead should be correct. cake offers two PTM = specific keywords, pppoe-ptm and pppoe-bridged that translate into 27 = and 19 bytes respectively. It looks like they are not well enough = documented though*. I would recommend to simply ignoring these keywords = wholesale and use the explicit =E2=80=9Coverhead 27=E2=80=9D statement = instead, but we are getting ahead of ourselves here: The first question is what is the true bottleneck link and what = bandwidth and encapsulation is in use on that link. Often the VDSL2-link = is the true bottleneck, but some ISPS like DTAG in Germany actually = implement a shaper/policer at the BRAS/BNG level with lower thresholds = than the vdsl2 link itself. Be that is it may, the first issue is = figuring out the relevant bottleneck link bandwidth (we just assume that = your ISP has no shaper in use): Look into the status page of your VDSL2-modem and write down the values = of the actual synchronization bandwidth for uplink and downlink. Multiply both with 64/65 =3D 0.984615384615 as VDSL2 uses a continuous = 64/65 encapsulation that will eat roughly 1.6% of the sync bandwidth; = this now are your reference values for what can be sent over that link. = Often 85 to 90%** of that reference bandwidth works well for downlinks, = uplinks can work well up to 100% of the reference. I initially recommend = to set both uplink and downlink to 50% of the reference values and run a = speedtest (e.q. the dslreports of the sourceforge one that both also = measure latency under load, or preferentially flent to a well connected = netperf server) to get a feeling for the best case latency uunder load = increase (at 50% of line rate both a potential ISPs shper as well as the = real pe-packet overhead will not matter under real-world conditions). Next you need to figure out the per-packet overhead, here is my handy = cheat sheet: ###ATM: see RFC2684 http://www.faqs.org/rfcs/rfc2684.html ATM (ADSL2+ PPPoE):=09 2 Byte PPP + 6 Byte PPPoE + 6 destination MAC + 6 source MAC + 2 = ethertype + 3 ATM LLC + 5 ATM SNAP + 2 ATM pad + 8 ATM AAL5 SAR =3D 40 = Byte ATM (ADSL2+ PPPoE VLAN):=20 2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + + 6 destination MAC + = 6 source MAC + 2 ethertype + 3 ATM LLC + 5 ATM SNAP + 2 ATM pad + 8 ATM = AAL5 SAR =3D 44 Byte ###VDSL2 see IEEE 802.3-2012 61.3 relevant for VDSL2: Note VDSL2 = typically transports full ethernet frames including the FCS (shown as = COMON below)=20 VDSL2 (PPPoE VLAN) 2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + 1 Byte Start of Frame = (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), =3D 16 Byte COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 = (src MAC) + 2 (ethertype) =3D 18 byte total: 34 Byte VDSL2 (your case?) 1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte = TC-CRC (PTM-FCS), =3D 4 Byte COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 = (src MAC) + 2 (ethertype) =3D 18 byte total: 22 Byte ### Ethernet FAST-ETHERNET (should also be valid for GB ethernet):=20 7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 = Byte inter frame gap (IFG) =3D 20 Byte COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 = (src MAC) + 2 (ethertype) =3D 18 byte total: 38 Bytes worth of transmission time So a per-packet overhead of 22 seems correct for your case. But the = linux kernel will already add 14 bytes (for the part of the ethernet = header it actually send to the device the MACs and the ethertype) = automatically for most interfaces, so in all likelihood (assuming you = connect via ethernet from your router to the DSL modem) you should = specify 22-14 =3D 8 Bytes per packet overhead for SQM. Now redo the tests from before but first keep the uplink at 50% and = iteratively increase the downlink until you encounter too much latency = under load increase (for your taste); set the uplink to 50% and = iteratively increase the uplink until latency will increase (which might = only happen once you increase above the uplink reference value = calculated above). Finally set both values to the the independently = tested optimal values and test again. Please note that reaching 100% of = reference on egress without bufferbloat showing up is a decent indicator = that you did not underestimate the per-packet overhead. The opposite = unfortunately is not true, as you might simply have run into an ISP = shaper. *) There is still an open discussion how to best deal with the fact that = there is considerable complexity in the different encapsulations schemes = used on ATM and PTM links. I would prefer a table of encapsulation = schemes wit the resulting numerical overheads and cake simply exposing = the explicit numeric =E2=80=9Coverhead NN=E2=80=9D argument. But others = have argued that named symbolic keywords for common variant can be quite = helpful. (My counter argument is that without more explanation neither = alternative is self-explanatory and at least the numeric alternative is = less work to maintain). But please let us know your opinion as a user. **) Downlink shaping is more approximate than uplink shaping as = sufficiently high incoming traffic rates will sort of back-spill also = into your ISPs uplink buffers and that will cause unwanted latency under = load increases that get more unlikely the larger the speed delta between = the true bottleneck and the artificial bottleneck created by SQM = actually is. In essence downlink shaping requires larger margins than = uplink shaping=E2=80=A6 >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake