My book defines queuing delay as the time the packet waits to be transmitted onto the link. It defines transmission delay as the amount of time required to push all of the packet's bits onto the link. It defines processing delay as "the time required to examine the packet’s header and determine where to direct the packet". I do not completely understand the difference. The first two sound very similar and processing delay sounds like it is part of one of the other two. Can anyone explain me the difference?
$\begingroup$
$\endgroup$
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
There's some similarity. In the end, they all get bundled up into one big "delay" factor, but the size of the delays depends on different factors so it makes sense to break them apart.
Transmission delay is a delay based on how long it takes to send the signal down the transmission line. This includes costs like the time it takes for an EM signal (or other signal) to propagate from one side to the other. It also includes costs like training signals that are often put on the front of a packet to help the receiver synchronize clocks. The important factor to transmission delays is that the packet is in motion. Once the transmission period starts, bits have to keep appearing on the wire one after another, without unexpected delays.
Queuing delay is a delay based on how long the packet has to sit around in the router. Quite often the wire is busy, so we can't transmit a packet immediately. In these cases, the packet sits, ready to go, in a queue. These delays are almost entirely defined by the amount of traffic on the network (often queuing delay is the only traffic dependent part of the puzzle!). The more traffic there is, the more likely a packet finds itself stuck behind another packet in the queue, just sitting in memory, waiting.
Processing delay is the delay based on how long it takes the router to figure out where to send the packet. Once it figures it out, it will queue the packet for transmission. These costs are predominantly based on the complexity of the protocol. The router must decode enough of the packet to figure out which queue to put the packet in. Sometimes that's easy, sometimes it's not. Typically the lower level layers of the stack have simpler protocols. If a switch doesn't already know which physical port to send a packet to, it will typically send it to all ports, queuing the packet in many queues immediately. On the other hand, at a higher level such as those which come into play in IP protocols, the processing may include making an ARP request to find out the physical address of the destination before queuing the packet for transmission. One may choose to call that a processing delay.
$\begingroup$
$\endgroup$
Late answer, but hopefully I can add something to what the others have already said.
Processing delay
The name is pretty self-explanatory, but I feel like the main hurdle to understanding this is that one might find it difficult to put their finger on what exactly 'processing' consists of. What does, for example, a router do, that would fall under 'processing' a packet? This also depends on the routing protocol employed as well as the IP protocol involved (the structure of an IPv6 datagram is quite different from that of IPv4 and different actions might be required when processing them), but some examples might be (I'm writing these with IPv4):
- decapsulating the ethernet frame into an IP datagram
- computing the Internet checksum (not in ipv6)
- decrementing the TTL field value
- acting on the possible options in the options field of the datagram header, if any (no such field in Ipv6)
- performing a routing decision, determining the appropriate output port, based on a certain routing protocol
- getting the packet from the input port buffer into the output port buffer via the switching fabric of the router
- splitting a datagram into smaller datagrams if the original one is too big to fit the MTU of the outgoing link (this is IP fragmentation, which isn't a thing in ipv6)
- encapsulating the datagram into a frame to be sent out onto the link
Transmission delay
The difficulty I find a lot of people have here is with understanding the difference between processing delay and transmission delay. The answer is that they measure different things. Processing, as seen above, measures the time it takes to process a packet (as exemplified above), whereas transmission has relatively nothing to do with processing, simply measuring the time it takes to push a packet onto the link.
At this stage, the packet is ALREADY PROCESSED, and it's just waiting for transmission. Put another way, imagine we have left off at the last bullet point in the previous 'processing delay' section. The packet is ready to go. What could be limiting this 'transmission' action if the packet (frame, here) is already processed? It's hardware. The action is bound by hardware. Specifically, the transmission delay is determined by the speed of the output line card. The transmission delay is how fast the line can push out the packet.
Queuing delay
Queuing delay is the most difficult one to estimate. It hinges on the other factors (e.g. the processing speed of the router), and so it's inextricably tied to the other types of delays that occur. Primarily, it's determined by how and how much traffic arrives at the queue, the so-called 'traffic intensity', and it can vary from packet to packet.
If traffic is highly congested and the speed of the switching fabric is much higher than the speed of transmission, for example, say 5 times as fast, and you have 50 packets arriving at the input ports and most happen to be pushed to the same output port, then the buffer of the output port will fill up faster than packets can be pushed out. If enough packets get queued up to overflow the buffer, packets start getting dropped.
$\begingroup$
$\endgroup$
Roughly speaking, queuing delay depends on the queue, how many packets are there in the system. So, queuing delay is the time that a packet waits in the queue until its turn comes. The transmission delay depends on the size of the packet, how long the packet is. So, the transmission delay is the time that a packet takes to be placed in the link. (After that comes the propagation delay which is the time that a packet takes to move in the link, which depends on the speed of light.) Finally, processing delay is like the time it takes to read the packet. The packet is arrived at destination and is waiting for processing, that's the processing delay.
$\begingroup$
$\endgroup$
Explanation by Analogy
I'm using firearms analogy. Even if your culture has zero firearm education, you probably can still intuit from movies etc.:
- I have a gun.
- 6 bullets.
- I can only fire one after the other.
Queuing Delay
Bullet number 6 is the last in the chamber. It has to wait until I fire all the bullets preceding it. This time period is the queuing delay.
Propagation Delay
After they are fired, it takes a certain amount of time to hit a bullseye. This time period is the "propagation delay". If the target is far away, then the bullet will take a little more time to reach its destination, even though a bullet travels pretty quickly.
- If I fire in a vacuum - then the propagation will be the speed of the bullet itself.
- If I fire in the air: then it's still quick, but the air is viscous - the air actually slows a bullet down! This is called "drag".
- If I fire through water - the water makes the bullet slow down considerably. The propagation delay is very high.
The same concept applies when transmitting signals through a medium.
If you transmit using sound waves - the propagation delay will be slow. However, we transmit using electrical pulses and light: most signals travel just under the speed of light, because we are transmitting through mediums - e.g. fibre optic cables, and not a vacuum.
(According to Einstein, we cannot transmit faster than the speed of light. If you find out a way to do this: congratulations: you have won yourself a Noble prize).
Transmission Delay
The time taken to load a bullet into a chamber. This is analogous to:
...the amount of time required to push (that is, transmit) all of the packet's bits into....[a link] (Computer Networking: A Top-Down Approach, 7th Edition)
Analogy ain't perfect, but I'm hoping (at least for some) that it helps conceptualise the concepts.
