[Cake] pppoe-ptm overhead calculation question

[Cake] pppoe-ptm overhead calculation question

[Sebastian Moeller]

Hi Jonathan,


I just stumbled over the following snippet in tc/q_cake.c (https://github.com/dtaht/tc-adv/commit/853558f94968fe849ddd51e0ca395688aff1d940):


+		/* Typical VDSL2 framing schemes */
+		/* NB: PTM includes HDLC's 0x7D/7E expansion, adds extra 1/128 */
+		} else if (strcmp(*argv, "pppoe-ptm") == 0) {
+			atm = 0;
+			overhead = 27;
+		} else if (strcmp(*argv, "bridged-ptm") == 0) {
+			atm = 0;
+			overhead = 19;

Now the comment might be irrelevant, but I believe it to be actually not quite roght; VDSL2 does not (typically) use HDLC on the bearers used for data paths, but those are the ones we care about when thinking about per packet overhead and on-the-wire-bandwidth.
	According to Rec. ITU-T G.993.2 (12/2011) HDLC is used on the 	ManagementTPS-TC(MPS-TC) (see section 8.2); but neither the user data TPS-TC section (8.1) nor the referenced annex L.3 mention HDLC encapsulation at all. 
	They do however reference Rec. ITU-T G.992.3 (04/2009) Annex N, which in turn describes the 64/65 encapsulation scheme used in VDSL2. 
	So VDSL2 in contrast to VDSL1 uses 64/65 encapsulation and no HDLC expansion is required. Which is great as for HDLC the 1/128 is just stochastic approximation that can be gamed by manipulating packet payload to consist only out of to-be-expanded-bytes. The 64/65 encapsulation of VDLS2, IMHO, is best dealt with as a generic rate reduction of 100-100*64/65 = 1.54%, but I digress.

I also believe the correct overhead for pppoe-ptm over vdsl2 to be:
VDSL2 (IEEE 802.3-2012 61.3 relevant fuer VDSL2): 2 Byte PPP + 6 Byte PPPoE + 1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), = 12 Byte

With a high probability that on-the-wire an ethernet header including frame-check-sequence (4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ether type) + 18 bytes) needs to be added (and depending on ISP potentially several VLAN tags); I realize that cake handles all of those as discrete entities that need to be specified in their own right

I really do not see how you get to 27 for pppoe-ptm, so most likely I am overlooking something, so I would be delighted if you could explain what I am missing. Thanks in advance...





Best Regards
	Sebastian

Re: [Cake] pppoe-ptm overhead calculation question

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

I'm getting the distinct impression that VDSL1 & VDSL2 are completely
different technologies with the misfortune of sharing an acronym and
physical medium.  It's certainly far too easy to confuse data about one for
the other.

Ideally, I'd like to see measurements on a real line to corroborate one way
or the other.  However, the use of a fixed-size word frame does sound much
more elegant than HDLC.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 498 bytes --]

Re: [Cake] pppoe-ptm overhead calculation question

[Sebastian Moeller]

Hi Jonathan,


On Sep 3, 2015, at 20:02 , Jonathan Morton <chromatix99@gmail.com> wrote:

> I'm getting the distinct impression that VDSL1 & VDSL2 are completely different technologies with the misfortune of sharing an acronym and physical medium.

	That is a decent way of putting it. VDSL2 has the advantage of coming late to the party and avoiding some of the then obvious warts of VDSL1; also VDSL1 ist not compatible with ADSL-lines in the same DSLAM and hence probably on the define world wide. There are some deployments in Asia and parts of the rest of the world (according to wikipedia) VDSL2 seems to have struck mor resonance with telco ISPs and hence seems more prevalent..


>  It's certainly far too easy to confuse data about one for the other.

	It certainly is, it does not help that ITU documents are decidedly not fun to read...

> 
> Ideally, I'd like to see measurements on a real line to corroborate one way or the other.  

	The good thing is that I outlined the approach to measure this: create a traffic shaper close to line-rate, saturate the shaper with to-be-expanded-bytes packets and measure latency under load. For VDSL2 all should be well (or as well as with not-to-be-expanded bytes as payloads), for HDLC latency should rise quickly and badly (my first approximation would be that the on-the-wire-size doubles, so the shaper is toast by then).


> However, the use of a fixed-size word frame does sound much more elegant than HDLC.

	64/65 encoding is not too bad actually 1.5% overhead independent of the number of packets is decent…

Best Regards
	Sebastian

> 
> - Jonathan Morton