Subject: Concerns about exported numbers 1/03/96 13:07:59

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Wed, 3 Jan 96 18:53:31 EST

Reference:  Your note of Wed, 3 Jan 1996 13:07:59 -0800

>From discussions I have had with John W, it sounds like C and D are
>constants, not measurements.

Absolutely.  Since Guaranteed Service specifies a deterministic
QoS measure (delay bound), the advertised quantities are constants.

>These would certainly be good things to put
>into a MIB rather than repeat on the wire every few seconds. And I could
>put these others into the int-serv MIB if that works for people.

Don't mean to blunt, but to me this seems like a barely hidden way to bury
the service.  I just cannot imagine that an application that receives a
PATH message will then take the trouble to figure out all the routers
it went through, get the necessary info back from all of them, and
then use it to request the service.  You mention below some of the
difficulties you are facing when trying to explain to application writers
what to do with the various numbers defined, and this one seems far worse.
This is even less than an option, which if I recall correctly means
"not implemented".

>I am still, like you, concerned with the meaningfulness (meaninglessness?)
>of the numbers requested - if I know, as you suggest, what was the worst
>delay experienced in the last 60-120 or 3600-7200 seconds, what is the real
>utility of this? The 60-120 second number, by that approach, would never be
>greater than the 3600 second number, as the two time domains overlap, and
>if it is less, which is more meaningful? The fact that current conditions
>allow for better delay characteristics, in which case I wonder why we need
>the 3600 second number, or the fact that conditions have been worse, in
>which case what's the point of the 60 second number?

The issue of measurements, their usefulness and how to use them, is
somewhat different from the C and D parameters aspect you mention above.
However, I usually think of them as a less precise characterization of
the delay associated with a certain service class.  This will likely
change over the day as traffic patterns change (at night, the lowest
level of service may be ok, but not during peak hours where I may need
to ask for something better if I need to get some level of delay
guarantees).  I am not advocating a specific measure or set of numbers,
just outlining what they could be used for.

>Before we do either, I would love to get a full description of exactly how
>the application is supposed to use those numbers. I'd like to know for sure
>that we are measuring the right thing.

If you are now getting back to the C and D terms, I think how they are to
be used by an application is reasonably well explained in the Guaranteed
Service specs.  You need them if you want to ask for a given delay bound.
Now, your application may not need that, but that's a different argument
than how to use the numbers.

>Maybe this is my "MIB designer" side coming out - folks like to take a lot
>of nebulous measurements, throw in a bunch of counters and gauges that say
>"I passed through this bit of code", without particularly thinkng about
>what the numbers are good for. Then I get the application writers and the
>network managers coming back to me asking for (this is literally a request
>I received once) a statement of what they can deduce from each number
>counting quickly or slowly, or not counting, and how that relates to the
>price of tea in China. So before *I* get hammered with the question, I am
>putting the question to the list, and submitting that absent a very clear
>explanation that an application writer or network manager can use well, we
>don't advertise the numbers in the first place.

I think what the C and D terms are used for is pretty clear (btw, sent
Craig a short note outlining what they mean for WFQ and RCSD schedulers.
Maybe that can help clarify things).  If the application does not really
care about a hard delay bound, then it should probably not use Guaranteed
Service and instead ask for Controlled Load. Alternatively, it
could simply ask for a service rate R=r, irrespective of what the Ctot and
Dtot values it received were.  On the other hand, if it is really interested
in getting a hard delay bound, then it is readily obtained from Ctot and
Dtot based on the service rate it ends-up requesting.

Roch