Subject: Re: latest draft of guaranteed

From: [email-masked] (Fred Baker)
Date: Mon, 15 Jul 1996 09:32:44 -0700

At 8:46 AM 7/15/96, [email-masked] wrote:
>We have said all along that different services cannot be merged.

true, but that's not the same thing. My point (and if I understood Craig,
he appears to agree) is that if two specs use the same parameter (token
bucket parameters, for example), they should have the same name.

If we do that, the sender can advertise his transmissions, and the
recievers can figure out what they want. If the recievers all want
guaranteed service, so be it, and if they all want controlled load, so be
it. But what the sender advertises (apart from the adspec) shouldn't have
to change on the basis of that.

Seems that if the sender starts receiving RESV messages containing requests
for Guaranteed QoS, that will serve as a trigger to start generating the
adspec. That works. But if we have different name spaces, then the sender
has to know outright what the recievers will ask for before they ask.
Taking it completely out of band sounds like a bad idea to me.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
When people run around and around in circles we say they are crazy.
When planets do it we say they are orbiting.

---

From: Craig Partridge <[email-masked]>
Date: Mon, 15 Jul 96 10:19:21 -0700

Yep.

It isn't quite that simple.  One has to worry about cases in which some
receivers want guaranteed and some want controlled load (in which case
there are nifty problems of replacement).

From an INT SERV perspective, I believe, with a bit of care, the data
structures work.  There's some trickiness there -- the value of certain
common parameters may be handled different depending on whether you want
guaranteed or controlled load -- I think, in practice, one probably needs
one ADSPEC per service (and for a family of compatible services like
guaranteed and controlled load, this means advertising multiple ADSPECs
in a PATH message -- I think...).  Putting it another way, I'm pretty
clear how I'd set up the services using SNMP.

Note, there need to be some composition rules that tell you when you can
substitute guaranteed for controlled load (ALWAYS) and controlled load for
guaranteed (???), and what you do when a guaranteed request appears on a
previously controlled-load-only branch and due to policy constraints
the guaranteed request would be denied while the controlled load request
is acceptable....

So far, INT SERV has focussed on ensuring that new services fit compatibly
with best effort [Fred, I think this is where you've heard most of the
comments about the receivers get to choose: they choose whether they want
best effort or something else] -- we've deferred (despite periodic reminders
from XEROX PARC) the issues of heterogeneity and mixing services.

Craig