Thus spake "Mikael Abrahamsson" <[EMAIL PROTECTED]>
On Fri, 16 Dec 2005, Christopher L. Morrow wrote:
ah-ha! and here I thought they wanted buzzword compliance :) From what
sales/customers say it seems like they have a perception that 'qos will
let me use MORE of my too-small pipe' (or not spend as fast on more pipe)
more than anything else.
When you're running voip over a T1/E1, you really want to LLQ the
VOIP packets because VOIP doesn't like delay (not so much a
problem) nor jitter (big problem), nor packetloss (not so much a
problem if it's less than a 0.1 percent or so).
There's two problems, actually. The first is serialization delay, and
afflicts any link under about 3Mb/s regardless of utilization. Access
speeds are finally climbing past this, but for links where they haven't you
need something like MLPPP for fragmentation and interleaving.
The second is queueing delay, and that tends to only matter when average
utilization passes 58% (someone with a stat background explained why, but my
math isn't good enough to explain it). LLQ and WRED solve this well enough
for end systems to cope with the result.
So combining voip and data traffic on a link that sometimes (more often
now when windows machine have a decent TCP window) go full, even
just in a fraction of a second, means you either go QoS or do what
Skype does, crank up the jitter buffer when there is high-jitter, which
means latency for the call goes up.
Adaptive jitter buffers are old technology; Skype is hardly the first
company to use them. Most phones and softphones have them; it's the
gateways at the other end that are usually stuck with static ones.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking