Cisco’s slightly-outdated QoS SRND (http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf) refers to slow, medium, and fast-speed links.
What’s the distinction? Why is anything less than 768kbps considered “slow”?
Well, one of the large ones is serialization delay. This is somewhat covered in the SRND, but I wanted to highlight some of the key reasonings behind the distinction, as they’re applicable regardless of how you define “slow.”
Slow links suck, on that everyone can agree, but for real-time traffic –voice and interactive-video, for example– they suck even more than only being able to torrent at 80 KB/s.
First, a few constants, some of which influence the “slow” characterization moreso than others, and are specified for informational purposes only:
Well-designed VoIP expects a one-way delay — mouth of speaker to ear of receiver — of approx 150ms. This is largely going to be a function of processing and propagation delays along the link; as link speeds increase, the effects of serialization delay on the total delay budget are reduced.
Second, standard G.729 codec specifies 10ms of voice per frame. Cisco IP phones pack two G.729 frames into each VoIP packet, for a total of 20ms of voice carried per packet; I’m focusing exclusively on the G.729 codec as it is the de-facto standard for VoIP over the WAN, due to its compression algorithm producing an 8kbps voice stream –before IP overhead is taken into account– compared to the 64kbps of G.711.
G.729 codecs can compensate for approx. 30ms of lost voice. Given that a single VoIP packet contains 20ms, a loss of two consecutive VoIP packets (40ms worth of voice) will be noticed by the receiver. Naturally you want to avoid losses, but moreso in a real-time voice environment than any other. This is what Low-Latency Queuing is for, but it will not be the focus of this note.
Third, IP phones expect a relatively constant stream of voice packets. Non-constant delays experienced along the path produce jitter; if one packet takes 160ms to get to the receiver, and the following packet takes 170ms, the stream has experienced 10ms of jitter. DSPs in IP phones can compensate for approx 40ms of jitter by buffering received packets and replaying them to the receiver at a constant rate. For this reason, you always want to have packets falling in the window of the jitter buffer (20ms to 50ms is a decent target for the IP phones I’ve read about).
So, given the above, what makes a 768kbps link slow?
Well, you want to stay within the jitter-buffer window, which means approx 30ms of jitter. Cisco’s speed characterization is based on the assumption of 10ms of jitter per hop.
If we take one extreme, a link that carries a single voice call experiences very low jitter, as there is extremely low delay between voice packets :
———-[voice][voice][voice] ———–>
But what happens when you throw a large data, unfragmented data packet into the mix?
———-[voice][------Data Payload-----][voice] ———–>
If that data packet is 1500 bytes, and the line speed is 768kbbps, it takes 15ms to clock that packet onto the physical line (warning: math!):
(1500*8) = 12000 bits/data-packet
12kb / 768kbps = 15.625ms
Thus, the 2nd voice packet in the stream experiences over 15ms of jitter. This is fine if you have a site-to-site WAN link, but less fine if your voice path transits multiple routers, as it significantly impacts your jitter and delay budget.
Remember, these numbers are based on Cisco’s assumptions. If you can get within ~30ms jitter while going through a single slow link and multiple extremely fast links (with very little serialization delay), then the number of routers you transit becomes less of a concern; whereas Cisco’s numbers are based on a three-hop path experiencing 10ms of jitter per hop.
The important thing to take away is that you want to stay within the window, and that at low speeds, serialization delays profoundly impact your jitter budget. See the following spreadsheet for reference:
| Packet Size | |||||||||
| Bandwidth | 20 | 40 | 80 | 128 | 256 | 512 | 1024 | 1200 | 1500 |
| 56 | 2.86 | 5.71 | 11.43 | 18.29 | 36.57 | 73.14 | 146.29 | 171.43 | 214.29 |
| 128 | 1.25 | 2.50 | 5.00 | 8.00 | 16.00 | 32.00 | 64.00 | 75.00 | 93.75 |
| 256 | 0.63 | 1.25 | 2.50 | 4.00 | 8.00 | 16.00 | 32.00 | 37.50 | 46.88 |
| 512 | 0.31 | 0.63 | 1.25 | 2.00 | 4.00 | 8.00 | 16.00 | 18.75 | 23.44 |
| 768 | 0.21 | 0.42 | 0.83 | 1.33 | 2.67 | 5.33 | 10.67 | 12.50 | 15.63 |
| 1024 | 0.16 | 0.31 | 0.63 | 1.00 | 2.00 | 4.00 | 8.00 | 9.38 | 11.72 |
| 1544 | 0.10 | 0.21 | 0.41 | 0.66 | 1.33 | 2.65 | 5.31 | 6.22 | 7.77 |
| 4632 | 0.03 | 0.07 | 0.14 | 0.22 | 0.44 | 0.88 | 1.77 | 2.07 | 2.59 |
| 10000 | 0.02 | 0.03 | 0.06 | 0.10 | 0.20 | 0.41 | 0.82 | 0.96 | 1.20 |
| 100000 | 0.00 | 0.00 | 0.01 | 0.01 | 0.02 | 0.04 | 0.08 | 0.10 | 0.12 |
| 1000000 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.01 | 0.01 | 0.01 |
| 10000000 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
Note that above 768kbps, the influence of serialization delays on the links can only get better than 15ms, regardless of packet size; at these speeds, serialization delays become less of a concern.
There are a few things you can do to overcome the serialization limitations imposed by slow-speed links, and there are good reason why [some of] these same techniques should NOT be employed on high-speed links; these will be covered in a future note.
Right now, I’ve got a buddy’s 30th birthday to attend and I plan on getting drunk enough to forget most of this.
