Wan Packet Overhead For Qos

[Vexira]

How do i calcualte the wan packet ovherhead for a vdsl2 connection llc based or vc based bridge mode, but its ipoe (dhcp) encapsulation not pppoe, just need it for qos.

 

[bbunge]

How do i calcualte the wan packet ovherhead for a vdsl2 connection llc based or vc based bridge mode, but its ipoe (dhcp) encapsulation not pppoe, just need it for qos.

Try the preset for RFC2684/RFC1483 Bridged LLC/Snap 32 with ATM checked. I am using this with the Beta3 of 380.67 on ADSL2 with a LLC bridged modem. I do not use PPPoE.

There is a lot of scholarly work on the web about packet overhead if you want to learn to be a network engineer. Otherwise, experiment to see what works best for you!

 

[RMerlin]

For VDSL2 use the "Bridged/IPoE VDSL" preset. VDSL2 generally does not use ATM.

 

[Vexira]

Thank you both

 

[Vexira]

Try the preset for RFC2684/RFC1483 Bridged LLC/Snap 32 with ATM checked. I am using this with the Beta3 of 380.67 on ADSL2 with a LLC bridged modem. I do not use PPPoE.

There is a lot of scholarly work on the web about packet overhead if you want to learn to be a network engineer. Otherwise, experiment to see what works best for you!

Vdsl2 doesnt use atm, on nbn here, we have amix of pppoe and ipoe for authentication.

 

[Vexira]

For VDSL2 use the "Bridged/IPoE VDSL" preset. VDSL2 generally does not use ATM.

Does that also account for llc or vc-mux encapsulation? would be nice if the presets did account for it just incase it actually matters.

 

[RMerlin]

Does that also account for llc or vc-mux encapsulation? would be nice if the presets did account for it just incase it actually matters.

I don't know. I just took the values documented by Lede.

 

[Vexira]

I don't know. I just took the values documented by Lede.

got it thnx very much

 

[Vexira]

still confused now I just found this it says
https://lists.bufferbloat.net/pipermail/cake/2016-August/002137.html
and this:
https://lede-project.org/docs/howto/sqm#sqmlink_layer_adaptation_tab
ATM (ADSL2+ PPPoE):
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 = 40 Byte
ATM (ADSL2+ PPPoE VLAN):
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 = 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)
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), = 16 Byte
COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 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), = 4 Byte
COMMON: 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
total: 22 Byte

