I have difficulty in deriving a mathematical model/equation to estimate the round trip latency between two nodes communicating using TCP/IP. The nodes are exchanging data based on HTTP protocol. In this model, the most important factors to study are physical distance between two nodes in the network, number of intermediate hops, bandwidth, processing delay at each hop. I searched the web but could not find anything in this sense, rather found something about circuit switching networks and UDP protocol. Can I customize them to fit in TCP?
This is a very complicated process, so to formulate an equation that could be useful for accurately predicting RTTs is extremely difficult. At best, I would say you could create a model that using a bunch of averages for each stage, that you could tweak if you happen to "know better" for a particular situation is about as close as you can get. This is something I am presently studying so I can tell you what I know so far (from the ground up, starting at the physical layer):
See my questions on the Electronics SE; Encoding delay of Ethernet and the relation to cable frequency rating and Speed of electricity (signal propagation?) through copper for communications delay. Since you would be using standardised speeds (100Mbps, 1Gbps, 10Gbps etc), don't treat fibre or copper differently. The "delay" down the two is near as damn it the same, but copper can't carry a signal as far obviously. I have this question on the Physics SE site, which I do know the answer to now. I just need to find the time to right it up, so keep an eye on that if you are interested (I will be posting some more telecoms-use-of-fibre related questions to which I now know the answer when I get a chance).
Much more delay is going to be added in by the devices at the end of a link. There is no standard way of saying "oh 2 switches along a path is Xms delay, 4 switches is 2*Xms, 2 routers is Yms...etc". Assuming you are using say 1Gpbs for example and the devices in the path forward at line rate, we know that is 1000000000bps, so the physical interface is running at a fixed encoding rate (ranging from 1 nanosecond per bit up to whatever the max of the symbol encoding scheme in use is, such as 10b)
There are three main kinds of delay (at the physical layer) you need to be aware of and factor in; Serialisation delay, encoding delay, propagation delay (and processing delay, queueing delay, encode and decoding delay, but these are above the physical layer but need mentioning!). These are reasonably well documented on the Internet, VoIP: An In-Depth Analysis, Slide 13 here, loads on Google Scholar, and many more.
As we move up the protocol stack, I would work on the assumption that the destination MAC is in each switches cam table, and at the IP layer, the destination MAC in ARP tables. The extra delay induced by these discovery processes only occurs for the first packet in a flow so they can be circumvented by raising time-outs and sending gratuitous ARPs etc.
As you get to the application layer this is going to get really difficult because this depends on the server (for example) processing the request, which will be subject to interrupt delay. The number of interrupts required to process the request and context switches due to load is unpredictable.
I would very much like to help you with your question, sadly this is all I have time for right now. I will update this answer maybe later tonight or tomorrow, I wanted to post what I have so far.
In the mean time, most people tend to work with the figure for the delay at a physical copper/fibre layer of around 0.6*c (C = speed of light). Also, you need to think about TCP's exchange of ACKs every X packets, which differs if you are using SACK for example, and if you're using jumbo frames and/or larger MSS size (now MTU needs to be factored in also!), if you're sending more in-between ACKs (if volume of data transferred is of interest to you). You also need to factor in the infamous Bandwidth Delay Product and don't make the stupid misinterpretation that I did of that page. I started making various simple (and very ugly) data calculators here. Again a work in progress I will try and update them soon. I plan to add a calculator similar to what you are trying to do. I have also made some light and fibre calculators if you are interested, but again, no time!, I haven't gotten round to uploading them yet. I will try ASAP to update this answer some more, in the coming days.
P.S. I forgot to mention QoS! If QoS is in play anywhere in the path, it's going to get really tough to caluclate the RTT!
(I want to point out that others have posted excellent answers about how the delays et al work and what causes them. But the OP asked about modeling; A basic model is simple and you just plug in example numbers. If you want to know why the delays are what they are, then see everyone else's answers :^)
The network latency is simply the transit time from one end point across to the other end point, spanning N hops between.
So you have N segments (hops) with N-1 intermediate nodes. Each node has a delay (the cumulative effect of several things on that node, like queue delay, processing delays, etc), and each segment has a transit delay. Overall that's 2N - 1 independent variables. So it's seg1 +node1 +seg2 ... +node(N-1) +segN One hop, is just =seg1 , two hopes is seg1 +node1 +seg2, etc.
Next you have to define what all those pieces are. So you might construct a model network with a CATV network, a satellite link, a fiber optic link, an ethernet, etc. For each of those technologies you have to look up example information.
The transit delays would be approximately the data size divided by the transmission speed of the segment. If you need a more accurate model, you have add the flight time lag -- approximately the length of the segment, divided by the speed of data flow (approximate the speed of light.) This DOES matter if you have a satellite link involved; The up-and-down to the the geosynchronous satellite is significant.
The delays on each node you will have to estimate based on what equipment you are placing into your model.
If you want the application latency, (for example the delay until the start of an FTP transfer's data flow,) then you build up by counting how many times your network latency comes into play. For example, a 3-way TCP handshake adds triple-the network latency, and so on building up to what the application sees.
You can estimate the round trip latency by taking a packet capture on either side, then measure the delay between requests going out from the monitored machine and responses coming back. For example, if you mark the time a SYN went out to the remote machine, then marked the time the SYN+ACK response came in, the difference would give you a pretty good ballpark of the round trip TCP latency.
Keep in mind that this will be greater than the true network latency, and how much greater depends on how heavily loaded either machine is.
The delay between two hosts will be dependent on several factors:
- Propagation delay
- Serialization delay
- Queueing/buffering delay
Propagation delay is how long time it takes physically for the packets to travel between two locations. Speed of light in fibre is around 200000 km/s. Sweden where I live is around 1570 km so that would be 7.85 ms but in reality it's more because that is the distance via birds view.
Serialization delay is how much time it takes to seralize the packet through the physical medium, that is the interfaces on the networking device. If you have a 2 Mbit connection and you are sending a 1500 byte packet that would be 6 ms to serialize the packet(12000/2000000).
Queueing/buffering delay is how much time the packet has to stay in a queue/buffer before being sent out on the interface. Depending on the speed on the interface and how large buffers are used this could be next no nothing or a significant delay.
Then there would be some delay on the hosts to generate the packets and for the application to handle them. There are applications to measure HTTP delay. People don't accept much delay on web sites before giving up on them so it's an important factor.