Subject: Re: QOS Routing

From: [email-masked] (Noel Chiappa)
Date: Wed, 10 Apr 96 11:10:53 -0400

From: Jon Crowcroft <[email-masked]>

    routing that includes current traffic conditions in the advertisements

Err, I'm not sure this is the way to go, i.e. flood information about current
load levels. It's an argument based on fundamentals of information flow, and
to a lesser extent, of routing (the latter depending on your basic routing
architecture).

Basically, too much overhead goes on sending information about current loads
to people who have no use for it. In addition, in a network of any size, if
you're using a distributed path calculation, you're going to be having
problems with stabilization.

Rather than a flood model, I think the right thing to do is more of a demand
model; i.e. you find out about traffic levels when you decide to use a path.
This works fine with a Map Distribution system (e.g. PNNI, etc), since what
you flood is the basic topology (which changes slowly). If you're using a
resource reservation system, you can kill two birds with one stone; the
exchange that reserves resources also is an implicit load query.

Note that this approach sort of assumes that the load is not changing very
quickly; if you have load fluctuations on the scale of less than an RTT, the
load info is stale by the time you have it. Of course, if the load is changing
that fast, no approach will really work.

(Interestingly, this may be another fundamental argument for resource
reservation; if best-effort loads fluctuate very quickly, VJCC and similar
closed-loop systems may not be able to respond quickly. But let's stay out
of that rathole.)

    it might be nice to actually advertise conditions so that the next stage
    can evolve...

There's obviously a balance between flooding info about congestion, and
letting people find it out by enquiry. If you have only a few failures,
there's less total overhead to do it the latter way. If you have lots, then
there's less total overhead the former. (It's more expensive than the latter,
but it's only done once).

You have to do a cost/benefit analysis, which is "will the overhead of
flooding this information be larger than the benefits of having it on hand,
as opposed to the alternative of getting load info on demand, as a piggyback
on reservation". My intuition says that answer is probably "no".

    alternate paths (i.e. overflow paths) routing, where not only do we
    advertise the metrics, and the metrics include the current traffic
    conditions, but we also can route (and reroute) traffic to load balance
    the net.....

Stability becomes an issue; you can get load oscillations as traffic chases
its own tail.

This provides, of course, yet another advantage to an explicit-route/
resource-reservation model: once you've set up a flow, it won't chase around
the network. There's still some obscure feedback loop my brain won't cough
up, but the situation is generally much improved.

	Noel

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 10 Apr 1996 16:28:58 +0100

>problems with stabilization.

given we're assuming this all nly makes sense for long lived flows,
then surely we can send around aggreagate information.....?then isn't
flooding it going to be reasoanble.....if the average number of flows
doesn't change a lot, but the rate of arrival of new flows warrants a
search, wouldn't having the information to hand for alternate routing
be more efficient?

i'm happy to be pursuaded otherwise tho...

cheers
jon

---

From: [email-masked] (Bala Rajagopalan)
Date: Wed, 10 Apr 1996 12:04:31 -0400

On Apr 10,  4:28pm, Jon Crowcroft wrote:
> Subject: Re: QOS Routing

>-- End of excerpt from Jon Crowcroft

Actually, you don't have to flood information. You may use
an efficient tree-based broadcast. Like you point out,
the frequency of update generation can also be reduced a lot
by quantizing the information coarsely. Anyway, to make a
solid argument, we have to do some performance studies...

Regards,

Bala Rajagopalan
([email-masked])

---

From: [email-masked] (Christian Huitema)
Date: Wed, 10 Apr 1996 12:29:14 -0400

On Apr 10, 11:10am, Noel Chiappa wrote:
>...

Uh? The problem of "stabilization" is a classic "control with delay"
problem. But there is no necessarily less delay in the "network routing"
and "demand" level. In one case, the network computes routing dirctions
based on the status of load some times ago; in the other, the user
computes a route based on the status of load... some times ago.

Stabilization can be achieved under certain conditions, e.g. using
sufficiently low-passed estimates or compensating delays with "dead
reckoning" based on accurate models.  This is a classical result of
control theory. Whether this is easier to achieve within the network
through coordinated global decisions or end to end through a large number
of uncoordinated local decisions is debatable -- that is, we need a
serious debates based on facts, model and control theory, not just
qualitative arguments.

-- 
Christian Huitema