Pages

Thursday, 25 August 2016

TCP: RTT (Round Trip Times) and RTO (Retransmission Timeouts)

A RTT (Round Trip Time) in TCP terms simply defines how long to takes for a client to make a request for example when a sender sends a SYN and then recieve an SYN ACK back from the receiver.

Quite often people will refer to an 'initial RTT' - which is simply the time involved establishing a three way handshake between the two nodes (SYN, SYN ACK, SYN.)

Although it generally not a good idea to capture packets on the client / server side for the following reasons:

- Windows clients frequently have a lot of security software installed that can hinder / alter / block packets.
- Results can be misleading - for example when TCP Segmentation Offloading is being performed.

So instead we will capture by sniffing in between the traffic - although at first glance this does present a slight issue when attempting to attempting to calculate the initial RTT - this is because by the time the network sniffer sees the ACK message from the client it has already travelled some distance and hence it is not possible calculate the overall time - the same applies to the SYN ACK message originating from the server.

Although it is actually pretty easy to get the RTT with some basic math - we simply take the following timings:

- How long it takes the sniffer from when it first see's the SYN origniating from the client until it see's the reply (SYN ACK) from the server.
- How long it takes the snigger from when it first see's the SYN ACK (from the server) until when it first hears the SYN back from the client.

If you put the above two together you will get the initial RTT - the diagram below (courtesy of packet-foo.com) does a very good job of visualising this:



A RTO (Retransmission Timeout): When TCP packets are sent to their destination a retransmission timer begins to count down - if this timer expires before anything is heard back from the destination host the packet(s) are re-transmitted. Now in the event that the re-transmission timer has failed a certain numbers of times a RTO is then imposed - for example the client's TCP stack might hold of sending the packet for 1 second and then attempt to retransmit the packet and if successful gradually send more and more.

If nothing is heard back the client's TCP stack will double the timeout value each time the previous timer expires - for example 3 seconds, 6 seconds, 12 seconds and so on - this process is reffered to as exponential backoff.

One of the initial questions I had was whether the RTO is a static value (i.e. 1s) or whether it varies - and as it turns out it varies (and can do quite significantly) depending on RTT's and various other factors - a much more detailed explanation can be found here: http://unix.stackexchange.com/questions/210367/changing-the-tcp-rto-value-in-linux

Sources:  
https://blog.packet-foo.com/2014/07/determining-tcp-initial-round-trip-time/
http://sgros.blogspot.co.uk/2012/02/calculating-tcp-rto.html

No comments:

Post a Comment