Subject: Re: Reg: Quality of Service routing

From: Roch Guerin <[email-masked]>
Date: Sun, 20 Dec 1998 12:11:40 -0500

Raghu V.V.J Vadapalli wrote:

> Dear All,
>
> I have one basic question regarding QoS routing.
>
> 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.
> May in that case the memory at the routers will be
> bottleneck.

Besides the delay issue that Tony mentions, you should also consider
that tx bandwidth is not the only resource inolved in delivering your
data.  You also need switches/routers that can keep up with the
bandwidth, and if they don't they are the resource you need to focus on,
i.e., you need to consider the forwarding tput available rather than
just the raw bandwidth.

Roch

---

From: Masilamany Raguparan <[email-masked]>
Date: Mon, 21 Dec 1998 08:28:24 +0800 (SGT)

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.

| May in that case the memory at the routers will be
| bottleneck. 

This problem is well addressed in the previous answers from Roch & others

Ragu.

---

From: Parag M Panse <[email-masked]>
Date: Mon, 21 Dec 1998 00:11:11 -0600 (CST)

> certainly works, if you have enough capacity left on the link at the time

An implicit assumption that seems to be made here is regarding 'number of
data sources'. 

While designing a system that guarantees certain values of BW and 
end-2-end delay, given the present Internet model no  assumption can be 
made about the number of users or the number of sources geneating data.
Since no upper bound can be placed on the value of this parameter, even
though links with 100Gbps (or higher) , faster CPUs and faster memories
are given eventually the 'number of users' will always catch up and so
the "queueing delay" factor mentioned in the above equation for delay can
be never be eliminated. In fact as the number of users grow, the factor
will become more dominant. So it would be incorrect to say that delay ~
propagation time. 

> Ragu.

Regards...

-Parag

---

From: Roch Guerin <[email-masked]>
Date: Sun, 20 Dec 1998 12:11:40 -0500

Roch

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 21 Dec 1998 12:14:37 -0600

> large) bandwidth.

One can't take the word "inifinite" literally and still try to give a
sensible answer.

What bandwidth would truly be "sufficiently large" that you would
never need to consider the need to give some traffic preference over
other?  That would be the case if every link and switching device in
the network had sufficient capacity to carry all the traffic that
could conceivably directed through it by the concerted action of all
the end nodes.

Do you still want to pursue the question under those terms?  I don't.
______________________________________________________________________________
Matt Crawford                    [email-masked]                     Fermilab
"A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment,
thoroughly smash them with a hammer or an ax, and scatter the pieces."

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 20 Dec 1998 10:41:07 -0500

Raghu V.V.J Vadapalli wrote:
> Am I missing something.
> With Regards
> -Raghu.

I am not aware that you can generally trade bandwidth for delay 
(said simply: if you have end-2-end delay constraints to meet & sum of 
your link propagation delays exceeds it, there is little you can do)  
so having arbitrary amounts 
of bandwidth does not necessarily solve the end-2-end delay problem. 

			thank you

			--- tony

---

From: "Raghu V.V.J Vadapalli" <[email-masked]>
Date: Sun, 20 Dec 1998 07:05:34 -0800 (PST)

Dear All,

From my poor knowledge:

Am I missing something. 
With Regards
-Raghu.

==
------------------------------------------------------------

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Bala Rajagopalan <[email-masked]>
Date: Sun, 20 Dec 1998 23:49:00 +0000

> i.e., you need to consider the forwarding tput available rather than

I'd assume that if abundant bw is available then the routers will
also be big and obese. 

but I don't believe (or at least like to believe) in the premise that a
network can be economically maintained at low utilizations all the time 
thus obviating need for proper engineering and intelligent routing. 

regards,

Bala

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 21 Dec 1998 18:19:21 +0000 (GMT)

On Mon, 21 Dec 1998, Parag M Panse wrote:

> > | From my poor knowledge:
> > | 

A second assumption is that this is appropriate to all the lists it's
being cc'd to.

Followups set to qosr only; give those of us subscribed to all the
lists a break.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: [email-masked] (Daniel Awduche)
Date: Mon, 21 Dec 1998 00:38:54 -0500 (EST)

Tony P. has captured the basic issues very nicely. 

The fundamental problem is that of resource management. 
Specifically, the controlled mapping of traffic onto network 
elements to achieve desired performance objectives. The
Internet being an economic system, the problem of resource
management will persist even as technology and terminology
evolve.

Constraint based routing (of which QoS routing is a subset),
allows the mapping of traffic onto network assets to be effected 
in a controlled fashion. Diffserv provides additional mechanisms 
for localized control.

