Optimal LTE 4G MTU / WAN Packet Overhead

Mindful of, e.g.:

Quote:Over the Iu-ps interface 1400 byte will avoid fragmentation. This is a conservative value to accommodate the protocol layer header overheads. The possible overheads over the Iu-ps interface (GTP/UDP/lower-IP) are the following: GTP main header = 12 bytes GTP extension header = 4 bytes UDP header = 8 bytes IPv4 header = 20 bytes (without optional IPv4 fields), or IPv6 header = 40 bytes (without optional IPv6 headers). The maximum headers size is then 12+4+8+40=64 bytes. The MTU for IPv4 and IPv6 is 1500 bytes. So, the maximum SDU size would be 1500-64=1436 bytes. 1400 bytes is a safer value.

Click to expand...

https://www.etsi.org/deliver/etsi_tr/126...80000p.pdf

This makes me wonder: what is the optimal MTU set for a 4G LTE connection, to maximise throughput and avoid fragmentation? Should this value be the same in OpenVPN?

I have been experimenting with QoS-CAKE, in which ideally the 'WAN packet overhead' is ascertained.

Since I use a VPN, by using 'tcpdump -vpni' on 'eth0' vs 'tun11' interfaces, I have determined that the OpenVPN encapsulation adds 53 bytes to each packet.

But I need to enter the overhead associated with 4G LTE transmission. That is a harder number to determine.

Any idea of the 'WAN packet overhead' for use with 4G LTE? I mean, what is the WAN packet overhead in bytes associated with the 4G LTE encapsulation around the payload? Is it fixed?

Here on 4g;

ping -f 8.8.8.8 -l 1500
Pinging 8.8.8.8 with 1500 bytes of data:
Packet needs to be fragmented but DF set.

ping -f 8.8.8.8 -l 1428
Pinging 8.8.8.8 with 1428 bytes of data:
Packet needs to be fragmented but DF set.

ping -f 8.8.8.8 -l 1420
Pinging 8.8.8.8 with 1420 bytes of data:

With my favorite ping sites via DNS I have to use 1300.

Does this technique still allow for 4G LTE overhead? Could it be that given 4G LTE overhead the packet is still fragmented and then reassembled during transmission? So the ping report reports no fragmentation but this is just because of reassembly?

Do we know how many bytes of overhead 4G LTE adds to each payload (whatever that maximum can truly be)?

Not at a low level such as 1300, the 4g overhead varies depending how traffic flows (which can alternate alot in a short time), as it varies the best value is lower then the optimum 4g (or 5g) may have at any given time.

hi, lynx, old post, but i experimented, i am copy pasting, i hope it helps, i have cpe 155-381 and only set to 4gLTE and 5G gives very poor speed on the CPE, i have it bridged to asus ax58u and using default merlin cake (for now).


Microsoft Windows [Version 10.0.26100.3775]
(c) Microsoft Corporation. All rights reserved.

C:\Users\safwa>ping -f -l 1472 8.8.8.8

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=1472 time=151ms TTL=108
Reply from 8.8.8.8: bytes=1472 time=190ms TTL=108
Reply from 8.8.8.8: bytes=1472 time=179ms TTL=108
Reply from 8.8.8.8: bytes=1472 time=83ms TTL=108

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 190ms, Average = 150ms

C:\Users\safwa>ping -f -l 1500 8.8.8.8

Pinging 8.8.8.8 with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\safwa>ping -f -l 1499 8.8.8.8

Pinging 8.8.8.8 with 1499 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\safwa>ping -f -l 1479 8.8.8.8

Pinging 8.8.8.8 with 1479 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\safwa>ping -f -l 1475 8.8.8.8

Pinging 8.8.8.8 with 1475 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\safwa>ping -f -l 1472 8.8.8.8

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=1472 time=192ms TTL=108
Reply from 8.8.8.8: bytes=1472 time=109ms TTL=108
Reply from 8.8.8.8: bytes=1472 time=120ms TTL=108
Reply from 8.8.8.8: bytes=1472 time=93ms TTL=108

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 93ms, Maximum = 192ms, Average = 128ms

C:\Users\safwa>ping -f -l 1272 8.8.8.8

Pinging 8.8.8.8 with 1272 bytes of data:
Reply from 8.8.8.8: bytes=1272 time=82ms TTL=108
Reply from 8.8.8.8: bytes=1272 time=112ms TTL=108
Reply from 8.8.8.8: bytes=1272 time=275ms TTL=108
Reply from 8.8.8.8: bytes=1272 time=194ms TTL=108

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 82ms, Maximum = 275ms, Average = 165ms

C:\Users\safwa>ping -f -l 12 8.8.8.8

Pinging 8.8.8.8 with 12 bytes of data:
Reply from 8.8.8.8: bytes=12 time=52ms TTL=108
Reply from 8.8.8.8: bytes=12 time=83ms TTL=108
Reply from 8.8.8.8: bytes=12 time=74ms TTL=108
Reply from 8.8.8.8: bytes=12 time=110ms TTL=108

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 52ms, Maximum = 110ms, Average = 79ms

C:\Users\safwa>ping -f -l 1473 8.8.8.8

Pinging 8.8.8.8 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\safwa>

Thanks. Since bandwidth varies so much with my own 4G connection, the only way to render cake effective is to keep adjusting the cake bandwidth (hence cake-autorate). This way I can keep latency in check without worrying about sacrificing too much bandwidth at any given moment. The effect of adjusting the packet overhead is comparatively very minor.

Lynx said:

Thanks. Since bandwidth varies so much with my own 4G connection, the only way to render cake effective is to keep adjusting the cake bandwidth (hence cake-autorate). This way I can keep latency in check without worrying about sacrificing too much bandwidth at any given moment. The effect of adjusting the packet overhead is comparatively very minor.

Click to expand...

1388 and 694 give me the best results.