Optimal LTE 4G MTU / WAN Packet Overhead

[Lynx]

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.

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?

 

[itpp20]

https://customer.cradlepoint.com/s/article/MTU-MSS-Design-Considerations

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.

 

[Lynx]

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)?

 

[itpp20]

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.

 

[Bluesky]

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 I'm using the USS B Dongle overhead? It seems to be different in uploadi

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)?

I'm using the USS B Dongle overhead? It seems to be different in uploading and downloading sometimes MTU