Subject: Re: QOS Routing

From: Jon Crowcroft <[email-masked]>
Date: Wed, 10 Apr 1996 10:01:30 +0100

firstly,

a key difference between resource reservation at the ATM layer and at
the IP layer may also be how much topological information you have
when you make the reservation - if we assume IP over ATM, then there
are 3 types of routing - classic, where the ATM layer has no knowledge
of the IP layer, augmented, where, withi nthe ATM cloud, the ATM layer
and IP layer share information, and integrated pnni, where both layers
have full information

only in the latter case can 
i) a sensible global decison be made as to whether a full path can
support a reservation
ii) the routing updates then include the capacity allocated (or
subtract it from their link state4 advertisements - though its safer
to have two seperate link state advertisement types, one for actual
transmission capacit, the other for allocated effective bandwidth)

if you believe ATM everywhere, then the problem goes away...

the origin of this entire thread was about QoS routing - neither ATM 
nor IP (with int-serv and rsvp - see the to: line) have 
any of the 3 stages of what we might mean by this

1. routing that permits QoS to be advertised safely so that more than
a single set of paths from a soruce to a set of dfestinations are
available  - this is  just about there in some OSPF implementaions and
promised PNNI work...

2. routing that includes current traffic conditions in the
advertisements so that new flows be admitted whilst taking account of
existng traffic - obviously, this can be done without actually
advertising the traffic conditions if a hop by hop reservation is made
since each hop can decide if the current reservation set will permit a
new flow, but it might be nice to actually advertise conditions so
that the next stage can evolve...

3. 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.....

doing this, and including more than just link capacity, is very very
hard....

the advantage that we have with IP level reservation is that it is
(just about) incrementally deployable...

secondly, off at a tangent....

reserving resources for one person is the same as saying that you 
are prepared to deny resources to someone else - denying resource to
some applcations is denying someones business (e.g viewing live TV<
surveillance, telemmetry, share dealng - anythign where the actual
data soruce is ephemeral) - denying service to other applications is
noit denying anything - e.g. if an FTP can be resecheculed, and
osmeone has other work to get on with, then whats the problem - these
key requirements are why you HAVE to have guaranteed services, and
why the internet works....respectively....

however, there may be no business case for denying service to any
realtime users - certainly TV companies (and most telephone nets)
guarantee service without reservation....in the sense that you
practically never get a busy signal.....

the bottom line is that there is only so much that people can do - and
being on a 3D holographic videophone or VR game 24 hours a day is the
limit - there is no such thing as a bottomless demand for
capacity....people claim computer based applications might cause
higher capacity fdemand, but the economics say that we'd move the
processing power to the data in those cases...

 jon