VDSL2 overheads and CAKE

I have been experimenting with using CAKE and traffic shaping on my Linux router to eliminate bufferbloat on my Internet connection. My local network links are mostly 1 Gbps, including the link between my router and VDSL2 modem. The modem is configured in bridge mode and syncs reliably at an upsteam rate of 19,999 kbps.

In order for CAKE to ensure that the flow of outbound traffic won’t exceed the link rate, it needs to be told what that maximum link rate is and what the per-packet overhead will be due the encapsualtion used on that link.

VDSL2 transports Ethernet frames using Packet Transfer Mode (PTM) with a 64/65 octet encapsulation. This means that every 65th byte is a control byte rather than a payload byte. This overhead can be easily accounted for by reducing the line rate accordingly: 19,999 kbps × 64 ÷ 65 = 19,691 kbps.

Finding clear information on the per-packet overheads was more difficult. The following table shows what I think the overheads are when encapsulating an IP packet over this VDSL link.

PPPProtocol ID22
PPPoEVersion & Type16
Session ID2
EthernetMAC destination622
MAC source6
VLAN tag4
PTMStart of frame (S)14
End of frame (Ck)1
Grand total34

My ISP (AAISP) uses PPPoE which introduces 8 bytes of overhead. Then there are the standard Ethernet headers with the addition of a 4-byte VLAN tag (101) injected by the modem. Finally, there are an additional 4-bytes to transfer the Ethernet frame using PTM.

A total additional overhead of 34 bytes seems to agree with the corresponding keyword options in tc-cake, which gives me some confidence. The pppoe-ptm option equates to 30 bytes overhead and ether-vlan to an additional 4 bytes. I have also used the noatm option to disable compensation for the 64/65 octet encoding, as this has already been accounted for by calculating a reduction in the line rate (bandwidth).

The command to configure CAKE on my wan interface (renamed from eth1) is:

tc qdisc replace root dev wan cake bandwidth 19691kbit pppoe-ptm ether-vlan noatm

It seems to be performing well on DSLReports’ bufferbloat test. Latency increases by less than 5 ms when the upload is fully saturated at 20 Mbps.


Your email address will not be published. I need it to send you a verification link. It will also be sent to Gravatar to check if you have one.


Do you know what the overheads are for Sky superfast broadband? I'm trying to setup SQM on my router but I can't find the correct settings.

Alasdair Smith

I believe that Sky use IP directly over Ethernet (IPoE) and DHCP with option 61 / client ID to assign IP addresses. PPP/PPPoE is not involved so you can exclude those 8 bytes from the table above, which would leave a total of 26 bytes additional per-packet overhead.

That equates to the bridged-ptm plus ether-vlan options in tc-cake. So the command would be something like this instead:

tc qdisc replace root dev wan cake bandwidth 19691kbit bridged-ptm ether-vlan noatm


Hi there

I don't really understand all this stuff but I'm trying. I have BT as my ISP with an FTTC connection. In my Asus router there is an option to select VDSL2 PPPoE PTM for wan packet overhead which I am more than sure should be correct for BT and most ISP in UK anyway.

Does this look ok? https://i.imgur.com/HShXuVQ.png

Thank you

Alasdair Smith

Hi David, both our ISPs use the same underlying BT Wholesale FTTC service and so the overheads should be the same.

The PTM mode in your configuration should account for the 64/65 octet encapsulation. Though it might easier on your router’s CPU to not use this mode and simply reduce your 10 Mb/s upload bandwidth by that fraction to 9.84 Mb/s.

If I’m right about the VLAN tag then your packet overhead should be increased to 34 bytes. It’s probably safer to slightly overestimate than underestimate.


Hi again

Just to confirm you would set something like this? https://i.imgur.com/MmpWmPK.png

I can't find much for MRU for BT. I'm also already being very generous on upload bandwidth allocation at 10. I can usually max out around 11.20 if no shaping is applied.

Alasdair Smith

That looks right to me. I have never configured an MPU value, as I haven’t been able to understand the purpose of it. There seems to be very little information available.


I tried to read the cake documentation again and I do think that 34 is correct. I can't see any reason why it's not. However it got me thinking about FTTP providers. Apparently the FTTP networks (BT anyway) drop the need for vlan tagging so the correct number should go back to 30. Additionally, I found this info about MPU for UK ISP: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#more_hints_tips_info

"Similarly there's a minimum packet size limit, which empirically I'll set to 72 bytes, based on the smallest packets we ever see on the ingress side."

It's unclear if a bridged-ptm connection via Sky will corelate to a 72 MPU for PPPoE. I don't know enough to check.


Sorry to bombard you again but I actually came across this thread: https://forum.openwrt.org/t/sqm-link-layer-adaptation-question-vdsl2/11055

