Does increasing the bandwidth on a link from, let's say, 1mb to 30mb reduce the RTT?
I have found one answer saying no. Can someone please explain?
Also, what are the best mechanisms to reduce RTT?
Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.Sign up to join this community
Does increasing the bandwidth on a link from lets say 1mb to 30mb reduce the RTT?
In short, yes; you are changing serialization delay; at 1Mbps the serialization delay is non-trivial.
Compare the serialization delay for a 1500 Byte packet at 1Mbps and 30Mbps:
1500 Bytes * 8 bits/Byte / 1,000,000 bits/second = 12 milliseconds (at 1Mbps) 1500 Bytes * 8 bits/Byte / 30,000,000 bits/second = 0.4 milliseconds (at 30Mbps)
Remember also that those are unidirectional numbers; you should double them when considering RTT. Whether you care about 11.6 milliseconds difference in each direction at 1500 bytes is another question, but strictly speaking you can influence RTT with link speed.
Does increasing the bandwidth on a link from lets say 1mb to 30mb reduce the RTT?
No, increasing the bandwidth does not reduce RTT strictly speaking. I say "strictly speaking" because it depends on what your are measuring!
Scenario 1: The physical layer
Given the following simple topology which is easy to follow, a copper Ethernet connection running at 1Mbps with an MTU of 1500 bytes between two devices with a 10 meter cable, this has the same RTT (the time it would take for an ICMP echo request packet to travel from device 1 to device 2 and the ICMP echo reply message to travel from device 2 back to device 1) as a 10/30/50/100mbps copper Ethernet connection between them with a 1500 byte MTU on the same 10 meter cable.
This is because the "delay" of the signal down the copper cable is related to its dialectic constant (relative permittivity). See those two Wikipedia pages for additional information on the physics which are out of scope here.
Essentially the "flight time" of the electrical signals down the copper cable is the same speed for a 10Mbps and a 1000Mbps connection when using the same length and grade Cat5e cable. The difference is that with a 10Mbps connection data is encoded on to the wire less frequently then a 100Mbps connection, so there are smaller gaps between the bits of data as they are placed on to the wire (this is called serialisation delay). These two wikipedia articles expand these concepts further: Bit time and Slot time.
Scenario 2: Layer 4 and above (TCP example)
Given the following example topology, a copper Ethernet connection running at 1Mbps with an MTU of 1500 bytes between two devices with a 10 meter cable. If you have X amount of data which we shall pretend is 100 Megabytes of data to transport between device 1 and device 2, this will take longer than it would with an 30 or 100Mbps copper Ethernet connection with an MTU of 1500 bytes on a 10 meter copper cable between the same two devices. This is because it takes longer to encode and transmit the data on the wire and the receiving NIC will be equally as slow at receiving and decoding the signals.
Here the RTT of "actual data" that is perhaps a single 100MB file will take longer because with the higher level protocols introduced you not only have to transfer the data but also may SYNs, ACKs and PUSH's packets exchanged here using additional bit times, before at the application layer a message can be sent from device 2 to device 1 saying "I have received all the data now".
Also, what is the best mechanisms to reduce RTT.
Short answer: not much
To bring this into a real life example expanding on the examples above; If you are "pinging" between two devices that are connected together via several intermediary routers and/or switches the RTT is a product of the physical distance and the time it takes for the signals to travel that far and back through all those devices (basically). If QoS is configured on these devices that can increase the end-to-end delay too and complicate the model further.
There isn't much you can do here apart from (in a purely hypothetical situation where money is no object and politics don't matter etc); Install a fibre connection that runs directly from device 1 to device 2 cutting out all the switches and routers in between. That would be an ideal scenario. Realistically you could upgrade any copper or wireless links to fibre (not that fibre is hugely faster [i], [ii]) and try to make the connection path as direct as possible so that data passes through the least amount of intermediary devices and different physical connections. QoS tuning and traffic engineering (constraint based routing) can also help over larger distances with many hops in between.
If you are wanting to transfer data between to points with what you consider to have "too high an RTT" you can look at technologies like TCP SACK which is in use in many places already, but if you read up on that it will give you a starting point as there are other similar technologies you can then look into. This includes technologies such as WAN accelerators and compressors, although that would be digressing out of the scope of this topic. You must consider with data transfer over a link with a high RTT the BDP (Bandwidth Delay Product, [iii]) - when using something like TCP this will always hold you back.
[i] The "flight" time over a copper dielectric medium is very similar to a fibre waveguide
[ii] This could change though, new research and technologies will hopefully bring the speed of light in a fibre up from the average of 0.6*c to near 1.0*c, http://www.orc.soton.ac.uk/speedoflight.html
[iii] http://www.kehlet.cx/articles/99.html - BDP example
The thing most directly affecting RTT is signalling speed. Look at the progression of ethernet over the eons: 10M, 100M, 1G, 10G, 40G, and 100G. Each following version (except 40G) is 10x faster than the previous; the time to transmit a single bit is 1/10th as long. The time to transmit a full (1500B) frame drops by a factor of 10.
So, the answer to your question depends on the link layer. If the change in bandwidth has no corresponding change in link speed, then it will have minimal effect on RTT -- because traffic policing isn't done per bit. For example, my office metro-e connection is physically 1G, but it's shaped to 100M at both ends. Bits flow at 1G speeds; ethernet frames will be delayed as necessary to keep the average (over 1s, 10s, etc.) at or below 100M. In simple terms, a single frame transmits at link speed.
If you're talking about DSL, then the change in bandwidth is most likely also a change in link speed. But not always. The sync speed will normally be higher than the profile rate. My DSL line syncs at 8M down, 1M up, but the profile limits it to 6/512k. I've seen Uverse lines sync as high as 60M but still have a 25M profile.
No one mentioned the link loading.
On otherwise empty links then not much difference between 1Mb and 30Mb - sure the encoding can be done in 1/30th the time but this is negligible if the distance is the dominating factor.
However, if the 1Mb link is heavily loaded (overloaded?) then you will see increased (and fluctuating) ping times.
The same traffic load on a 30Mb link represents only a few % of its capacity and so ping times will be faster and more consistent.
The Two-Way Active Measurement Protocol (TWAMP) defines a flexible method for measuring round-trip IP performance among any two devices in a network that support the standard.
The real answer is it's complicated.
Latency is made up of multiple components.
Time spent travelling through the physical medium can only be changed by choosing a different physical medium.
Time spent sitting in queues will generally be reduced by having faster links. So will time spent serialising and de-serialising data.
The effects on processing can get complicated. If the processing step stays the same then it will generally take less time at a faster data rate. However techniques designed to extract more bandwidth from existing links may also introduce additional processing delays. A classic example of this is DSL interleaving.