Reduce MTU over an Ethernet Link

[iantra123]

Hi,

Is it possible to reduce MTU over an Ethernet link?

Best regards,

Antra

[andrew.prince]

What hardware is in use?

Why do you need to reduce the MTU?

[iantra123]

I'm using a cisco 1841.

I need to reduce MTU for testing Voice lattency.

MTU 1500 take more time over WAN, for voice.

From my Office to Operator, there is a Bridge Alvarion.

The Fast0/1 is connected directly to the IDU.

[andrew.prince]

Eh?

That makes no sense - are you saying that you are having issues with Voice over your WAN circuit? If so - lowering the MTU will not fix the issue, you need to prioritise your Voice over the WAN circuit = QoS.

HTH>

[iantra123]

I've already done this, but the problem persist.

The upstream voice is OK, but the downstream present robotised voice.

[andrew.prince]

OK - downstream is the remote end to you, you cannot prioritise voice that you do not control.

QoS needs to be applied on both ends.

HTH>

[iantra123]

That's right.

So I'll use a VPN.

[andrew.prince]

Using a VPN wcould possibly not fix the issue.

The problam could still exist - anf you may add to the issue by introducing extra latency of the enryption/decryption of the voice in the VPN.

[iantra123]

The problem with VoIP, is that even when using the best of the best QOS sheduler (Pfsense HFSC is one of them), you still need to wait for a 1500 bytes frame of tcp, (http or ftp for example) go out of the WAN interface, before to be able to effectively transmitt a VoIP frame.

1500 bytes is a non negligeable amount of transmission time on a slow WAN link.

As an example, a 256 000 bps link gives approximately 47 ms to transmitt a 1500 bytes frame :

500 000 / 8 = 32 000 Bps

1500 / 32 000 = 47 ms

Even the best QOS sheduler can't do more than waiting for the Data TCP frame to go out of the WAN interface, before to transmitt a VoIP frame.

The best he can do, is to try to minimize the amount of time needed between VoIP frame transfer, like this :

The long lines is Data TCP traffic, the short one VoIP udp traffic.

The solution is to reduce the Data MTU, or fragmenting the Data trafic when there is VoIP trafic

[andrew.prince]

I disagree more - this is why there are tools like PQ,CBWFQ,LLQ,Policing/Shaping and LFI

The name of the game is Congestion Avoidance, if the WAN is 1 hop away from your equipment, you need to do a much as possible to mitigate the bottle neck of your WAN provider.

But at the end of the day it's your network.

[Joseph W. Doherty]

You're correct when bandwidth is generally under 768 Kbps. Then serialization delay for 1500 byte sized packets can overrun the time budget for VoIP. However, you did note Ethernet?

PS:

BTW, some Cisco platforms support a method to "spoof" TCP MSS. This too will reduce TCP packet sizes, in a manner "nicer" than changing the MTU. However, non-TCP traffic packets sizes won't be changed.

Also it's possible to change Ethernet's MTU, but at typical Ethernet bandwidths, VoIP quality issues often more due to transient congestions that is managed by QoS.

One typical problem, WANs with Ethernet handoffs. No or minimal congestion at the handoff, but the WAN doesn't actually provide Ethernet bandwidth. For these, you need to shape down to the actual available bandwidth, and manage that bandwidth with QoS. If the effective bandwidth is also below about 768 Kbps, 1500 byte sized packet serialization delay can be an issue.

[andrew.prince]

Ahh Joseph - thanks for point out the "Ethernet" part, I must appologise and admit I missed that!

TCP-MSS adjust is a great tool, but as you say not all platforms support changing the TCP negotiated MSS value on transient packets - 99% of routers do support this. 65xx 3750 Metros do not.

QoS - in the form of policing or indeed shaping to the actual circuit speed that is 1/2 hops away would be the way forward.

[Joseph W. Doherty]

Could you further describe your topology end-to-end? If you're able to perform VPN on both sides, it may be possible to also provide QoS on both sides. Even if you don't manage the actual WAN handoff devices, depending on your topology, it might be possible to manage your traffic with QoS before it reaches devices not under your management control.

PS:

BTW, adjusting MTU smaller could be helpful for VoIP in the situation where there's little bandwidth and no direct support for LFI, but more likely you just need to insure VoIP is prioritized.

[iantra123]

The topology is lik this :

Cisco{f0/1} - ISP - SIPProvider

The second toplogy is

Asterisk - Cisco{f0/1} - ISP - SIPProvider.

The quality is the same.

[Joseph W. Doherty]

Your test results show a low bandwidth capacity. So, would still need to understand what your topology is, i.e. devices, links, nomimal bandwidths, etc.