The poster made a good point. I'm not 100% sure but there might actually be 2 vlan tags. The 0 and the 101. Thus the value should actually be 38. I don't know if the 0 actually is a vlan tag but cake documentation does actually state you can use multiple ether-vlan commands if needed so it's not unheard of.

Alasdair Smith

Interesting info about MPU, thanks. I’ll post an update if I work out what this should be. I believe BT FTTC connections use a single VLAN tag (101). You’ll see in the various places that provide BT FTTC configurations for third-party routers that the second VLAN tag (Service VLAN) is not used.

There is also quite a bit of information in SIN 498, the specification for compatibility with BT's VDSL2 services; though it's not exactly light reading.


No problem. I think you're right. Also with so much reading sometimes you miss the easy stuff: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details

"Choose Ethernet with overhead: select for e.g. VDSL2 and set the Per-packet Overhead to 34 if you know you have a VDSL2 connection (this is sometimes called Fiber to the Cabinet, for example in the UK)."

I think I've nearly cracked MPU. Further down that page:

"Similarly there's a minimum packet size limit, which empirically I'll set to 72 bytes, based on the smallest packets we ever see on the ingress side."

So if bridged-ptm is 22 (no vlan tag) and vdsl2 pppoe ptm is 30 (no vlan tag) you should just have to add 8 to the mpu.

Alasdair Smith

I think I’ve figured out MPU. The smallest packet my internet interface has seen in the last 24 hours or so is 28 bytes, as shown below. When CAKE adds the 34 bytes of overhead to that, it thinks it will result in 62 bytes transmitted over the wire and estimates the time that transmission will take accordingly.

# tc -s qdisc show dev aaisp
qdisc cake 8001: root refcnt 2 bandwidth 19691Kbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 30.0ms noatm overhead 34 
 Sent 986258293 bytes 5222192 pkt (dropped 2720, overlimits 2137730 requeues 0) 
 backlog 0b 0p requeues 0
 capacity estimate: 19691Kbit
 min/max network layer size:           28 /    1500
 min/max overhead-adjusted size:       62 /    1534

However, Ethernet has a minimum frame size of 64 bytes. A 28 byte packet + 2 bytes PPP + 6 bytes PPPoE + 22 bytes Ethernet results in only 58 bytes, and so it will actually be padded to create a 64 byte Ethernet frame. Once the remaining 4 bytes of PTM overhead are added for transmission, the minimum size (MPU) must actually be 68 bytes.


Are you sure it's not 72? The 64 doesn't include the vlan tag in the calculation (why it's in brackets): https://i.imgur.com/43A60Ss.png

So really you have to do ptm (4) and vlan tag (4) added to the minimum 64.

I could be wrong though trying to figure out what you account for is getting pretty complex for me now.

Alasdair Smith

This diagram shows what I think is happening.

Image The Ethernet frame is following the 802.1Q standard that includes the VLAN tag in its header. This means the 64‐byte minimum frame size is already inclusive of the VLAN tag.

The physical transmission of the frame is by PTM, so there is no preamble, start frame delimiter or interpacket gap.

Alasdair Smith

Wikipedia's Ethernet Frame page agrees with this interpretation:

Payload is a variable-length field. Its minimum size is governed by a requirement for a minimum frame transmission of 64 octets (bytes). With header and FCS taken into account, the minimum payload is 42 octets when an 802.1Q tag is present and 46 octets when absent. When the actual payload is less than the minimum, padding octets are added accordingly.


That's a good spot. I missed that. 68 seems correct.

You know I started to think about more stuff and going down the rabbit hole so to speak. I'm just thinking out loud here but:

1: I wonder what happens with FTTP/FTTH services in UK. I have read that they don't use vlan tags but I think it's people incorrectly assuming that since the ONT does the tagging automatically, you don't need to. Would you still account for this as normal?

The wiki states for FTTH you should set wan packet overhead to 44 and an mpu of 88: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#more_hints_tips_info

It's ofcourse a general rule they say but unless I'm mistaken there should be no reason for the values to change. Ofcourse it is still ptm so there should be no reason to involve layer 1 values (maybe this is why the wiki states these as not many fttp providers will use ptm to stick within layer 2).... I think that's how it works.

2: I doubt AAISP will change for awhile but I can maybe see BT and slightly large ISP like Talk Talk maybe moving to CGNAT in some years. Now I am not sure but maybe it's worth looking into the numbers if a change to ipv6 is required to steer clear of that. ipv6 ethernet frame:


Minimum frame size of 84 (I assume also padded) so 88 mpu due to ptm... as a first guess ofcourse.

Add your own comment?