Transcript QDDIM-02 Issues Policy Framework WG 49th IETF Bob Moore -

QDDIM-02 Issues
Policy Framework WG
49th IETF
Bob Moore - [email protected]
12/11/00
Policy Framework WG - 49th IETF
1
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
12/11/00
Policy Framework WG - 49th IETF
2
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?
12/11/00
Policy Framework WG - 49th IETF
3
Issue 1: Pictures
Fwd
Cond
Clas
Met
Mark
Drop
Q
Sch
Q
Sch
Fwd
Cond
Clas
12/11/00
Met
Mark
Drop
Policy Framework WG - 49th IETF
4
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
12/11/00
Policy Framework WG - 49th IETF
5
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)
12/11/00
Policy Framework WG - 49th IETF
6
Issue 2: Scheduling Disciplines
• Should specific scheduling disciplines be
represented by
– subclasses of the SchedulerUsed association?
– subclasses of PacketSchedulingService?
12/11/00
Policy Framework WG - 49th IETF
7
Issue 2: Pictures
Q *
SchedulerUsed
0..1
Sched
PrioritySchedulerUsed
0..1
*
BoundedPrioritySchedulerUsed 0..1
*
etc.
Q *
SchedulerUsed
PriSched
12/11/00
1
Sched
BoundedPriSched
Policy Framework WG - 49th IETF
etc.
8
Issue 2: Multi-Discipline
Scheduler
Is this combination allowed or not?
Q1
Priority
Q2
Q3
Priority
Scheduler 1
Priority
WRR
Q4
Q5
12/11/00
WRR
Warning: Instance diagram
Policy Framework WG - 49th IETF
9
Issue 2: Per-Queue Properties
Where to put the priority values (if not
in the associations, then where)?
Q1
Q2
Q3
Priority
Priority
Scheduler 1
Priority
Warning: Instance diagram
12/11/00
Policy Framework WG - 49th IETF
10
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/11/00
Policy Framework WG - 49th IETF
11
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
12/11/00
Policy Framework WG - 49th IETF
12
Issue 3: Algorithmic Droppers
• 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
12/11/00
Policy Framework WG - 49th IETF
13
Issue 3: Algorithmic Droppers
• 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?
12/11/00
Policy Framework WG - 49th IETF
14
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?
12/11/00
Policy Framework WG - 49th IETF
15
Any Other Issues?
•
•
•
•
12/11/00
Policy Framework WG - 49th IETF
16