Subject: Re: heterogeneity

From: David Clark <[email-masked]>
Date: Wed, 11 Jan 1995 10:46:25 -0800

Scott and folks,

I wanted to offer some comments on Scott's heterogeneity note. These thoughts
have come from some conversations that JohnW and I have had, and its possible
that he agrees with what I am saying.

I agree with the basic thrust of Scott's proposal, but have a slight change that
is perhaps not so slight...

The top level comment is, (along the same lines of our note to some of you
on link-sharing) to avoid complexity that we don't yet know that we need.
If I go back to our proposal about the QM, the top-level position on the
table was that for most applications, it is not necessary to reveal most of
the complexity of the particular service. For predictive service, I argued
that what most applications need to know is that there is a somewhat stable
bound which they can adapt to. This rather simple view leads to a similar
view of what RSVP must do.

I claim that for most applications, what they want to ask for is "predictive".
Nothing more. No more details. There may be applications with more advanced
problems that want to say more, but we need, at a minimun, to deal with
applications that just want to say "predictive".

At the same time, the problem that Scott raises is a very real one. If we are
going to have different sorts of predictive services in the network, we
need some way to mix different service types that occur in different parts
of the network when setting up a connection. And I agree that the right
model is some sort of controlled fall-back to a different service. The
interesting question is how that fall-back is controlled.

Scott's model is that the user describes the acceptable degree of fall-back in
abstract terms, using the fixed space of: no replacement, reliable replacement,
unreliable replacement.  The router then gets to make the decision as to what
specific option to pick in making the replacement.

In general (and again, I play the taxonomist) there are three places where the
decision as to the specific replacement could be made. 1) Scott's proposal: the
router makes it within the bounds of the abstract specification from the source.
2) The source of the reservation could make it. The reservation, instead of
having an abstract measure of replacement, could have a list of explicit
services, and the router picks the first one that can be accepted. 3) The IETF
working group could define the accepted fall-back method for each service.

My claim is that in fact the real answer will be a mix of these, and we need to
recognize that.

The advantage to option 1, letting the router pick, is that the router can
make a
decision that is specific to the site, such as the decision that a link is so
underloaded that it represents a reliable repacement.

The advantage of option 2, let the reservation requestor pick, is that it deals
with unknown services. Since the request just lists a set of services, the
router
just goes down the list until it finds one it knows. Scott's proposal has this
feature as a special case, as a script under the "dont know" case. But it also
solves other problems. For example, a client might want to offer guaranteed as a
"fall-back" for predictive, to deal with the possibility of a <not mergeable>
failure.  The disadvantage of this scheme is that it makes the role of the
end-point more complex, not more simple.

But the importance of option 3 should be factored into all this. Scott observes,
and I agree, that we are going to have a degree of heterogeneity, but a small
degree. We may have a few options for predictive service, but not 27. These will
be discussed and approved by the WG. I suspect that, as we start to define the
specific alternatives, that we will in fact define classes of services which are
known to "replace" each other in understood ways. Scott's note offers
examples of
how replacement could work. I think that these examples will get considered, and
documented, and will in fact be the basis for what the router vendors do.

I think we will document services that can serve as replacements for
others. John
and I were using the alternatve vocabulary of "classes of services that can be
composed". So different forms of predictive service can be composed, for
example.
We had a sort of "greater than/less than" model of composition. A user
asking for
a bounded delay predictive service could know that this could be composed "down"
with a level of effort predictive service, or composed "upward" with a
guaranteed
service (assuming that this works, which it may not...).

My point here is not to discuss specific replacements or compositions, but to
note that by the time the WG gets done filling in a service template for a bunch
of services, it will understand those services pretty well, and will define the
range of workable replacements. So perhaps we should recognize, in the way that
RSVP names and asks for services, that these sets will exist, and will probably
be a part of the process of defining the templates.

This might end up with reservations that look a lot like Scott's. That is, they
would specifiy a particular service, and then specify in abstract terms what
sorts of replacements they will accept. However, instead of a static class of
replacements (none, reliable, unreliable) the set will be a set that is defined
for the particular group of services. The set of understood replacements among a
group of services will be defined as a part of the template process, I assume.
Thus, for predictive, the list might include Scott's options, as well as other
options such as <accept guaranteed>.It would also define a default behavior if
the application just asked for "predictive".  This is the means to give us the
simplicity that I claim most applications will want.

This control of heterogeneity at the WG level might in fact help get a handle on
the problems of merging services. If we specify what it means to replace one
service with another, and the user accepts that replacement in his reservation,
then the consequence of merging is well defined and can be carried out.

Merging, replacing and composing are all sort of the same thing, I suspect.

Dave