ecause of any fault of the provider. The problem was with the speed of the links on each end. We also discovered that the client had been having the same problem on its Frame Relay network for years. The client just figured that the links were SO slow that painful performance was to be expected. When I did some packet analysis, I discovered that the protocols in use weren't using even half of the available link. Why, then, were they reporting bad performance? The problem most people encounter when trying to grasp the concept of traffic shaping is a misunderstanding of how serial links work. Let's talk T1 versus DS3 for a bit. A DS3 is not a bigger pipe, as SO many of us like to say. It is, instead, a faster link. We constantly reinforce the misconception that a DS3 is bigger than a T1, because we say things like, "A DS3 contains 28 T1s." That's true, but many people, especially execu- tives, believe that the image in Figure 31-8 is representative of the difference, when it is not. This is further exacerbated by the constant misuse of the word bandwidth. Yes, I do this myself throughout the book. Why? Because I'm a creature of habit and for over 25 years we've all said that we need more bandwidth, when what we need is throughput. If I tell an exec we need more throughput than the T1 can deliver, he'll ask me to explain. If I say we need more bandwidth, he'll ask me how much it will cost, and I'll get out of his office that much faster. QoS Mechanics Figure 31-8. Faster links are not bigger links Multiple T1s fit within a DS3 because of multiplexing. A DS3 still sends bits one at a time, as does an OC3 and an OC192. Faster links send bits, well, faster. Figure 31-9 shows a representation (not to scale) of the difference between a DS3, a T1, and a 256k fractional T1. Notice that they're all serial links. They all send bits one at a time. The DS3 just sends them faster. If a DS3 sends bits this fast: 11111111111111111111111111111111111111111111111111111111111111111111111111111111 Then a T1 sends bits this fast: And a