### Ethernet
FAST-ETHERNET (should also be valid for GB 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
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 = 8 Bytes per packet overhead for SQM.

leading me to believe the correct value is 8.

 

[Nigel Jones]

If one uses the actual max speed test results rather than the published line speed, why would one need to build the overhead into the calls? Isn't that double accounting?


Sent from my iPhone using Tapatalk

 

[Vexira]

If one uses the actual max speed test results rather than the published line speed, why would one need to build the overhead into the calls? Isn't that double accounting?


Sent from my iPhone using Tapatalk

its probably to account for over heads that exist, regardless of the speeds. That affect the accuracy of qos.

 

[MagikMark]

Does fiber have overhead too?


Sent from my iPhone using Tapatalk

 

[Vexira]

im not sure if there is, an over head but it there is it would be small, you would have to ask some one whos more experinced than me, such as a network enginner.

 

[Vexira]

aww snap i read it wrong 8 is for sfq, and 22 is standard my bad.

 

[bbunge]

I have tried several settings for wan packet overhead on my slow ADSL2 running through a bridged modem router, PK5001Z. Most values from the preset made speeds slower. Ethernet preset was OK as well as a manual entry of 28. 28 bytes is the header for a MTU of 1500 which I was able to verify with a ping to a remote site of 1472 bytes.
Am beginning to believe that the wan packet overhead does not apply for the most part when the router and modem are separate devices. I am sure there is someone who can prove me wrong and i welcome the discussion! Also feel that there may be a connection between MTU and wan packet overhead in some systems...

Sent from my P01M using Tapatalk

 

[Vexira]

I have tried several settings for wan packet overhead on my slow ADSL2 running through a bridged modem router, PK5001Z. Most values from the preset made speeds slower. Ethernet preset was OK as well as a manual entry of 28. 28 bytes is the header for a MTU of 1500 which I was able to verify with a ping to a remote site of 1472 bytes.
Am beginning to believe that the wan packet overhead does not apply for the most part when the router and modem are separate devices. I am sure there is someone who can prove me wrong and i welcome the discussion! Also feel that there may be a connection between MTU and wan packet overhead in some systems...

Sent from my P01M using Tapatalk

asl2 mtu as far as i know is 1492 in pppoe, 1500 in pppoa but only pppoe works if your bridging, also the over head does apply i check it, well in my case there is a noticeable latency and packet resposinveness diffrence in my case, also is you modem set to bridgemode. I do suspect that the reason you having an issue is because you havent set the correct values for wan packet overhead.
Did you test the bridged llc snap preset?

 

[Nigel Jones]

I'm still not convinced by the use of packet overhead when one sets max up/down to the *observed* max rate.

I DO see how it applies when it is applied to the max documented line speed such as 100 Mbps Ethernet, a VDSL sync speed etc.

I also see how recommendations are often to set the max speed manually to 90-95% of actual ... but that's more to allow for some natural variation, esp on cable etc. Setting an overhead has a similar effect, but the reasoning is different.

I also note the "auto" setting for bandwidth doesn't seem to work on the ASUS sw, but reading around ddwrt it seems as if they have a more sophisticated algorithm which can work within a 1/8-full speed actual throughput situation by measuring bandwidth/pings

All this being said I'm not a QOS expert so add the obligatory pinch of salt ;-)

Oh and very grateful to see some focus in this area, as QOS can be rather useful (and a reminder we need faster router CPUs!!)

 

[Vexira]

I'm still not convinced by the use of packet overhead when one sets max up/down to the *observed* max rate.

I DO see how it applies when it is applied to the max documented line speed such as 100 Mbps Ethernet, a VDSL sync speed etc.

I also see how recommendations are often to set the max speed manually to 90-95% of actual ... but that's more to allow for some natural variation, esp on cable etc. Setting an overhead has a similar effect, but the reasoning is different.

I also note the "auto" setting for bandwidth doesn't seem to work on the ASUS sw, but reading around ddwrt it seems as if they have a more sophisticated algorithm which can work within a 1/8-full speed actual throughput situation by measuring bandwidth/pings

All this being said I'm not a QOS expert so add the obligatory pinch of salt ;-)

Oh and very grateful to see some focus in this area, as QOS can be rather useful (and a reminder we need faster router CPUs!!)

This is what merlin says about it, post 117
"To properly calculate packet delay and performance, the packet scheduler needs to know the exact size of a packet. Modems and ISP equipment adds some overhead to each packet when using protocols such as VDSL2, and transmitting packets over ATM. This allows to adjust the packet size calculation by specifying the overhead that gets added to each packet, providing more accurate traffic performance calculations."
https://www.snbforums.com/threads/alpha-preview-builds-for-asuswrt-merlin-380-60.32978/page-6

Auto bandwidth is for 10gb connections, the 90-95% is to account for congestion which like you said qos should be able to account for, but keep in mind unless the kernel is updated we cant have new features or the full ablity set of cetrain features like FQ_Codel, which is a back port and doesnt include the full potential of the traffic shaper, im no expert either so that makes two of us . Also my orginal post was in regards to the new feture in 380.67, wich adds new qos disiplines to adaptive qos.

 

[Nigel Jones]

Will be doing more reading on the subject. A very interesting area for sure.

 

[Vexira]

Will be doing more reading on the subject. A very interesting area for sure.

awesome, if you do mange to find a definative value for Vdsl2 IPOE(dhcp) anex B or A profile 17a modem briged with a router id apreaciate it very much, been trying to nail the value, tossing up bettwen 19, the value form merlins refrence document, and 22 which is from the calculation.