Subject: QDIM issue: the SchedulingService classes

From: [email-masked]
Date: Thu, 17 Aug 2000 14:12:54 -0400

An instance of any of the scheduling service classes
represents a scheduler, which is a component that
services a set of queues according to the parameters
of some scheduling algorithm.  A priority scheduler
services queues based on static priority values
associated with each queue.  But the QDIM-01 model
can't represent these priorities:  it has only a
single-valued Priority property on the
PrioritySchedulingService object itself.

What's needed is the ability to have one priority
value per queue that a priority scheduler is
servicing.  There are two ways to do this:

  a. Move the Priority property from
     PrioritySchedulingService to the association
     SchedulerUsed that sits between a scheduler
     and each of the queues it services.

  b. Move the Priority property from
     PrioritySchedulingService to the class
     QueuingService.  Note that this is an
     option only because the cardinality at the
     PacketSchedulingService end of the
     SchedulerUsed association is 0..1, which
     says that a given queue can by serviced
     by at most one scheduler.

There is disagreement among the QDIM authors
about which of these alternatives we should
choose.  Alternative (a) represents more
accurately the fact (anthropomorphizing a bit)
that a queue doesn't "know" anything about
what priority it has with respect to a given
scheduler / scheduling algorithm.  The
argument for alternative (b) is that it's
easier to implement (in a data model)
properties on classes than it is to implement
properties on associations.  I believe that
(a) is the better alternative here, but I
could live with (b).  We can't, however, live
with Priority where it is now, on
PrioritySchedulingService.

I'm going to continue from this point with
the assumption that we choose alternative (a)
above.  The same basic changes to the model
can be made (subclassing the queue classes
rather than the associations) if we choose
to go down the (b) path.

  - Once we move Priority up to SchedulerUsed,
    there's no need any more for the class
    PrioritySchedulingService.  A priority
    scheduling service is now represented as
    a PacketSchedulingService whose
    SchedulerUsed associations all have the
    Priority property on them.
  - Similarly, we no longer need the class
    PriorityBandwidthSchedulingService:  this
    is just a BandwidthSchedulingService whose
    SchedulerUsed associations all have the
    Priority property.
  - WeightedRoundRobinPacketSchedulingService
    has a problem similar to the one we just
    fixed for PrioritySchedulingService.  It
    has a WeightingFactor property that needs
    to be one per queue, not one for the whole
    scheduling service.  The way to fix this
    problem is to move the WeightingFactor to
    the associations, just as we did with
    Priority.  To do this, we need to subclass
    the SchedulerUsed association to a new
    association class WRRSchedulerUsed, so we
    can add the new property to the association.
    On the scheduler side, this new association
    goes to WeightedRoundRobinPacketScheduling
    Service rather than to its superclass
    PacketSchedulingService.
  - Applying the same trick a third time, we
    define another subclass of SchedulerUsed,
    BandwidthSchedulerUsed, so that we can
    move the per-queue property
    BandwidthAllocation from the class
    BandwidthSchedulingService up to the
    association.  This time the class on the
    scheduler side of the new association is
    BandwidthSchedulingService.

Finally, one more change to the scheduler classes,
which is independent of all the changes we've
discussed up to this point:  we need to move
the Boolean property WorkConserving from the
class BandwidthSchedulingService up to its
superclass PacketSchedulingService.  The reason
for doing this is to align with the treatment
of work-conserving and non-work-conserving
schedulers in the Diffserv Conceptual Model.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: "Andrea Westerinen" <[email-masked]>
Date: Fri, 18 Aug 2000 01:46:10 -0700

Regarding moving Priority to the SchedulerUsed association...  This property
can't be on the SchedulingService since each queue serviced by the
SchedulingService (there can be more than 1) might have unique values.  The
property could be on the QueuingService since it is only serviced by 1
scheduler (the 1..1 cardinality on SchedulingService in SchedulerUsed).
But, this says that a queue object natively knows its priority.  From a
modeling perspective, this is wrong.  A queue does not know this - only its
scheduler does.  Also, if the cardinalities on SchedulerUsed were ever
relaxed in the future, we would be screwed with priority on the
QueuingService (ie, there wouldn't be only 1 priority).

For me, this is not just "six of one, half dozen of another" - in which case
we should not have moved the property.  But, instead, it is a conscious
modeling choice - that should improve the model's semantics.

BTW, I disagree with the argument "it's easier to implement (in a data
model) properties on classes than it is to implement properties on
associations."  This is tieing the info model to an implementation/data
model.  We have worked very hard to keep these separate - and keep the info
model as semantically correct as possible, while the data model may be
optimized.  Properties on associations make sense when the property deals
with (adds info to) the relationship between the two entities, and is not
data specific to a single entity in the relationship.

Note that the info model does not say "thou must", but says "these are the
semantics" and "this is how the pieces fit together."  As long as we can
make the pieces fit together, data models are free to optimize.

Andrea

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Thursday, August 17, 2000 11:13 AM
To: [email-masked]
Subject: QDIM issue: the SchedulingService classes

... Alternative (a) represents more
accurately the fact (anthropomorphizing a bit)
that a queue doesn't "know" anything about
what priority it has with respect to a given
scheduler / scheduling algorithm.  The
argument for alternative (b) is that it's
easier to implement (in a data model)
properties on classes than it is to implement
properties on associations.

<snip>

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 18 Aug 2000 11:53:37 +0200

Bob,

I favour (a). The argument about easier implementation is true, but
holds for all associations. If implementation is an issue, we would
better live with a set of references instead of associations. The great
thing about associations is the adding of properties, so use it.

Marcus

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

New address starting 9/1/2000
Postal Mail:
Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 905110
Fax:   +49 (0)6221/ 9051155

Address valid until 8/31/2000
Postal Mail:
Hardenbergplatz 2
D-10623 Berlin
Germany

Phone:  +49 (0)30/ 25 42 30 17
Fax:    +49 (0)30/ 25 42 30 99