qddim-02 issues

12/11/00 Policy Framework WG - 49th IETF 1

QDDIM-02 Issues

Policy Framework WG

49th IETF

Bob Moore - [email protected]


QDDIM-02

• Previously QDIM, the QoS Device Information Model

• In order to move the document forward, the scope was narrowed to DiffServ

• Thus QDDIM, the QoS DiffServ Device Information Model


Issue 1: Derivation of Schedulers

• Should the class PacketSchedulingService be derived– from ConditioningService, just as the classes

for Classifiers, Meters, Markers, Droppers, and Queues are?

– from ForwardingService, because a Scheduler is different in an important way from the other DiffServ elements?


Issue 1: PicturesFwd

Cond

Clas Met Mark Drop Q Sch

Fwd

Cond

Clas Met Mark Drop Q Sch


Issue 1: Discussion

• What would PacketSchedulingService inherit from ConditioningService?– Being a Conditioning Service -- aligns with the

DiffServ Informal Model– Participates in NextService associations– Association with protocol endpoint -- people

think of a Scheduler as the last Conditioning Service on an egress interface


Issue 1: Discussion

• Why should PacketSchedulingService not inherit from ConditioningService?– A Scheduler is in the control plane, not in the

data plane; thus it doesn’t condition traffic (although it controls the conditioning of traffic)


Issue 2: Scheduling Disciplines

• Should specific scheduling disciplines be represented by – subclasses of the SchedulerUsed association?– subclasses of PacketSchedulingService?


Issue 2: Pictures

QSched

SchedulerUsed

PrioritySchedulerUsed

BoundedPrioritySchedulerUsed

*

**

0..1

0..1

0..1

etc.

Q SchedSchedulerUsed* 1

PriSched BoundedPriSched etc.


Issue 2: Multi-Discipline Scheduler

Warning: Instance diagram

Q1

Q2

Q3

Q4

Q5

Scheduler 1

Priority

Priority

Priority

WRR

WRR

Is this combination allowed or not?


Issue 2: Per-Queue Properties

Q1

Q2

Q3Scheduler 1

Priority

Priority

Priority

Where to put the priority values (if notin the associations, then where)?

Warning: Instance diagram


Issue 3: Algorithmic Droppers

• Currently in QDDIM HeadTailDropperSvc is a subclass of DropperService, but other subclasses of DropperService represent the drop algorithm, not the drop location

• The Informal Model is moving towards representing head / tail dropping solely by the relative placement of the queue and the dropper



• There seem to be four (independent?) parameters that characterize a dropper:– Which queue to drop from– Where in that queue to drop from (head, tail, etc.)– Which queue or queues to monitor to make the

drop decision (often, but not always, this is the same queue from which packets are dropped)

– The parameterized algorithm for making the decision whether or not to drop a packet



• So long as we don’t allow the sequence Q-->Dropper-->Q, the first two are handled by the sequence of Conditioning Elements

• Need a separate association for #3; in the MIB, diffServAlgDropQMeasure

• Subclass of DropperService, with additional properties, specifies a drop algorithm and its parameters



• QDDIM also has a class DropThresholdCalculationService, which monitors a set of queues, and aggregates information about them into values that a Dropper can use in its drop algorithm

• Currently this service is not modeled in the Informal Model, the MIB, or the PIB

• Is this something that should be added to the three DiffServ documents?


Issue 4: Representing Filters• Packet filtering clearly applies to more than

DiffServ

• Currently have several ways to represent filters

• single-field generic (FilterEntry)

• single-field specific (examples in IPSP)

• multi-field specific (e.g., IP6TupleFilter)

• atoms (defined in QPIM)

• How much convergence do we need here?


Any Other Issues?

•

•

•

•

qddim-02 issues

Documents