White Paper

TCP Network Latency and Throughput

Or ‘Why your customer doesn’t receive the Throughput they paid for’

A frequent complaint raised by customers

of a particular service is that they have
TCP versus UDP Background
been sold a particular rate or bandwidth but Traditionally, video was carried over User Datagram Protocol (UDP). UDP is a
when the customer downloads one of the connectionless protocol. Packets are pushed to the destination with no regard for
many applications that can check the actual packet loss or packet order. The problem with UDP is that there is no guarantee that
throughput they then find that they are only the packets will reach the end destination.
receiving a fraction of the bandwidth that they
expected. This leads to complaints, finger Now, most of the streaming video on the internet uses Transmission Control
pointing and customer churn as the disgruntled Protocol (TCP). Video streaming services or applications such as Netflix, Amazon
customer seeks a better available bandwidth and YouTube all use TCP for streaming video. These services account for the bulk
elsewhere. In reality, the available bandwidth of video streaming in the Western world. TCP was designed to ensure delivery of
may be no better elsewhere but by that time it’s all packets and minimize packet loss. It is a connection oriented protocol which
too late. The customer has gone and probably ensures quality of service by re-transmitting packets until all packets are received
won’t be coming back. One of the reasons is correctly. An unintended consequence is that TCP is extremely sensitive to network
that throughput is adversely affected by latency delay as it is a reliable protocol, which means that significant re-transmission can
and packet loss. This white paper explains why occur, and this along with the TCP handshake process is made worse by long
this is the case and shows the effect of latency transmission delays.
and packet loss on service throughput.

What the
customer
gets

5M
3M 10M

2M 20M

NETWORK 1M 30M

0 50M
6.63
Megabits
What the
customer
Packet loss expects
and latency
throttles down
throughput
White Paper

TCP Network Latency and Throughput

Or ‘Why your customer doesn’t receive the Throughput they paid for’

One of the key reasons for the switch form UDP to TCP is that content providers want TCP for reliability/
quality of picture etc. Service providers believe that today’s networks are much higher bandwidth and
therefore able to cope with longer delays and re-transmissions. However, throughput can be much less
than the provisioned capacity of the link. The issues affecting TCP throughput are very often out with
the network operator’s control but as these issues are often significant it’s important that each network
operator can be certain that their network is not causing throughput issues thereby reducing time
consuming finger pointing and troubleshooting. Traditional testing is of the RFC-2544 variety i.e. load
testing which does not capture problems associated with latency and buffer size. Studies have shown
that a correctly configured TCP network can perform up to 10 times faster*.

What Causes Network Latency?

• Propagation Delay: This is the time it takes to send a packet thousands of kilometres. For example, the
propagation delay from New York to London, via optical fiber, is approximately 26ms.

• Routing/Switching Latency: An IP router adds approximately 200us per device. This would add another
1.4ms to the above New York to London link based on assumptions that there is one router per 800km.

• Queuing Latency: This is the amount of time a packet can spend in a queue awaiting transmission due
to congestion after routing/switching. This can add another 20ms of latency.

Why is Network Latency such an issue for TCP?

As discussed above, Latency matters for reliable connection oriented protocols such as TCP. TCP is a
session-based protocol that ensures packet delivery, and minimizes packet loss. As a result throughput
can often be much lower than provisioned capacity. Unlike UDP, TCP requires the receiving end
to acknowledge the successful receipt of packets. However, it is inefficient to wait for successful
acknowledgement of every individual packet before sending the next packet. This is especially true over
long distance networks with long latency. TCP uses the notion of a “window size” to determine how many
packets are likely to be sent without loss. TCP waits on an ACK handshake to establish connection.
If packets are missing TCP uses the ACK to request re-transmission. TCP uses a “windowing” technique
by waiting on ACK to slowly increase the transmission rate to match the available bandwidth. The
transmission rate is rapidly reduced when packets are lost or not acknowledged within an expected time
frame. As a result, throughput is greatly affected by the latency and also by any packet loss in the link.

Network Latency can be such a problem that some satellite links implement TCP spoofing to terminate
the link at the Tx site to pretend that the link has lower delay. This only works if the link is uncongested
and error free.

