4
$\begingroup$

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?

$\endgroup$
3
$\begingroup$

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.

| cite | improve this answer | |
$\endgroup$
2
$\begingroup$

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.

| cite | improve this answer | |
$\endgroup$
0
$\begingroup$

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.

| cite | improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.