Jitter and delay can influence various types of applications. In applications that run over TCP, high delay reduces the effective throughput that can be sent and high jitter can cause packet losses and retransmissions. In multimedia applications that run over RTP, which runs over UDP, high jitter and delay can cause severe disturbances in the voice and video quality.
In this recipe, we will get into the details: the influence of behavior on TCP, and how it can influence the application behavior. RTP over UDP behavior was discussed in Chapter 12, SIP, Multimedia, and IP Telephony.
When you ping a remote site and get high delays, and in the Wireshark you see many retransmissions, it can be because of high network or applications delay. Connect the Wireshark to the network and configure port mirror to the link that you test.
The purpose of this recipe is to check whether the TCP retransmissions and duplicate ACKs are due to delay and jitter or other problems.
When experiencing many TCP retransmissions, perform the following tests:
- Check whether retransmissions are coming from the same application or from the same IP address. In this case, it is a slow application or a slow device and probably not a network delay issue.
If retransmissions are distributed between various applications and devices, it can be because of unstable line that causes network delays.
- Configure a display filter
tcp.analysis.retransmissions(numbered 1 in the following diagram). A list of all retransmissions in the packet list will appear.
- Down the packet details pane, expand the TCP Analysis Flags, and you will get:
- Usually the Retransmission Time Out (RTO) timer will be around 0.2 seconds for local connections, and up to 0.3 to 0.4 seconds for international connections. Start with assuming 0.2 seconds. Refer to the How it works... section in this recipe for explanation about the RTO mechanism.
- To check TCP delay over a connection, use IO Graphs with the following filters, as presented in the next diagram:
tcp.stream eq <the stream number>to get to the stream number right-click on a packet and select Follow TCP stream.frame.time_deltato see the time difference between frames in the TCP stream. This parameter actually shows inter-frame delta in layer 2, but since it is shown only for the stream, it will show us inter-frame deltas in a specific TCP stream.
You get a graph that shows a very stable connection, with delays that are lower than 20 ms, except for the two increases in delay in time 250s (250 seconds since the beginning of the capture), that causes retransmissions.
- When we add the
tcp.analysis.ack_rttfilter on the same connection, we see the delays between TCP packets and ACKs.
In the following diagram, you see a graph which is an example for delays not due to line delay issues:
- You can see here that I've configured:
- The Advance option in the Y Axis
- The Filter field: tcp.stream eq 0 (numbered 1 in the preceding diagram) to present a single stream
- The calculation AVG(*) to see the average (2)
- You can also configure MAX(*) and the filter
tcp.analysis.ack_rttto see the time to acknowledge every TCP sequence
What we've got is the time that it took to acknowledge every TCP packet.
- Now, let's configure IO Graphs to see if there are TCP retransmissions, and why they happen:
- Use the same IO Graph with Advance in Y Axis, and configure the second line.
- The Filter field: tcp.stream eq 0 (numbered 1 in the preceding diagram) to present a single stream.
- The calculation COUNT FRAMES(*) to see the average.
- The filter
tcp.analysis.retransmissionsto see the time to acknowledge every TCP packet.
- We can see from here that all retransmissions happened when there was a significant increase in the delay, so it is a delay problem. We cannot say from here if the delay is from the network, from the end device or from the application, so for isolating the problem check how retransmissions are distributed (see Chapter 9, UDP/TCP Analysis).
- Retransmissions that are not due to increase in RTT are probably due to packet losses.
TCP uses the retransmission mechanism to ensure data delivery in the absence of any feedback from the remote data receiver. The duration of this timer is referred to as Retransmission Time Out (RTO). This mechanism was first standardized in RFC1122 that specified that the RTO should be calculated as outlined in the Jacobson V. and M. Karels, Congestion Avoidance and Control, article from 1988. An update to this RFC came out in RFC 2988 in November 2000, and later in RFC 6298 Computing TCP's Retransmission Timer, June 2011.
For delay variations, you can also navigate to Statistics | TCP Stream Graph | Round Trip Time Graph.
When experiencing high delays, it also influences the throughput you can get from the network. This is what is called as the bandwidth delay product as shown in the following figure:
From here we can see that the higher the delay is, the lower the throughput becomes. In networks with high delays, for example, old cellular networks, satellite lines, and long distance international lines, we have several methods to improve the application's throughput. Among these methods are applications that use multiple connections per application, usage of the TCP increases the window size (comes as default in Window Vista and the higher versions, along with various Linux versions).