* (Pittsburgh Supercomputing Center and https://en.wikipedia.org/wiki/TCP_tuning#cite_note-1)

2 I spirent.com
High Speed Network – Effect of a segment at a time. This is done to detect optimal
throughput. The whole process is very sensitive to
Buffering delay through the network. A simple rule in a zero
TCP performs badly in the presence of latency packet loss environment is that:
and tiny amounts of packet loss. In addition, TCP
TCP Rate = MSS/RTD
windowing and latency can be an even bigger
problem in high speed networks. At 100GbE, the where:
TCP windowing buffer fills up much more quickly MSS = Maximum Segment Size
than at 10GbE or 40GbE as the interface input and RTD = Round Trip Delay
output buffers tend not to be scaled up sufficiently
to cope with higher speed traffic. This means (if you TCP is also bursty in nature and spikes exceeding
set the same wait time) that you get a throughput the CIR (Committed Information Rate) can equate
drop-off at even lower latencies than at 10GbE or to lost packets, leading to re-transmission with a
40GbE. smaller window size and consequently reduced
throughput. There is a double hit here as the “ACK”
Some switches are now combating this issue process leads to more messages going back and
by adding many GBytes worth of packet buffer forth which is the very process that takes longer
memory. This is many orders of magnitude greater when there is more latency in the network.
than the amount of buffering in traditional switch/
routers. This helps minimize packet loss, preventing
re-transmission delays and the build up of huge TCP Slow Start
latencies. 1 Segment

Data Loss
As a result, different switches/routers will perform
markedly differently within a network and there ACK
can be a huge resultant difference to the observed
practical traffic throughput within the network.
2 Segments
TCP Windowing (effect of latency
and packet loss on throughput)
CWND
The figure opposite shows the TCP windowing ACK
‘Slow Start’ in action. It is inefficient to send a single 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

frame and then wait for acknowledgement before

sending another. So, TCP ‘Slow Start’ groups the • Slow Start uses a congestion 4 Segments
window (CWND)
frames together into a ‘congestion window’ (CWND) • CWND is initialized to the
to increase throughput. The sender sends out one segment size announced by the
other end of a new connection
packet then waits for ACK before doubling the
number of packets then repeats. When the TCP
window registers that a packet is lost (for example
due to congestion) then the packet window size is
halved. The slow start kicks in again but this time it
will not double the rate but increase more slowly by

spirent.com I 3
White Paper

TCP Network Latency and Throughput

Or ‘Why your customer doesn’t receive the Throughput they paid for’

How is TCP effected by Latency?

The graph below shows the effect of different amounts of latency on throughput. The left hand side shows
the effect of “windowing” with 30ms round trip delay (RTD). Packets are continuously halted as the window
size is full and the sender needs to see ACK. 30ms could be the typical RTD found across the USA. On the
right hand side, with the exact same bandwidth, but with the latency increased to 256ms RTD. This could
represent a typical RTD for a satellite link. You can see that the throughput drops dramatically to almost zero
even though the bandwidth has not decreased.

4 I spirent.com
How is TCP effected by Packet Loss and Latency?
The graph below provides an indication of the effect of 0% packet loss and no latency on the left with
almost full bandwidth utilization. With 3% packet loss, congestion control & slow start process TCP struggles
to fill the link even with no latency. Adding 30ms latency combined with 3% packet loss further impacts
throughput leading to low link utilization. Adding 256ms latency combined with 3% packet loss completely
kills throughput. Therefore, the effect of packet loss and latency on throughput can be extremely severe.

spirent.com I 5
White Paper

TCP Network Latency and Throughput

Or ‘Why your customer doesn’t receive the Throughput they paid for’

How is UDP effected by Latency?

The next two figures show that unlike TCP, UDP is unaffected by latency and packet loss. UDP will
continue to transmit at line rate regardless of latency in the connection. As mentioned above, TCP is a
reliable connection oriented protocol and UDP is not. UDP is connectionless with no reliability built-in and
unlike TCP there is no transmission window that can close. Therefore, UDP is completely unaffected by
latency (there is no ACK process) as there is no re-transmission.

6 I spirent.com
Simulating Latency
In order to know the performance of your TCP network or application/service, it’s important to be able
to simulate the network in your laboratory. Service providers will need to be able to add delay to test the
impact on throughput and will need the ability to error packets and measure the impact on throughput
due to packet loss. It is possible to use drums of fiber to simulate network delay but there are practical
considerations with this approach.

• Drums of fiber are too large: Drums of fiber are very large, heavy and unwieldy. 200km of fiber is needed
for 1ms of delay (5ns/metre). So, to simulate the latency from say Los Angeles to New York which is a
distance of 4,500km then 22.5ms of delay is required. That’s 22.5 drums of 200km fiber.

• Amplifiers are needed: Fiber drums need amplification. Single mode 1310nm fiber has a fiber loss of 0.4
dB per km which equates to 80dB loss for 200km. The specified supported range for a single 100GbE LR4
interface is only 100km. Therefore, optical amplifiers are needed for >100km. Simulating longer links such
as the 4,500km link between LA and New York needs a lot of amplification. That’s a lot more cost and
complexity.

• Lack of control: If a test fails with 200km of fiber (1ms latency) it’s not easy to finely adjust fiber length
to find point of failure. Splicing fiber is one method but that’s a time consuming practice and is a one
time event unless you want to purchase more fiber. Adding additional drums to increase latency is
also problematic. It doesn’t lend itself to automation either. You may want or need to control latency via
software that either adds or decreases the latency in small incremental steps.

spirent.com I 7
White Paper

TCP Network Latency and Throughput

Or ‘Why your customer doesn’t receive the Throughput they paid for’

About Spirent Conclusion

Spirent provides software solutions to high-tech Streaming video is now predominantly carried by TCP (Amazon, Netflix and
equipment manufacturers and service providers YouTube). Network latency which is caused by Propagation Delay, Switching/
that simplify and accelerate device and system Routing and Buffering/Queuing is a big issue for TCP networks. Latency kills TCP
testing. Developers and testers create and share throughput as TCP waits for ACK before sending the next packets. This process is
automated tests that control and analyze results greatly affected by delay. Re-transmission is also needed if packets are dropped/
from multiple devices, traffic generators, and lost and this process is also severely impacted by latency. Latency is an even bigger
applications while automatically documenting problem in high speed networks as the TCP windowing buffer fills up much more
each test with pass-fail criteria. With Spirent quickly.
solutions, companies can move along the path
toward automation while accelerating QA cycles, So, it’s important to be able to check the effect of latency and dropped packets by
reducing time to market, and increasing the emulating the network and or service in the lab. You need to be able to add delay to
quality of released products. Industries such test the impact of latency on your network or service’s throughput. Plus, you need to
as communications, aerospace and defense, be able to error packets and measure the impact on throughput due to packet loss.
consumer electronics, automotive, industrial,
and medical devices have benefited from
Spirent products. • TCP re-transmits packets to ensure packet delivery and therefore Quality
of Service.

• As a result, TCP is very sensitive to Network Latency and Packet Loss.

• Packet Loss and Latency can completely kill TCP throughput.

• The biggest complaint of end users is being promised xGb/s of service

and receiving significantly less.

• Check the effect of latency and dropped packets by emulating the

network and or service in the lab.

spirent.com
AMERICAS 1-800-SPIRENT
+1-800-774-7368 | [email protected] © 2016 Spirent. All Rights Reserved.
EUROPE AND THE MIDDLE EAST
All of the company names and/or brand names and/or product names referred to in this document, in particular, the name “Spirent”
+44 (0) 1293 767979 | [email protected] and its logo device, are either registered trademarks or trademarks of Spirent plc and its subsidiaries, pending registration in
ASIA AND THE PACIFIC accordance with relevant national laws. All other registered trademarks or trademarks are the property of their respective owners.
+86-10-8518-2539 | [email protected] The information contained in this document is subject to change without notice and does not represent a commitment on the part
of Spirent. The information in this document is believed to be accurate and reliable; however, Spirent assumes no responsibility or
liability for any errors or inaccuracies that may appear in the document. Rev A. | 05/16