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: http://www.rageboy.com/stupidnet.html
Isenberg's site: http://www.isen.com/
It's amazing that people continue to spout this "bandwidth is free" notion over
and over again. Based upon economics, could someone please explain to me how
service providers can run a business by giving away bandwidth?
I work at a small networking startup, with a moderate speed connection to the
Internet. If bandwidth was essentially free, our company would have an OC48c
connection to the service provider. Our company would perform all of its backups
over the network to an offsite data center. I would be downloading movies from a
new "electronic online video rental" company so I could watch it at home (until
my home received an OC48c and I streamed it directly). I would install cameras
at home that I can login into from work and watch constantly as a security
measure. Using these simple examples, I estimate that I could easily consume
several Mbps on average. So could everyone else. Is bandwidth still so plentiful
that it could be given away and QoS is not needed?
Let's compare bandwidth to another product that is getting cheaper: PCs. PCs
continually offer much better performance at the same price, but are not free.
The "free PCs" model is simply a way of offsetting the cost to another party
that sees value in getting captive long-term clients. The PC maker still gets
paid.
Likewise, bandwidth will continue to cheaper, but will not be free. As with
PCs, the cost of bandwidth may be offset by a third party, but that is not
"free bandwidth". The service provider still gets paid. How much depends upon
factors like the QoS, the bandwidth, and the service availability.
Well paid (read profitable) service providers are good for all of us. This
includes the end customers, who need a service provider that can investment in
good facilities, equipment, and most of all, talented people to run the network.
Prabhu
"Steve Riley (MCS)" wrote:
One big problem with QoS is that most application programmer have no
clue as to how to specify QoS related parameters. A few years ago, when
I put on my application programmer's hat [pretending I had an MPEG-1
stream to pump out] and looked at the ATM UNI 3.0 specification, I found
that (a) I could not really understand the meaning of roughly 1/4 of the
parameters and (b) for many of the parameters I understood, I was not at
all sure what were the appropriate values to use.
In general, most of the multi-media stuff uses some sort of compression
algorithm. Unless one have a good understanding of the nitty gritty of
the algorithm, one would be somewhat hard pressed to set values. For
pre-generated pre-compressed material, one can at least run the material
once and monitor its network characteristic. However, translating those
characteristic to jitter control parameters is still non-trivial. With
real time compression, the challenge is much trickier.
So, if the application programmers have a hard time specifying QoS
......
Non application based QoS may be more practical. Hence if I pay for a
3Mbps service from my ISP, I want to ensure that I can get 3Mbps from my
end of the pipe to any edge of the ISPs backbone. I will be a bit
annoyed if the 3Mbps is only between my end of the pipe to a totally
over subscribed and under provisioned POP! If my ISP have a real
meaningful SLA with me, I suspect they will being doing real traffic
engineering in their access and backbone routers to support the
contracted QoS. That could be relatively straight forward as long as
the QoS parameters are not too funky (definitely no mention of jitter).
Another related type of QoS that is more practical and likely to be done
is relative QoS in the form of if I have a 3Mbps pipe to the ISP, the
CEO is going to get preferential service to the mail room clerk etc.
Such QoS does not seem to be too complex to do at the CPE edge router,
again, as long as one does not try to get too fancy and as long as it is
relative.
Regards,
John Leong
You are merely showing your geocentricism by saying that bandwidth is
essentially free. That may be true in the USA but not in other countries
and especially not trans-Pacific or trans-Atlantic. T3 from NY-Chicago
goes for around $20K/month. T3 from London to NY goes for around
$100K/month. T3 from Tel-Aviv to NY goes for around $300K/month. T3
Tokyo-LA goes for $400K/month (all prices for fiber on a one year
contract). I would agree that at $20K/month you could build possible
business models that turn the cost of the b/w to be part of the costs you
eat and in turn provide b/w free of charge to your users.
But at $300-$400K/month it ain't gonna work ($20K/month gets one an almost
E1 from Europe to the USA - whereas in the USA it gets you a T3). Go to
www.band-x.com to see what current circuits cost.
Once int'l bandwidth costs drop to the rates of USA national rates, then I
would be inclined to agree with you and Vadim that QoS is not needed.
Clearly today, IP QoS is not needed at the campus level.
-Hank
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
Internet.
In addition. Months ago I'v asked about RSVP in Nanog. I'v get 1 (one)
answer - just from the Russia - _we use it over one our link_. -
"Steve Riley (MCS)" wrote:
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.
And of course, since you seem to have discovered the deal of the
century, exactly who are you getting all of this free bandwidth from?
Maybe you're living in the same universe as Larry Ellison. The *idea*
of QoS works for lower-bandwidth connections in remote locations, or for
economically challenged installations. The fact that the
*implementations* of QoS don't solve this problem is merely a reflection
of marketing outweighing research and development. The fact is, we may
never get good IP QoS, but to reason that the idea is foolish because
bandwidth is free is clearly not rational.
You are merely showing your geocentricism by saying that bandwidth is
essentially free. That may be true in the USA but not in other countries
It depends. It's not free yet for us (in Russia).
But we are talking about two tendencies. One are decreasing of bandwidths
charges. Other is the quality of protocols (such as RSVP and multicast's
applications) - now this is not usable issues yet.
Guess what happen first - this issues will be realised by the proper way,
or charges decrease to the values when RSVP and coimplex QoS mechanisms
have not any importance?
Once int'l bandwidth costs drop to the rates of USA national rates, then I
would be inclined to agree with you and Vadim that QoS is not needed.
Clearly today, IP QoS is not needed at the campus level.
-Hank
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)
If you have an OC-48, someone will find a way to Smurf it and then you
will need QoS at the ICMP level (CAR?). I believe that no matter how
unlimited your b/w will be you will always need some modicum of QoS.
-Hank
It's just what I am saying - some technologies (as CAR) are used widely,
some with the troubles (traffic-shaping, for example), some are dead
(RSVP).
Through - SMURF by OS-48? Let's the enemy try - OS-48 will not notice it
at all. You can't generate such traffic by the simple way.
Anyway, no one answer to the initial question. I guess no one here use
complex QoS features, except primitive (CAR, RED, WFQ) ones.
Alex.