Application RTT
RTT, or Round-trip time, is the total time taken to send the first packet to the destination, plus the time taken to receive the response packet. This is calculated during the connection establishment phase (the 3-way handshake) of every TCP connection Sinefa monitors.
RTT is a good indicator of the latency of a connection between the client and server. A larger RTT indicates a larger latency. Generally connections made to closer locations will have a lower RTT and those to locations further away a larger RTT.
A large RTT may indicate one of the following:
- Poor quality link
- Congestion on the link
- A busy server struggling to handle the connection
One way to understand how RTT affects applications performance is through the example of a web browser. When we load a web page in a browser we must first send out a a request to load the page. This will take at least one RTT to get the response. It generally takes more than a single request to load the entire page. The page might consist of images, scripts and other components, each requiring a separate request to load. If the page consists of 30 components, assuming the browser doesn't send multiple requests at a time, it may take RTT x 30 to request the entire page. If the RTT of the link were to double it would also double the time taken to load the page.
TCP Health
TCP Health is a measure of the percentage of TCP packets that are not retransmitted. If 1 out of every 100 packets are retransmitted the TCP Health of the connection will be 99%. (100 - 1) / 100 x 100 = 99%
Packets generally have to be retransmitted when they are lost in the network.
For each retransmitted packet the connection has to wait an extra RTT to deliver the data. The connection may also back off and send future data at a slower rate to avoid future retransmissions. The lower the TCP Health the poorer the application will perform.
See Also
How to set-up Network Quality Reporting
How are quality metrics measured
Comments
0 comments
Article is closed for comments.