Re: Inconsistencies in QDDIM -07 Draft
[email protected] Wed, 29 May 2002 13:36:09 -0400
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
Hi Andrea,
Busy editing QDDIM ....
From CR 795:
// ==================================================================
// CalculationServiceForDropper
// ==================================================================
[Association, Experimental, Version ("2.7.0"),
Description (
"This association is a subclass of ServiceServiceDependency, "
"and represents the reliance of a REDDropperService on one or "
"more DropThresholdCalculationServices. The latter calculate "
"average queue depth, based on the observed depths of a "
"queue. The specific queue examined by each CalculationService "
"is defined using the CalculationBasedOnQueue association.") ]
class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency {
[Override ("Antecedent"), Description (
"A calculation service for the dropper.") ]
CIM_DropThresholdCalculationService REF Antecedent;
[Override ("Dependent"), Description (
"The RED dropper which is dependent on average queue depth "
"calculations by the Antecedent Service.") ]
CIM_REDDropperService REF Dependent;
};
For the calculation service, the words say "one or more", but the
cardinality says 0..n. You also propose 0..n for QDDIM, but I think that
the words are correct here - the cardinality should be 1..n, since the only
path to get from a RED dropper to a queue for it to examine is via a
calculation service instance.
Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n
in the QDDIM update. You can still talk me out of this is you're quick.
Otherwise, I've edited QDDIM as you've proposed in this note.
Regards,
Bob
Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email protected]
"Andrea
Westerinen" To: "Policy@Ietf. Org" <[email protected]>, Robert Moore/Raleigh/IBM@IBMUS
<andreaw@cisco. cc:
com> Subject: Inconsistencies in QDDIM -07 Draft
05/14/02 06:28 PM
In reading QDDIM very closely :-), I noticed some inconsistencies in the
text in Section 3, in the formal class definitions in Section 4, and in the
intent. Here are my observations and recommendations ...
1. For RED droppers, I think that we wanted the following ...
A REDDropperService can be related to many DropThresholdCalculationServices
(many to many), but each CalculationService examines a single queue (many
to one).
2. This means that ...
IF you define a DropThresholdCalculationService, you really MUST specify
the queue that is examined. So, CalculationBasedOnQueue should have a
cardinality of 1..1 on the QueuingService side (currently it has 0..1).
AND
A REDDropper MAY be associated with one or more CalculationServices (each
looking at a specific queue). So, CalculationServiceForDropper should have
a cardinality of 0..n on the DropThresholdCalculationService side
(currently it is a mandatory 1).
3. For a HeadTailDropperService, its determinations can also be based on
several queues (as discussed at the bottom of page 23). So,
HeadTailDropQueueBinding should have a cardinality of 1..n for the
QueuingService (currently, it has mandatory 1). I agree that at least
queue is mandatory - but more than one can be examined.
Andrea
graycol.gif
(image/gif, 105 B) - not displayed
ecblank.gif
(image/gif, 45 B) - not displayed