In general, cost structure, revenue model, competition, and
other miscellaneous factors will impact optimization policy.

Even if bandwidth becomes cheap and plentiful, and we suppose 
no imaginative entrepreneurs exist to create new services that 
exploit this abundance (thereby creating a new cycle of demand), 
the issue of effectiveness concerning resource management will 
remain a significant aspect for many ISPs who must derive a 
return on their investment in infrastructure.

/Dan.

Antoni Przygienda said:
> 
> Let me bring the economical and philosophical component into this
> discussion 
> 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
> us, 
> 	matter of years at most.

---

From: Qingming Ma <[email-masked]>
Date: Sun, 20 Dec 1998 12:49:00 -0600

I agree with Roch. Router packet pool memory and CPU cycles can often
become bottleneck in certain scenarios, especially when packet
forwarding 
is done by software. One probably should never expect that there are 
sufficient memory and CPU cycles, since keeping adding new QoS features 
(e.g., classifying, scheduling, admission, reservation, policy
enforcing, 
access control, ...) will consume more and more CPU resources.   

Let us assume that router CPU is never the bottleneck. Even with
sufficient
large amount of bandwidth, we may still need QoS routing, unless one
can ensure that the traffic load is always below the link capacity and 
the network rarely gets congested. One common belief is that QoS is only
needed when the load of QoS traffic is heavy, so that we can reduce the
number of requests being blocked. However, QoS routing is still useful 
even when the QoS traffic load is light. For example, when the load of 
best effort traffic is heavy and conentrated on some hot links, although 
call blocking rate for QoS traffic is not an issue, but encourage QoS
traffic 
to use the links with relatively light load of best effort traffic can 
improve over all throughput for best effort traffic.   

Qingming

Roch Guerin wrote:
>   ------------------------------------------------------------------------
>                    Name: vcard.vcf
>    vcard.vcf       Type: VCard (text/x-vcard)
>                Encoding: 7bit
>             Description: Card for Roch Guerin

---

From: Richard Carlson <[email-masked]>
Date: Mon, 21 Dec 1998 13:10:04 -0600

Raghu;

This is a very interesting and important question that I don't think gets
the attention it deserves.  As has been pointed out in other replies to
your question, the cost of providing 'enough' forwarding capabilities
(switch/routers, link BW, etc) to prevent packet queuing will be high.  The
unstated (and I believe suspect) assumption is that the cost of providing
QoS mechanisms will be lower.  I don't think enough research has been done
to identify and classify the real costs of deploying a QoS based Internet.

By real costs I mean those charges that are required to build a workable
global system.  Some simple examples are:

* authentication, can I prove who I am and that I have the authority to
request this service?

* non-repudiation, can you prove it was really me so you can counter my
claim that I never used this service?

* charging, who pays for traffic in the non-symmetric data world where the
web server is the 'source' and the client is the 'sink' for data streams.

* cross domain charging, how do service providers pass charges to each
other and finally back to the customer.

* equipment requirements, how much will equipment (switches/routers,
computers) cost when they need to keep track of all the accounting
information.

I am not trying to say that any one of these issues is expensive by itself,
but that the combination of all the components needed to build a workable
global QoS Internet must be addressed.  Only then can a fair comparison be
made to determine what the best answer is.

Looking at the total picture, I begin to view the technical solution of
just throwing more packet forwarding capability (faster switches/router,
links, DWDM muxes, etc.) as very attractive.  The costs for the technology
will only come down.  Indead, look at the new terabit routers now being
worked on, wire speed forwarding engines at gigabit speeds in campus
switch/routers, and optical networks using NxOC-192 DWDMs.  All of these
technologies tend to decrease in price as time increases.  In contrast, who
knows what the administrative costs will be and how they will change over
time?

Building a high quality Internet will not be an easy task.  Right now I
think it is to early to tell if technological growth or administrative
constraint is the solution to this interesting problem.

Rich

> May in that case the memory at the routers will be
------------------------------------

Richard A. Carlson			email: [email-masked]
US Dept of Energy ER-31      		Phone: (301) 903-0073
19901 Germantown Rd			Fax:   (301) 903-7774
Germantown, MD 20874

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 20 Dec 1998 21:10:26 -0500

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
us, 
	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 ;-)
technology, 
	on the other hand the expected (and for some companies already real)
significant
	revenues from networking and on the third hand progress in ASIC
technology. 
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 http://pespmc1.vub.ac.be/Default.html 
	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
problem. 

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
over-engineering, 
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
be 
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