Subject: Re: guaranteed service vs CBR

From: [email-masked] (Noel Chiappa)
Date: Tue, 18 Jul 95 09:19:03 -0400

From: Jon Crowcroft <[email-masked]>

    given we have IP ratehr than pinned virtual circuits a la ATM, we cannot
    know a lot about the hop by hop (e.g. we don't know how a delay budget is
    subdivided amongst hops....

As long as path selection decisions are made in a distributed fashion, as they
are now, with each node node making a choice effectively independantly of
choices made at other nodes, (I know, I know, the routing table entries are
coordinated - let's not get hung up on that philosophical pin-head), there's
no way to do a calculation that looks at the whole situation, and divides up a
delay budget, or ensures that the overall path meets an overall delay
constraint.

The solution to this thus more or less has involve making those path selection
decisions in a non-distributed way (or at least in a way where any
distribution is not in a peer relationship, as it is now, but in a
hierarchical relationship); what is called "unitary" or "explicit" routing.

This does *not* mean you have to go to a virtual circuit, or at least what I
think of when I hear the words "virtual circuit". To me, X.25 is a virtual
circuit network. If you label anything that's not unicast IPv4 a "virtual
circuit", then maybe the solution does involve a "virtual circuit".

(I except multicast IPv4 since, modulo tunneling, it requires setting up state
in all the routers along the distribution tree; i.e. it's a multi-cast
"virtual circuit", if your definition of "virtual circuit" involves state in
the switches.

This is actually a pretty zany definition for virtual circuits, now that I
think about it, since many X.25 networks don't have state in intervening
switching, just end switches; so by that definition, I'm not sure X.25 would
be "virtual circuit"! I actually wonder, sometimes, if perhaps some of the
people who disparage things as being "virtual circuit" have not really thought
about what the defining characteristics of a virtual circuit network are,
anyway, and just use the term as a convenient put-down, one which most people
accept without thinking about it. Perhaps we could all profit from thinking
for a bit about what a virtual circuit network really is, anyway, and what
characteristics make it so.)

    so the problem is that since we can see less of the internal
    implementation of the QoS provision, we have to say more than we would if
    the net revealed more of its topology and traffic patterns as a VC type net
    would...
 
Again, you don't have to go to a "virtual circuit" network to get this kind
of information (I'm not sure if that's what you're implying, or if you're
just trying to to use them as an example, and saying we might want to try and
do something analagous).

I think getting that kind of information (and control) out of your routing is
the only real way to do the kind of things you want to do. I obviously don't
think it's impossible; a combination of distributing maps as the basic routing
data, and explicit routing, does just that (and much more than that I'm loath
to say, less people think I'm trying to push a particular solution to the
problem).

	Noel

---

From: Steve Jackowski <[email-masked]>
Date: Tue, 18 Jul 1995 09:14:18 -0900 (PDT)

Noel,

> characteristics make it so.)
Relaxing some attitudes about virutal circuits might just 
open the door to some creative solutions.  Perhaps then we 
could make some real progress towards integration with ATM 
and standard telephony (ISDN) networks: the folks 
associated with these technologies (ATM Forum, ITU, etc) 
only understand circuits.  It seems that many of us 
concentrate on disparaging what doesn't quite fit our 
model rather than adapting.

Steve