QDDIM-02 Issues

1
QDDIM-02 Issues

• Policy Framework WG
• 49th IETF
• Bob Moore - remoore_at_us.ibm.com

2
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

3
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?

4
Issue 1 Pictures
Fwd
Cond
Clas
Met
Mark
Drop
Q
Sch
Fwd
Cond
Clas
Met
Mark
Drop
Q
Sch
5
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

6
Issue 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)

7
Issue 2 Scheduling Disciplines

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

8
Issue 2 Pictures
SchedulerUsed
Q

0..1
Sched
PrioritySchedulerUsed
0..1

BoundedPrioritySchedulerUsed
0..1

etc.
SchedulerUsed
Q

1
Sched
PriSched
BoundedPriSched
etc.
9
Issue 2 Multi-Discipline Scheduler
Is this combination allowed or not?
Priority
Priority
Scheduler 1
Priority
WRR
WRR
Warning Instance diagram
10
Issue 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
11
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

12
Issue 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

13
Issue 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

14
Issue 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?

15
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?

16
Any Other Issues?