Tip

Probing to maximize MTU efficiency and deliver QoS

Reading Rich Parson's excellent tip "Link Efficiency within QoS" (July 8, 2004) got me thinking about some of the potential remaining benefits of private

    Requires Free Membership to View

circuits and issues involved in making QoS decisions. Managing latency is definitely the real bugaboo of managing voice traffic on public Internets because of the variability of bandwidths available and issues inherent to packet switched networks, where packets don't always follow the same routes (and hence, can experience vastly different path-dependent latencies).

It's simple mathematics that increasing the Maximum Transmission Unit (MTU) for IP packets improves the header-to-payload ratio, and therefore permits better utilization of network links at any speed. But when bandwidth increases, raising MTUs from typical Ethernet MTUs of 1576 bytes to something on the order of 9000 bytes can provide remarkable increases in throughput (for example, see the calculations in Australia's Academic and Research Network (aarnet) "Why do we want to increase the MTU size?" where the difference between their min and max cases is an astonishing (and unattainable) three orders of magnitude. Research indicates that as long as links can handle larger MTUs without adding to delays (on slower links, larger MTUs can actually increase latency, for various reasons), such increases in transfer unit size can significantly help to reduce latency and provide better expectations of meeting or exceeding QoS requirements.

The problems involved in using large MTUs can be largely bypassed if they're restricted to IP-only subnets or links (so that Ethertype headers, which support large MTUs, rather than SNAP or 802.2 headers, will be the only traffic on such links). This puts practical sizes in the range of up to 11,000-plus bytes, which makes the 9,000 byte "jumbo frame" used in many Gigabit Ethernets entirely practical and capable of helping greatly with VoIP and other real-time traffic.

The catch, of course, is that careful probing is required to make sure that attempts to use large MTUs don't cause more problems than they solve, owing to fragmentation at some point along the way where larger MTUs aren't accommodated. Use of the ping -l buffersize ip-address command (for example ping -1 1470 172.16.1.17) will quickly indicate if endpoints on transmissions with higher MTUs are working properly or not. This rough and ready test can help make sure configurations are set correctly, and when used in tandem with tracert (trace route) or pathping can help isolate segments where all is not as it should be. But generally, this technique is useful only when all points along potential paths support higher bandwidth and hence, larger MTUs.


Ed Tittel is a regular contributor to numerous TechTarget Web sites, and the author of over 100 books on a wide range of computing subjects from markup languages to information security. He's also a contributing editor for Certification Magazine, and edits Que Publising's Exam Cram 2 series of cert prep books. E-mail Ed at etittel@techtarget.com.


This was first published in September 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.