Re: [Cake] More overhead keywords

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan,

On May 18, 2015, at 02:49 , Jonathan Morton <chromatix99@gmail.com> wrote:

> This is entirely userspace (ie. iproute2) stuff:
> 
> The initial cake-overhead patch included only “raw” and “conservative” shortcut keywords, alongside the numeric “overhead” parameter for experts.  I’ve now worked out an extended set of keywords which, I think, takes care of all the normal cases.

	Great!

> 
> 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.
> 
> ipoa-vcmux (8)
> ipoa-llcsnap (16)
> bridged-vcmux (24)
> bridged-llcsnap (32)
> pppoa-vcmux (10)
> pppoa-llc (14)
> pppoe-vcmux (32)
> pppoe-llcsnap (40)
> 
> Note that “pppoa-llc” is not a typo - it really doesn’t 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: “BT_ADSL”, 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...

> 
> 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 “deepest packet inspection”?), count the forbidden octets and adjust the skb->pkt_len (or cake’s 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 = 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), = 4 Byte
#FAST-ETHERNET: 7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 Byte inter #frame gap (IFG) = 20 Byte
COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 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) = 1492
preMTU header:
VDSL2:
1 (S) + 1 (Ck) + 2 (PTM-FCS) = 4
ethernet
18 (common) + 4 (VLAN) = 22 (with FCS)
14 (common) + 4 (VLAN) = 18

payload:
maxMTU - postMTU_header = 1500 - 8 = 1492

fullFrameSize
maxMTU + preMTU_header = 1500 + 4 + 22 = 1526
maxMTU + preMTU_header = 1500 + 4 + 18 = 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 
framing factor: 64/65 = 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.

> 
> pppoe-ptm (27)
> bridged-ptm (19)
> 
> 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 “ether-vlan”.
> 
> 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? 

> 
> Does all this look reasonable?  In particular, have I missed anything regarding PTM/VDSL2?  I’m using http://www.ethernetinthefirstmile.com/articles/WTC2002.pdf as a reference, but it isn’t 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… ;) Maybe T-REC-G.993.2-201112-I!!PDF-E can also be of help...


Best Regards
	Sebastian

> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake