4

Is it reasonable to set higher MTU size between RAN (3g, LTE) and RNC/SGW? Say, we have S1-U interface with GTP encapsulation, which leads to reduced data size for mobile user. Data size can be adjusted by SGW itself for TCP (MSS manipulation), but there's possibility to increase MTU from default 1500 value to, say, 1600, so that user can use bigger segment size for TCP, and other L4 protocols will not be fragmented at any level. Will this really help to improve performance and user experience or would there be some unaccounted factors that make the whole plan pointless?

Thanks.

Improve this question

4 Answers 4

Reset to default
5

I think it's always best to allow end-user traffic to use an MTU of 1500. Therefore when encapsulated the overlay network has to cater for this either by a larger MTU size in the encapsulated domain or by fragmentation/reassembly techniques. Since fragmentation is computationally expensive when performed in software, I believe that a service provider should define and use an MTU in the domain of the encapsulated traffic sufficient to allow 1500 at the user level and avoid any fragmenation, as you say 1600 for instance.

This won't significantly improve TCP performance in the steady-state, but it will avoid complications.

As a service provider you should be in a position to define the MTU of your network to the customer, and if you define it at 1500 nobody can complain, and you will reduce potential problems where for instance PMTUD doesn't work well for any reason or is slow to adjust or settles for TCP minimum.

The downside is that you will need to ensure that every Ethernet port along the way has an appropriate MTU defined. Some equipment may default to dropping jumbos (or mini-jumbos if you prefer). If you fail to do this then traffic may be black-holed somewhere along the route.

The worst case is of course when the service provider just leaves everything default and doesn't really actually have a defined MTU with the service offering.

I would caveat all this by saying I haven't ever worked on the radio network, so I don't know if there's any frame or cell structure there that would lead you towards a different end-user MTU for bandwidth efficiency.

Improve this answer
4

I've done some tests with different MTU values. All tests were performed for mobile data, no voice affected or tested.

Results are as follows:

  1. Increased MTU in LTE network allows for more efficient exchange between eNodeB and EPC, e.g. MTU value of 1600 in S1-U is sufficient for transmitting 1500 bytes of user data, and mobile network overhead (GTP + UDP + new IP header) without fragmentation.
  2. Increased MTU in 2g/3g network brings none or almost none profit. Underlying protocols sitting between base station and packet core, and mobile device and base station still cause small packets to be transmitted. Eventually almost nothing grows up to MTU size. This is caused by scheduling mechanisms of base station.

One more notice: packets with DF (don't fragment) bit can be successfully fragmented on underlying level and reassembled at packet core with DF bit preserved. E.g. pinging some host with DF bit set and ICMP payload of 1472 is possible, but packets between base station and mobile packet core are still small.

Improve this answer
2

It's a reasonable thing to do, technically, but I don't believe it will help improve the users' experience, which is really the only thing that matters in mobile networks. And so, why bother?

Consider that voice (rtp) is packetized into tiny lumps, 20 ms being typical. That translates into a lot of small packets, rather than a few large ones, that might benefit from the larger MTU. SIP, the signaling protocol, might do, because in IMS networks the messages are quite large, but that doesn't really contribute to the users perception of their experience.

Data flows are the other case, eg video or email, but again, the video is is short packets and the email (which is typically really https) is not time and latency sensitive in a way that messing with the MTU would help.

Improve this answer
1
  • Well, there is point in your answer. I am not really trying to increase packet size for CS core network (voice). And for PS core network packet size depends on RAN. It seems increasing MTU is useless for 3G, but is useful in case of LTE. I will post separate answer after I'll be confident of reasons if you're intrested. P. S. in many cases video is also https nowadays.
    – ar_
    Commented May 26, 2017 at 10:04
0

IP MTU is 1536 for IP/GTP packets.

encapsulated IP packet 1500 bytes + GTP header 8 bytes + UDP header 8 bytes + outer IP header 20 bytes = 1536 bytes

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.