Consider the image to the right. The individual link bandwidths are summarized in the table below.
| Link | Bandwidth | Packet Size | Xmit Time |
|---|---|---|---|
| A | RA = 100 Mb/s | LA | LA/RA |
| B | RB = 40 Mb/s | LB | LB/RB |
| C | RC = 20 Mb/s | LC | LC/RC |
| D | RD = 15 Mb/s | LD | LD/RD |
| E | RE = 100 Mb/s | LE | LE/RE |
Suppose the server on the right is transmitting UDP at full speed to the client to the left. This is not realistic, since most datagrams will be lost. We can see this in the chart, where only 15% of the data, at best, would arrive at the client. This is protocols, such as TCP, limit transmission rates.
But what is really happening here?
100Mb are placed on link A per second. These bits are forwarded on link B at 40Mb/s. Unfortunately, this means that traffic backs up at router R1. When R1's buffers fill, packets are discarded (dropped). R1 feeds link C at 20Mb/s, but R2 forwards these packets on link D at 15Mb/s, so R2's buffers will fill quickly and R2 will start dropping packets. R3 receives on link D at 15Mb/s, and forwards on link E at 100Mb/s, so there is no incoming congestion at R3.
Notice that buffers fill and packets are discarded at R0, R1, and R2. Regardless of the congestion, the transmit times and bandwidths of the links are constant, so in no sense does any link "slow down." In practice, TCP at the sending end senses the congestion as lost packets, evidenced by a lack of acknowledgments. So, in practice, the sender slows down.