QOS or more bandwidth

Tue May 29 19:14:32 UTC 2001

On Tue, 29 May 2001, Sean M. Doran wrote:

> Pete Kruckenberg <pete at kruckenberg.com> writes:
>
> | The VoIP QoS problem is interesting. Barring congestion in
> | the network, VoIP just has a problem with the fact that IP
> | communications are frame-oriented (and a VoIP packet gets
> | behind a 1536-byte Ethernet frame in the transmit queue).
>
> You *really* want to study Peter Lothberg's excellent
> queue graphs in his presentation to the Phoenix NANOG a few

Yes, been waiting...

> Speaking of Peter, I often get calls from him which
> start off with, "you know, Voice Over IP doesn't work
> without ATM, RSVP, QoS, LAN emulation, MPLS, traffic
> engineering, and fancy queueing!".  It's how I know it's
> him, when he's making a VOIP call through MAE-EAST,
> since the connection is much too _clear_ to tell by
> listening alone.

His presentation, and Steve Casner's provided empirical
evidence that there is no QoS problem to be solved, at least
in the core.

Which raises another (perhaps rhetorical) question, back to
Sean Donelan's original question: is the value/importance of
QoS inversely proportional to ability to obtain more
bandwidth (ie if funding for new bandwidth is less, is QoS
more important now).

(Most of the arguments in this thread have focused on using
more bandwidth to remove the problem that QoS might solve.)

So, what problem is QoS solving? Is QoS about ensuring that
higher-margin ("differentiated") products like VPN's aren't
impacted as much by congestion? Is it about reducing the
impact and visibility of congestion (a la WRED, and making
ICMP and Keynote measurements 'priority' services).

> I hope that helps answer your question about what
> technologies are needed to improve VOIP sound quality,
> rather than the interesting ones about directories.

A 1536-byte frame has a fairly significant impact (~8ms) at
1.5Mb/s. QoS appears to have diminishing return as you move
beyond 45Mbps, at least as far as multi-service networks go.
Maybe QoS isn't necessary or useful in the core if you have
line-speed switching and no congestion on an OC-X/DWDM
network.

But the multi-service traffic has to originate/terminate
somewhere, and it's not likely to be much faster than 2Mb/s
in most cases, at least not for a while (my 64k ISDN line is
more than adequate for email, as long as my calendar app
doesn't decide to re-sync).

There were two presentations at NANOG Phoenix showing that
there isn't a problem (as far as packet loss, jitter or
latency) in the core. It'd be interesting to see similar
studies at the distribution/access layers, where things get
a lot more interesting QoS-wise.

Interesting that there is a lot of vendor focus on QoS in
the core, where it seems to make much less sense than at the
edge.

Pete.