Why does a queue of a network device like router starts to fill up if the arrival rate equals the transmission rate of the outbound link?

Question

In the book "Computer Networks: A Top Down Approach by Kurose" it is written that when the traffic intensity approaches 1, the average queue length gets larger and larger. Traffic intensity is La/R where

L= no of bits in a packet
a= Average arrival rate of packets 
R= Transmission rate of the link

The java applet also shows this. https://computerscience.unicam.it/marcantoni/reti/applet/QueuingAndLossInteractive/1.html

Shouldn't there be no queue at all?

Answer 1

I don't have that book, but I suspect what he's getting at is is that, while the average arrival rate may equal the maximum transmission rate, there can be fluctuations in the arrival rate. When the arrival rate fluctuates above the transmission rate, the queue fills up (assuming it doesn't drop packets). When the arrival rate fluctuates below the max transmission rate... well, if there's something in the queue, it can do a bit of catching up, but if not, it can never get ahead.

As a result, the queue size will fluctuate, and (because of the asymmetry between getting behind vs. getting ahead) it turns out that over time the average size will grow without bound.

Put it another way: the actual transmission rate will be lower than the maximum transmission rate by an amount proportional to the fraction of time the queue spends empty. The only way this can equal the average arrival rate is if the queue spends 0% of the time empty (well, ignoring the possibility that the arrival rate never fluctuates at all). And the only way this can happen is if the average queue size is infinite. Over time, it will approach this situation.

Answer 2

Very obviously, when the ingress rate exceeds the egress rate (that "traffic intensity" exceeds 1) you've got exactly two options:

1. queue the data (with the hope to catch up when the ingress rate slows down again)
2. drop the data (and have someone else clean up the mess)

Neither method is the always-right solution.

1. You can't queue indefinitely (memory is finite) and large queues have adverse effects on latency and congestion detection.
2. Dropping data causes data loss or retransmission which are not desired or inefficient.

The trick is to queue, but size your queue buffer just so that latency and congestion detection are barely effected while keeping data loss and retransmission at a minimum (shallow buffering).

Edit - As your question seems to be really about the queuing/buffering for an equal ingress/egress rate and an eventual buffer overflow:

I suppose, Kurose tries to point out that the internal processing overhead eats into the egress capacity, which in turn causes a slight imbalance between ingress and egress. That was true for (most) software-based forwarding.

However, most modern devices use hardware-based forwarding which can receive, process, and transmit truly simultaneously. So, processing can overlap with queueing (or rather buffering), and the described buffer growth doesn't really happen any more.

Answer 3

The queue filling is a natural effect of Data Transmission protocols such as TCP(connection based) which has a send buffer of data on the client, which get filled and then released onto the network.

before more data can be send, the sender needs to waiting for acknowledgement of the data from the receiver, causes an high/low traffic fluctorion of the bandwidth used.