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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6BCF021F1F7 for ; Mon, 18 May 2015 00:27:05 -0700 (PDT) Received: from hms-beagle-6.lan ([134.2.89.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lqn7e-1ZPRbg0mv4-00eIon; Mon, 18 May 2015 09:27:02 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 18 May 2015 09:27:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B7986E7-49A1-4EE1-B8D0-B55A6C2660A1@gmx.de> References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:Uscx7ZvyWOQT/X3hys9goWHXVKO+4lCtQqVizBg9M5XHpuB0Jxy X1Q60oSaX7DshQFIFPF9pIEtbeZix9Vw26wwlRxP4bHwr6JdtnOH4ybukIX9vDEIKzeya7r Lf8I1jq1J87zipC0x2fdV/V93wMrrJyHFfzixsYDfmE+7zOm6Sn0Vfxf+JFw16K9cT2E5nJ r+ce8Sdx1mjOZ6UPCqdzg== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More overhead keywords X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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, 18 May 2015 07:27:35 -0000 Hi Jonathan, On May 18, 2015, at 02:49 , Jonathan Morton = wrote: > This is entirely userspace (ie. iproute2) stuff: >=20 > The initial cake-overhead patch included only =93raw=94 and = =93conservative=94 shortcut keywords, alongside the numeric =93overhead=94= parameter for experts. I=92ve now worked out an extended set of = keywords which, I think, takes care of all the normal cases. Great! >=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) >=20 > Note that =93pppoa-llc=94 is not a typo - it really doesn=92t involve = SNAP, and is thus a little more compact than if it did. I am probably odd in my preferences, but to be able one needs to = read a certain number of technical documents to figure out which = encapsulation is used; these keywords woui;d make more sense sort of if = they were something along the lines of: =93BT_ADSL=94, so that the user = would just need to know what she signed up for. Then again no ISP I know = guarantees any stability in the encapsulation or actually discloses what = is in use... >=20 > Two more new keywords deal with the basic VDSL2 configurations. = Again, the overheads use IP as a baseline, but this time ATM = cell-framing is turned off. Apparently PTM does have a small additional = overhead on the order of 1/128, due to HDLC framing which attaches = special meaning to 0x7D and 0x7E bytes; I might need to add approximate = handling for that, kernel-side. HDLC is only used for VDSL1 not for the relevant data bearer = channels in VDSL2 (VDSL1 and VDSL2 are not as closely related as ADSL1 = and ADSL2 are). The issue with HDLC, in my eyes is that 1/128 is just a = stochastic approximation since it is payload dependent, think a packet = with just 0x7D as payload which will I believe roughly double in wire = size. So really one would need to read through the packet first (which = would be what =93deepest packet inspection=94?), count the forbidden = octets and adjust the skb->pkt_len (or cake=92s overhead) for the real = wire size, but that will not really work on puny routers that are = already struggling with NAT/routing/firewalling/traffic-shaping. As far = as I know VDSL1 is still in use, allegedly in South Korea, but in Europe = VDSL2 seems to be more dominant, no idea about the U.S.. For what it is worth here are my notes about the VDSL2 overhead: VDSL2 header: Deutsche Telekom Overhead: 2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN =3D = 10 Byte VDSL (IEEE 802.3-2012 61.3 relevant for VDSL2): 1 Byte Start of Frame = (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), =3D 4 Byte #FAST-ETHERNET: 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 (By now I think that the ethernet FCS is = not transmitter over the VDSL segment, but recalculated at the other = end, as was usual with ADSL) maxMTU: 1500 postMTU header: 8 (PPP/PPPoE) =3D 1492 preMTU header: VDSL2: 1 (S) + 1 (Ck) + 2 (PTM-FCS) =3D 4 ethernet 18 (common) + 4 (VLAN) =3D 22 (with FCS) 14 (common) + 4 (VLAN) =3D 18 payload: maxMTU - postMTU_header =3D 1500 - 8 =3D 1492 fullFrameSize maxMTU + preMTU_header =3D 1500 + 4 + 22 =3D 1526 maxMTU + preMTU_header =3D 1500 + 4 + 18 =3D 1522 And then there is the PTM framing (one octet in 65, the sync octet, does = not carry user data and hence is overhead): PTM 64/65=20 framing factor: 64/65 =3D 0.984615384615 I am not sure whether this is already excluded from the sync rates = reported to the user, but since this is independent of data/packet size = and we always need to set the shaper lower than 100% anyways these 1.5% = might be irrelevant. I hope this is somewhat clear. >=20 > pppoe-ptm (27) > bridged-ptm (19) >=20 > The final three keywords are not for standalone use, but act as = modifiers to some previous keyword. They can be specified more than = once, which is probably only useful for =93ether-vlan=94. >=20 > via-ethernet (-14) > ether-fcs (+4) > ether-vlan (+4) I like this idea, but it might be a bit surprising that these = behave differently from the others, maybe prefix them with "mod_" or so? = Also if we really want to hold the users hand, only ether-vlan = reasonably can appear more than once, so maybe just add a keyword = 2nd-ether-vlan and disallow multiple instances of the same key-word?=20 >=20 > Does all this look reasonable? In particular, have I missed anything = regarding PTM/VDSL2? I=92m using = http://www.ethernetinthefirstmile.com/articles/WTC2002.pdf as a = reference, but it isn=92t as clear as it might be. I think that IEEE 802.3-2012 61.3 is more explicit and authoritative. = But clear as in nice to read and understand this is not=85 ;) Maybe = T-REC-G.993.2-201112-I!!PDF-E can also be of help... Best Regards Sebastian >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake