Wan Packet Overhead For Qos

[Vexira]

this might clarify some things
https://lists.bufferbloat.net/pipermail/cake/2016-October/002234.html
https://lists.bufferbloat.net/pipermail/cake/2016-October/002233.html

 

[FreshJR]

I've said this once, and I'll say it again but a little more concisely this time.

I do not think setting WAN overhead is critical for most users.

Eg. You have two 100mbps connections both saturating the entire link transfering 100% full sized 1460 byte payload packets.
a) Connection A has NO overhead
b) Connection B has a 20byte overhead

Let's say I limit connection A to 95 mbps to get perfect network performance.

To get equivalent performance on connection B the following two configurations would be equivalent given the above scenario.

1) Limit connection B to 95 mbps + 20 byte WAN overhead ==> result will be 93.75mbps data throughput
2) Limit connection B to 93.75 mbps + no WAN overhead ==> result will be 93.75 mbps data throughput

--

Since typically users determine the 93.75 or 95 mbps number by trail and error, they account for WAN overhead during initial configuration.

I do have to warn, since it isn't obvious, setups (1) & (2) are only equivalent in when dealing will packets that are all fully packed with 1460 bytes.
If dealing with smaller packets, the limit in connection (2) would have be be reduced a little more than 93.75.

If you log your network and look at the proportion of small packets to big packets, you will see that the quantity of small packets is insignificant **for most users useage, this can vary**

As such the user in situation (2) should be able to get away with choosing 93mbps as his rate and simply forgore the additional 0.75mbps possible. That is why the 85-95% recommendation when setting up QOS is listed as a starting point.

--

Even if you ISP does have a large overhead due to encapsulating the signal, how can you be sure they are throttling your speeds with this WAN overhead they incur included?
Many ISP's throttle at the modem instead of the supply node.

Fine tuning your network to be razor accurate is great and all, but the necessary speedtest tools are not available.

 

[Vexira]

I've said this once, and I'll say it again but a little more concisely this.

I do not think setting WAN overhead is critical for most users.

Eg. You have two 100mbps connections both saturating the entire link transfering 100% full sized 1460 byte payload packets.
a) Connection A has NO overhead
b) Connection B has a 20byte overhead

Let's say I limit connection A to 95 mbps to get perfect network performance.

To get equivalent performance on connection B the following two scenarios would be equivalent for the above scenario.

1) Limit connection B to 95 mbps + 20 byte WAN overhead
2) Limit connection B to 93.75 mbps + no WAN overhead

--

Since typically users determine the 93.75 or 95 mbps number by trail and error, they partially account for WAN overhead in the initial configuration.

Setups (1) & (2) are only equivalent in when dealing will packets that are full packed with 1460 byte.
If dealing with smaller packets, the number would connection (2) would have be be reduced a little more than 93.75.

If you log your network and look at the proportion of small packets to big packets, you will see that the quantity of small packets is insignificant.

As such the user in situation (2) should be able to get away with choosing 93mbps as his rate and simply forgore the additional 0.75mbps possible. That is why the 85-95% recommendation when setting up QOS is listed as a starting point.

--

Even if you ISP does have overhead due to encapsulating the signal how can you be sure they are throttling your speeds with their WAN overhead included.
Many ISP's throttle at the modem instead of the supply node.

Fine tuning your network to be razor accurate is great and all, but the necessary speedtest tools are not available.

I just thought it was an interesting read for anyone that wants it. But you have a valid point.
Sorry for being a pain.

 

[FreshJR]

I just thought it was an interesting read for anyone that wants it. But you have a valid point.
Sorry for being a pain.

No, it really is a great topic to really understand what is going on the data line and then being able to fine tune the perfect setup to match (effectively deal with) your ISP's bandwidth limiter.

But as it stands, without a speedtest that sends two different sized packets we still have a lack of a way of determining if users are being throttled on the overhead and the shear quantity of it.

There is no problem in using the suggested value from RMerlin's presets, I never said that was BAD, but as it stands either

1) You will be over-estimating the effect of small packets on your network
or
2) You will be under-estimating the effect of small packets on your network

by setting or foregoing that setting. The setting is basically a guess with a 50/50% shot depending on your ISP.

Either way the effect shouldn't be significant for most residential users as it will get "washed away" while tuning within the 85-95% sustained bandwidth setting.

--

WAN overhead is a big deal for ISP's as avoid the case of get screwed with bloat on the encapsulated link during the potential scenario where many (or higher than statistically accounted for) small packets are transversing their network.

I haven't found this to be the case, often, for a residential network.

 

[Vexira]

Would this method work, they seem to have a way of discovering the overhead, I'm just qurious that's all.

https://forum.lede-project.org/t/sqm-link-layer-adaptation-question-vdsl2/11055

 

[FreshJR]

Would this method work, they seem to have a way of discovering the overhead, I'm just qurious that's all.

https://forum.lede-project.org/t/sqm-link-layer-adaptation-question-vdsl2/11055

I saw no method of determining WAN overhead in that post. The user said he simply had a 26byte overhead.

Vexira, what I think you are doing is the following:

1) Input bandwidth number as-is from speedtest
2) The script lowers QOS ceiling to 95% of your WebUI input via the two lines you requested
3) If you have still have bufferbloat you find yourself setting / raising WAN overhead. What this does is that it further reduces the ceiling from your 95% setting, but it does so in a round about way.

It's not really WAN overhead that is making a difference, but rather that you limits are becoming lower than 95% due to how the setting affects your bandwidth ceiling.
--

There is no way to determine WAN overhead without a multi sized packet speedtest. This overhead is completely stripped and not seen at the router level.

 

[Vexira]

I saw no method of determining WAN overhead in that post. The user said he simply had a 26byte overhead.

Vexira, what I think you are doing is the following:

1) Input bandwidth number as-is from speedtest
2) The script lowers QOS ceiling to 95% of your WebUI input via the two lines you requested
3) If you have still have bufferbloat you find yourself setting / raising WAN overhead. What this does is that it further reduces the ceiling from your 95% setting, but it does so in a round about way.

It's not really WAN overhead that is making a difference, but rather that you limits are becoming lower than 95% due to how the setting affects your bandwidth ceiling.
--

There is no way to determine WAN overhead without a multi sized packet speedtest. This overhead is completely stripped and not seen at the router level.

While running on fq_codel/simple, output of tc -s qdisc: https://pastebin.com/V95F4U70 15
Also while running on fq_codel/simple ouput of tc -d qdisc: https://pastebin.com/TYyNQ5Su 7


From your pastebin:

maxpacket 1514 (eth0)

this indicates that your kernel adds 14 bytes so only request “overhead 12”.

maxpacket 7370 (ifb4eth0)


I was looking at that section of the posts, I'm just curious that's all, considering that, my connection has a 1500 mtu which I assume is the Max packet size, if I understand correctly and extra data is over head as in any data above the mtu

 

[FreshJR]

The overhead is stripped at the modem. You cannot see it. If you could, a speedtest would not be necessary.

In your linked forum post it was recommended for that ser to use an overhead of

12 since 14 was already added by his routers kernel.

12 + 14 = 26

 

[Vexira]

The overhead is stripped at the modem. You cannot see it. If you could, a speedtest would not be necessary.

In your linked forum post it was recommended for that ser to use an overhead of

12 since 14 was already added by his routers kernel.

12 + 14 = 26

after he ran a qdisc, im just qurious that's all about testing on my own net work.

 

[FreshJR]

after he ran a qdisc, im just qurious that's all about testing on my own net work.

No he checked the stats of his queuing disciplines and found the it was pushing packets with the size of 1514 instead of the expected 1500.

This means that the router is adding its own intermediate 14byte overhead that is accounted for when calculating rates.

This means he just had to tell to router to account for an additional 12bytes to fall inline with his ISP’s throttling scheme that has an overhead of 26bytes per packet.

If he input 26 into WAN overhead, he would be overshooting overhead by 14 bytes.