Is anyone actually USING IP QoS?
Alex P. Rudnev
alex at Relcom.EU.net
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 microsoft.com>
> To: nanog at merit.edu
> 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
> Paper: http://www.rageboy.com/stupidnet.html
> Isenberg's site: http://www.isen.com/
> Steve Riley
> Microsoft Telecommunications Practice in Denver, Colorado
> email: mailto:steriley at microsoft.com
> call: +1 303 521-4129 (cellular)
> page: +1 888 440-6249 or mailto:4406249 at skytel.com
> Applying computer technology is simply finding the right wrench to pound in
> the correct screw.
> -----Original Message-----
> From: Vadim Antonov [mailto:avg at kotovnik.com]
> Sent: Monday, May 17, 1999 12:28 PM
> To: nanog at merit.edu; pete at kruckenberg.com
> 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.
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