So I was going through the exercises in the 'Kurose and Ross' book.

Suppose users share a 2 Mbps link. Also, suppose each user transmits continuously at 1 Mbps when transmitting, but each user transmits only 20 percent of the time. Suppose packet switching is used. Why will there be essentially no queuing delay before the link if two or fewer users transmit at the same time? Why will there be a queuing delay if three users transmit at the same time?

The solution says that there won't be any queuing delay since the output link has a 2Mbps bandwidth. But if both the user is sending the packet simultaneously,won't there be a delay to the second packet that arrived. Suppose 1Mb packet is sent at the same time from the two sources, then the second packet will suffer a 0.5s queuing delay right? That's what I understood and please correct me if I'm wrong.

  • $\begingroup$ Note the 1Mb packet size in relation to bandwidth. $\endgroup$
    – greybeard
    Nov 27, 2021 at 8:42

1 Answer 1


you are absolutely right, if two packets arrive simultaneously, then one of the packets will have to wait for the other one to be sent. Actually, queues are there in the first place, because in a packet switched network this is likely to happen.

I don't think, that this situation is generally referred to as having a queue. Since in packet switched networks (as opposite to cirquit switched networks) this situation is sort of artifact of the design, such short term queue which happens because packets are arriving at once and where all packets are removed from the queue shortly after are expected to happen. They are referred to as temporary bursts, or maybe temporary queue or short term queues. When we talk about queues, we usually talk about queues that build up and persist over "longer" period of time (without the proper definition of longer), because these queues arise when senders are sending too much data (also known as persistent queue). Because usually this is what needs to be avoided. If there is a permanent queue on the interface, then all traffic passing though this interface takes longer to deliver, and we usually do not want extra latency.

P.S.. In "best effort" delivery model, your application, is supposed to deal with the fact that there can be short term queues, because a burst of packets can arrive simultaneously. If you consider "textbook" applications, like file transfer, they are indeed not a problem. I am not sure how it is for the web, but should also not be that big of a deal. There are applications that do not deal with these bursts: almost all real-time multimedia (video-conferences, online streaming), and they require special support from the network devices in order to avoid this. However, the queue of one packet is unavoidable, as once sending of the packet has started, it is usually not interrupted. There is a different class of networks - real-time, where this one-packet latency is a problem, and they require even more complicated logic to avoid it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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