Subject: Re: heterogeneity

From: Scott Shenker <[email-masked]>
Date: Thu, 5 Jan 1995 10:07:14 PST

> A couple questions/comments regarding design option 1:
> 
> 1) I didn't quite get whether or not unreliable replacements are fair
> game with this option.  Is a router allowed to advertise and use only
> reliable replacements?

A router is allowed to advertise and use either reliable or unreliable
replacements.  The key point is that the router must use whatever it
advertises.  In particular, if the router advertises a reliable
replacement, it must use a reliable replacement (or fail).

> 
> 2) Suppose a user/application isn't so concerned with the end-end
> characteristics (i.e., level-of-effort predictive works fine), but it
> wants to ensure that it is getting what it asked for and not a
> replacement.  Having to analyze the advertisements to figure this out
> seems like overkill.  Would a flag (or two) in the service request
> indicating "no replacements" and/or "no unreliable replacements" be
> workable (analogous to the "fail" action from option 2 without the
> scripting)?
> 

Yes, I see this as a stripped down version of option 2.  Ignoring the
issue of what to do when the service is not known, one can describe a
general script with three numbers:  the various router actions in the
cases of (1) not offered, (2) not admissable, and (3) not mergeable.
Each router action has one of three options: fail, reliable
replacement, and unreliable replacement.  If I understand you
correctly, you want to collapse all the three cases (not offered, not
admissable, and not mergeable) into one (i.e., they all induce the same
router action), and then just set a single flag to indicate what to
do.  That certainly simplifies things a little, but your proposal still
has the basic conceptual problem (inherent in scripts) of what to do
about merging.

I definitely agree with you that we should contemplate reducing the
degrees of freedom available in a script.  However, there are some
important reasons to want to distinguish between not admissable and not
offered.  I guess I am still somewhat unsure of the right tradeoff here
between reducing complexity and retaining adequate functionality.

--Scott