Re: Reg: Quality of Service routing

Antoni Przygienda <> Tue, 22 December 1998 01:15 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id UAA14780 for <>; Mon, 21 Dec 1998 20:15:37 -0500 (EST)
Received: (from smtpd@localhost) by (8.8.8/8.6.12) id PAA08219 for; Mon, 21 Dec 1998 15:59:47 -0500 (EST)
Received: from, claiming to be "" via SMTP by, id smtpdIRBa14031; Mon Dec 21 15:20:50 1998
Received: from by with ESMTP; Mon, 21 Dec 1998 15:06:24 -0500
Received: (from majordom@localhost) by (8.8.8/8.8.8) id OAA23433 for qosr-outgoing; Mon, 21 Dec 1998 14:51:14 -0500 (EST)
Received: from ( []) by (8.8.8/8.8.8) with SMTP id VAA08505 for <qosr@qmaster>; Sun, 20 Dec 1998 21:30:23 -0500 (EST)
Received: from by (SMI-8.6/SMI-SVR4) id VAA06883; Sun, 20 Dec 1998 21:30:20 -0500
Received: from [] by with ESMTP; Sun, 20 Dec 1998 21:30:03 -0500
Received: (from smtpd@localhost) by (8.8.8/8.6.12) id VAA24788 for; Sun, 20 Dec 1998 21:20:06 -0500 (EST)
Received: from via SMTP by, id smtpdAAAa24770; Sun Dec 20 21:20:02 1998
Received: from ([]) by dirty; Sun Dec 20 21:19:33 EST 1998
Received: from (root@prz-home []) by (8.8.8/8.8.8) with ESMTP id VAA28931; Sun, 20 Dec 1998 21:19:30 -0500 (EST)
Message-Id: <>
Date: Sun, 20 Dec 1998 21:10:26 -0500
From: Antoni Przygienda <>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.0.33 i586)
To: Masilamany Raguparan <>
CC: "Raghu V.V.J Vadapalli" <>, routing quality <>, Internet Protocol <>, MultiProtocol Label Switching <>
Subject: Re: Reg: Quality of Service routing
References: <Pine.GSO.4.02.9812210819550.26497-100000@fireball>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Content-Transfer-Encoding: 7bit

Masilamany Raguparan wrote:
> Raghu,
> | Do we need QoS routing if we have enough infinite (I mean
> | large ) bandwidth.
> |
> | >From my poor knowledge:
> |
> | We need QoS routing b'cos we have limited BW and we want
> | to give priority to QoS flows. If some one comes with
> | a Tx system which supports 100s Gb/s,(say 128 channel WDM system)
> | Do we need to support the "special"  status for the QoS flows.
> Nature of the traffic can be very bursty and suck up your 100s of Gb/s
> bandwidth easily at any given time slot. Therefore, having just large bit
> pipes does not solve the QoS problem.
> Your delay = propagation time + queuing time + processing time equation
> certainly works, if you have enough capacity left on the link at the time
> of your request.

Let me bring the economical and philosophical component into this
that I tried not to touch so far but probably needs being spelled out:

1. Any amount of bandwidth can be thrown at the problem. 100 Gb/s on
transmission media
	and beyond are not a dream but as CPU, bus & memory technologies taught
	matter of years at most. 
2. CPU problems, memory bandwidths, complicated lookups,
per-flow-queining in ASICs and other 
	"traditional-router" problems that QMA brings up can be solved based on 
	the fact that "pigs with enough thrust fly
	just fine" (Ross) and made ATM such a hard sell. Thrust being here on
one hand 
	IP being open and amazingly scalable (with hacks of course ;-)
	on the other hand the expected (and for some companies already real)
	revenues from networking and on the third hand progress in ASIC
3. Any amount of a free (or perceived as free) resource on this planet 
	has or is being depleted
	if it has any value. why is a question that has seemingly simple
answers but can
	run very deep. I highly recommend 
	Therefore I believe that we'll always face congestion in today's model
of the 
	Internet, no matter how much bandwidth you are willing to throw at the

Which leads to the core of what I try to say: QoS routing is just one
possible mechanism
how to provide certain guarantees about certain resources to the user.
What the resources
are and what other mechanisms could be used (network engineering or
shaping, CAC and others exist) depends on the pricing model which is
basically a function 
you try to optimize on. Since pricing in the Internet today is basically
flat at 
the end-user level, there is little or no incentive to provide
guarantees and therefore 
deploy something along the lines of QoS routing. Given a different
pricing (and an according
billing, that's of course the tough part ;-), different mechanisms could
necessary and being deployed. The picture is particularly twisted IMHO
since lots of things 
you'd want to do are not necessarily
what is possible (or being perceived as possible) from the technological
perspective and 
therefore widely different perceptions of what reality of data
networking on the scale of 
the planet should be clash in entertaining fireworks onto each other in
recent years.

I hope that unifies or at least spells out lots of implicit assumptions
that I sensed in 
the different mails sent to this thread ...

		thank you

		--- tony