Subject: Re: QOS Routing - high level comments (long)

From: [email-masked] (Noel Chiappa)
Date: Sat, 6 Apr 96 11:03:55 -0500

From: Steve Deering <[email-masked]>

    voice service can be made adaptable to bandwidth degradation, by
    progressively aggressive compression

First, do note that I said "these are the best arguments I heard for the other
side", not "I think these arguments are conclusive". I've heard a long list of
arguments for and against resource reservation, and I thought a lot of them
were not very strong, on both sides. I simply recounted some of the ones that
had seemed to me to be most valid.

I don't yet have any definite conclusion after listening to both sides, but I
am wondering if the world can get by with nothing but a best-effort packet
net; i.e. run all voice, etc on top of that. Perhaps we will continue on with
the current model; i.e. a best-effort packet net built on top of a circuit
network, with the latter being used to carry voice, etc.

Second, as to the specific example of voice, I'm not a voice expert. However,
I would imagine the following process is about what voice providers would go
through. First, they'd do a lot of human factors studies to figure out what
users will accept in the way of S/N, delay, echo, etc, etc (I gather most
phone companies have already done this), and what kind of degradation curve
they will take (i.e. what % of the time measure X falls below Y, for various
Y).

Then, they sit down and use theory/modelling/experiment to figure out what
degree of overprovisioning would be needed in a pure datagram net (perhaps
enhanced with charging-based priority, and some other simple enhancements,
including of course some sort of fair queueing algorithm) to meet those
service quality curves.

You also need to develop models of what the traffic loads are going to look
like (i.e. how much voice, how much data, etc), as well as engineering plans
for a number of options. At that point, you can cost out three different
approaches: i) a best-effort service pure packet net, over-provisioned to
allow real-time service that meets your needs; ii) a pure packet net, with
resource reservation, and somewhat less resources; and iii) a hybrid network
in which different infrastructures are used to support different services
(i.e. the current model).

It would seem to me that all three would meet the service requirements, but
I'm not sure a "back of the envelope" look at the problem is going to tell
you which is the most cost-effective way to do it. Am I missing something?

	Noel

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 06 Apr 1996 18:08:18 +0100

this discussion sure is confused - and the subject line is offbeam
(the original questions were good though!)

the internet _has_ QoS routing - we have multi-metric routing
algorithms which can calculate a path for data according to a QoS
requirement - what we don't have (and noone does) include:

i) a good set of algorithms for
factoring in current and requested future
workload adaptively to the distributed route
calculation without causing route oscillations 

ii) a way of allowing routes to change for current traffic with a QoS
guarantees requirement more than best effort
without a hiatus during which guarantees are lost (though traffic
isn't)

however, with WFQ, or HRR, you can make guarantees, and with
management, we could lock/pin routes (whether we're using RSVP or not)
and have something that is crippled like most circuit based nets.....

we could move forward from the current system as the PNNI people are
observing, and deal with i) quite easily - ii) is something not
avaialble to ATM without some _very_ hard thinking, becvause of the
arbitrary design decision in ATM to impose ordering requirements 
on cell delivery  - if you have an allowable CDV, why can't you
re-order cells, i ask - if you can re-order, then you can re-route
(more easily, at least, than if you want to hae dynamic distributed
adaptive (re-)routing)

in IP, we have the opposite problem of ATM _ this is the core problem
with soft state versus hard circuits - soft stae lets you re-route
with momentary loss of guarantee, while hard state lets you make the
guarantee, but makes re-routing harder....

the trick is going to be to develope algorithms so we can meet in the
middle - let ATM re-route and let IP (with int-serv guarantees,
whether via RSVP or management) re-route without shame

actually, the algorithms for (i) are quite hard too, tough zheng wang
and i (and others - jed referred to a few) have got some ways towards
some solutions - basically, dynamic QoS routing for _delay_ is a bad bad bad
idea - you should QoS route based on propgation delay, and admit based
on capacity   - QoS routing for bandwidth is probably easy enough
as long as flows that need capacity guarantees are long lived compared
with the routing calcualtion intervals....which may not always be
true...

in the end, over-engineering the net is a more attractive policy, but
there are daft political and short term economcc barriers, so i think
we need to solve i) and ii) pretty soon...

at least this is a technical discussion - good stuff everyone!!!
jon