Who Moved My Throughput?!

by TzvikaNaveh | Sep 17, 2013 12:05:19 AM

Why increasing the data rate is simply not enough (and why we’re not getting the TCP throughput we think we should be getting)?

Demand for more throughput from our networks continues to increase unabated. However, operators need to be aware of certain limitations to meeting this demand. Merely increasing data rates won’t always do the trick. While we want to think that pushing higher data rates equates to greater throughput, this is not always the case.

Many 3G networks are Ethernet-based. And Ethernet lies at the heart of new 4G/LTE networks. But Ethernet has its data-rate limitations. In fact, forcing on an Ethernet service a data rate that is greater than the service’s capacity will result in poor, not better, user experience! Packets may be dropped and re-transmissions may be required, resulting in net throughputs much lower than expected. Furthermore, in LTE networks running Ethernet’s standard Transport Control Protocol (TCP), instantaneous congestion issues can arise frequently resulting in sudden, large bursts that contribute further to throughput reduction.

pic 1

Throughput is actually affected by many factors including: bandwidth profile, traffic policing and shaping, protocol of choice and other settable parameters such as delay, delay variation, frame-loss ratio and frame size. Since mobile 3G and 4G/LTE networks run most services and applications over the TCP protocol, I’ll focus on this particular factor in this post. (You may refer to a technical brief on the subject of throughput for a more complete technical explanation of the other factors mentioned above.)

TCP is subject to congestion problems which, in turn, affect the throughput of a network. With TCP, instantaneous congestion results in sudden, large bursts that contribute to throughput reduction and poor quality of experience for the user. Key quality-of-experience issues include optimally setting the TCP window size on applications that require higher speed or that are delivered via services with longer delays.

pic 2

In fact, TCP window limitations can be seen even on Ethernet services transmitting at information rates as low as 13 Mbit/s when combined with transmission delays in the range of 40 ms (source – MEF White Paper). If the round-trip delay is great, the window-size limit can be reached causing the sender to stop sending while he waits for an acknowledgement, reducing throughput.

pic 3

From my experience in real LTE backhaul deployments where we were asked by mobile operators to figure out why they’re “not getting the throughput they think they should be getting”, it was clear that throwing more capacity at the problem was not always the right answer. Bursty traffic is an emerging impediment to maximizing throughput in LTE networks that employ the TCP protocol. Conclusion: throughput is greatly affected by TCP’s Round Trip Delay and Window Buffer Size parameters.

Network operators who would like to make sure their network is LTE-ready and will effectively handle strict service and application requirements should take into consideration their backhaul network’s readiness for sudden, bursty traffic. Priority queues with configurable buffer lengths might be the key to handling various types of TCP-oriented traffic in order to maximize the utilization of network resources and actual throughput.

More information and recommendations for testing TCP throughput over mobile networks is available here.

Tzvika Naveh is the Director of Product Marketing at Ceragon Networks. Since 2008, Tzvika has assisted in establishing Ceragon’s architecture program to tailor solutions for global mobile operator customers. Today, he manages the company’s product marketing team. Tzvika holds a BSc degree in Computer Science Engineering from the Ben-Gurion University and an MBA from the Israeli Open-University.

Short Haul, Holistic HetNet Hauling (3H), ISPs & RSPs


Written by TzvikaNaveh