Many people, even networking engineers, erroneously believe that this delay is caused by router hops across the network, with each router taking time to process the packet and forward it to the next one. While this may be true on the LAN where devices are physically close to each other, over the WAN the latency is predominantly caused by distance – or to be more exact, by the amount of time it takes an electromagnetic signal to travel between the two locations.
Except for those moments when we drift off and reflect on the complications of interstellar travel (at least that’s what I tell my wife I’m thinking about when I stare off into space), we usually consider the speed of light to be close enough to infinite to ignore in everyday life. But at computer processing speeds, it’s significant enough to affect even cross-town communications and can equal hundreds of milliseconds for intercontinental connections. But let’s start at the beginning…
Latency Breakdown
For an application to send data and receive a response, there are multiple sources of latency. Starting from the top of the ISO stack:
1. Application/host delay: The amount of time it takes the sending application to hand the packet to the TCP/IP stack, and on the other side, for the recipient to process the incoming data and send a response is called the application delay. For a simple ping packet/icmp echo response, this is usually measured in microseconds, and unless you’re in the business of high-frequency trading, can usually be ignored. For complex applications, of course, the time it takes the server to generate and send a response can be far greater than any network delays, but application delays are an entirely separate topic.
2. Transmission or serialization delay: We often think of a packet as a single thing that’s sent across the wire, but it’s really a long series of ones and zeroes that have to be transmitted one at a time. The amount of time from when the first bit is transmitted out the interface until the last bit in the packet is transmitted is called the transmission delay or serialization delay. Obviously, the delay is longer for bigger packets and slower networks. For example, transmitting a 64 byte packet onto a 1 Gbps network takes an insignificant half microsecond, and even a full 1500 byte packet on a gigabit speed line takes only 0.12 ms , but transmitting a 1500 byte packet over a 768 Kbps DSL return line takes 16 ms. Fortunately, few people are still stuck having to use a 56 Kbps modem.
3. Propagation delay: The amount of time it takes to transmit a bit of data from one side of a wire or cable to the other is called the propagation delay, and is usually the primary source of WAN latency. The speed of light through glass fiber is approximately 200,000 km/s, or 5 ms per 1000 km. For example, the distance between Los Angeles and NY is 5000 km, causing a delay of 50 ms for a signal to cross the country through a fiber network and the response to return.
4. Queuing or congestion delay: If more packets arrive for a link than the bandwidth can support, the router will buffer the excess (up to some limit, after which it will drop the extra packets.) The time that the packet is held by the router awaiting its turn for transmission is the queuing or congestion delay. The amount of delay depends on how much other traffic is in the queue in front of it, or in other words, how congested the links are.
Adding It Up
Putting it all together, the total round trip time to send a packet and receive the response is equal to the application delay on both the sender and receiver, the serialization delay for each hop along the way (though backbone links are usually 10 Gbps or higher, making serialization delay only significant on low speed access links), plus propagation delay for each direction, plus any congestion delay. The picture below shows a traceroute from Los Angeles (over a Verizon FIOS connection) to the Columbia University web server in New York. The packet bounces between a few different Verizon routers in Los Angeles, adding about 10 ms of latency. Then the packet goes through Houston, Atlanta, and Washington before reaching New York, taking about 80 ms to cross the country. Finally, it bounces around NY before arriving at the server.
Running the same traceroute over a DSL line, the first hop between the DSL router and the carrier’s network takes 23 ms instead of 4 ms due to the serialization delay of the low speed DSL link. The Netropy Recorder utility (available from Apposite for use with the Linktropy and Netropy WAN emulators) records the latency between sites. A recording of the latency to the Columbia University web server shows a RTT between 105 ms and 129 ms. It’s most useful to consider the minimum value of 105 ms to be the latency between the sites, and the extra 0-24 ms to be congestion delay along the path. This recording was taken over the DSL line, so latencies are about 20 ms higher than over the fiber access link.
As a second example, a traceroute from Los Angeles to Yahoo Japan’s server in Osaka shows a similar story: approximately 10 ms bouncing around Los Angeles to get to NTT’s network, 110 ms to cross the Pacific, a few more milliseconds bouncing around Osaka, and up to 30 ms to get a response from the server itself.
The Netropy Recorder utility shows this variability even clearer. Latency ranges from 142 ms to 171 ms. The recording was again performed over the DSL line, so latency was approximately 20 ms higher than with the fiber connection.
Overall, for WAN connections, latency is mostly a function of distance due to the speed of light. Serialization of the packet onto a low speed link can add 10-20 ms, and congestion causes the delay to vary from its minimum values. To learn more about simulating latency using the Netropy WAN emulator and Netropy Recorder, see the Netropy product page at: http://www.apposite-tech.com/products/
No comments:
Post a Comment