 256k links sends bits this fast: Figure 31-9. Speed of bits over different links The problem in this case had to do with the fact that the branches could only receive bits at 256 thousand bits per second, while the main office was sending them at million bits per second. The cloud was SO efficient that it delivered the bits at 45 Mbps right up until the provider end of the branch's 256 Kbps link, where the buffers would then become overrun (Figure 31-10). Bits sent out this fast from a DS3 cannot be received any faster than this on a T1 11111111111111111111 Figure 31-10. Speed difference between two links The key here was buffers. The device at the provider end of the branch's fractional T1 link would buffer the packets, but the main office was sending bits SO fast that the provider's router sending bits to the branch couldn't buffer all of them (Figure 31-11). Chapter 31: Introduction to QoS 11111111111111111111 1111111111 Interface Queue Figure 31-11. Too many bits in buffer-bits get dropped This is not a link oversubscription issue. Utilization rarely exceeded 50 percent, yet packet loss was severe. This buffer problem was something we called microbursting, since the issue started and stopped SO quickly that the bandwidth reports never showed it. This problem is also not limited to Frame Relay. It can occur anytime there is a large discrepancy in the speed of the links connecting two sites. This usually happens multipoint or mesh topologies such as Frame Relay or MPLS, where there are one more hub locations on the network that the rest of the network must access. As you'll see in the next chapter, it was easy to fix in a Frame Relay environment because of the virtual circuits used in the design. Luckily, there was a way to solve our problem: traffic shaping. With traffic shaping, we used the main office router to queue the bits being sent to each branch. We then sent those bits out at a speed that the far end could accept. We did this by inserting the bits into the DS3's data stream at a predetermined interva