Title: QDDIM-02 Issues
1QDDIM-02 Issues
- Policy Framework WG
- 49th IETF
- Bob Moore - remoore_at_us.ibm.com
2QDDIM-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
3Issue 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?
4Issue 1 Pictures
Fwd
Cond
Clas
Met
Mark
Drop
Q
Sch
Fwd
Cond
Clas
Met
Mark
Drop
Q
Sch
5Issue 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
6Issue 1 Discussion
- Why should PacketSchedulingService not inherit
from ConditioningService? - A Scheduler is in the control plane, not in the
data plane thus it doesnt condition traffic
(although it controls the conditioning of traffic)
7Issue 2 Scheduling Disciplines
- Should specific scheduling disciplines be
represented by - subclasses of the SchedulerUsed association?
- subclasses of PacketSchedulingService?
8Issue 2 Pictures
SchedulerUsed
Q
0..1
Sched
PrioritySchedulerUsed
0..1
BoundedPrioritySchedulerUsed
0..1
etc.
SchedulerUsed
Q
1
Sched
PriSched
BoundedPriSched
etc.
9Issue 2 Multi-Discipline Scheduler
Is this combination allowed or not?
Priority
Priority
Scheduler 1
Priority
WRR
WRR
Warning Instance diagram
10Issue 2 Per-Queue Properties
Where to put the priority values (if not in the
associations, then where)?
Priority
Priority
Scheduler 1
Priority
Warning Instance diagram
11Issue 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
12Issue 3 Algorithmic Droppers
- 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
13Issue 3 Algorithmic Droppers
- So long as we dont allow the sequence
Q--gtDropper--gtQ, 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
14Issue 3 Algorithmic Droppers
- QDDIM also has a class DropThresholdCalculationSer
vice, 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?
15Issue 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?
16Any Other Issues?