Is anyone actually USING IP QoS?

Alex P. Rudnev alex at
Tue May 18 09:17:09 UTC 1999

I must agree and disagree. RSVP is dead protocol - it's enougph to 
imagine how different ISP can negotoate about RSVP service, and (in 
addition) read RSVP protocol itself...

On the other hand, why don't provide QoS in the non-overbooked network. 
It's not difficult to install PRECEDENCE queue-control, just as negotiate 
about some classes of service, to prevent short network bursts from 
disturbing multimedia streams.

I'd like to ask one more question. Multicast, 

If we project multimedia services from the scratsch, you have a few 
different choices. For example, you have RealVideo server. I ask you 
abgour RV stream. Ok, you send packets with DST=MY_ADDRESS.

Then someone else send second request. Why (WHY) can't RV server add 
second DST address into the packet? Why can't you use the same, unicast, 
address space for multicast services.

I mean - first way was (was) to use existing address space for multicast 
multimedia, and add some mechanism (such as replicators) to hide the 
mechanisms from the end user. No one bother if some RV-CACHE server catch 
his request and use his own replicator to organise multidemia stream.

Second way was choosen - to use another address space for the multimedia 
multicasting. Result - you see - Internet have not (HAVE NOT) multimedia 
multicast at all. No, some ISP have internal multicast networks, but not 
more. If I ask CNN abour RV live stream, and you ask the same, be sure - 
the server send just 2 different packets - one for you and one for me...

And this is very serious obstacle against multimedia services in the 
Internet. Not QoS (through QoS prevent using existing public networks 
from the commercial telephony), but tjis absence of mukticasting in the 

On Mon, 17 May 1999, Steve Riley (MCS) wrote:

> Date: Mon, 17 May 1999 14:04:37 -0700
> From: Steve Riley (MCS) <steriley at>
> To: nanog at
> Subject: RE: Is anyone actually USING IP QoS?
> Nice to see that I'm not the only one believing in the foolishness of QoS
> hype. Bandwidth is essentially free, and will always be cheaper than QoS.
> And since in the end nearly all decisions are based on economics, it should
> be apparent which is the more logical decision.
> Allow me to point you to an interesting paper called "Rise of the Stupid
> Network." Many of you here may have already seen this. It was written back
> in 1997 by David Isenberg, then a reasearcher at AT&T Labs (Isenberg is now
> an independent consultant). His paper profoundly changed my views on QoS and
> made me realize that networks perform best when we limit how smart they get
> and ensure that networks focus on transport only. I urge everyone to read
> it.
> Paper:
> Isenberg's site:
> _________________________________________________________
> Steve Riley
> Microsoft Telecommunications Practice in Denver, Colorado
>     email: mailto:steriley at
>     call: +1 303 521-4129 (cellular)
>     page: +1 888 440-6249 or mailto:4406249 at
> Applying computer technology is simply finding the right wrench to pound in
> the correct screw.
> -----Original Message-----
> From: Vadim Antonov [mailto:avg at]
> Sent: Monday, May 17, 1999 12:28 PM
> To: nanog at; pete at
> Subject: Re: Is anyone actually USING IP QoS?
> Yep.  Altough not _all_ QoS schemes are broken-as-designed.  The
> most trivial per-packet priority combined with ingress
> priority mix shaping works.  Ths idea of end-to-end
> whatever reservations or guarantees is usually propounded
> by people who either neglected their CS courses or those
> who are trying to sell it.
> Yep.  The biggest QoS secret is that nobody actually needs
> it.  Bandwidth is cheap and is growing cheaper.  The
> manpower needed to deploy and maintain QoS is getting
> more and more expensive.
> --vadim

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

More information about the NANOG mailing list