1 / 16

QDDIM-02 Issues

QDDIM-02 Issues. Policy Framework WG 49th IETF Bob Moore - remoore@us.ibm.com. QDDIM-02. Previously QDIM, the QoS Device Information Model In order to move the document forward, the scope was narrowed to DiffServ Thus Q D DIM, the QoS D iffServ Device Information Model.

holli
Download Presentation

QDDIM-02 Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. QDDIM-02 Issues Policy Framework WG 49th IETF Bob Moore - remoore@us.ibm.com Policy Framework WG - 49th IETF

  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 Policy Framework WG - 49th IETF

  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? Policy Framework WG - 49th IETF

  4. Issue 1: Pictures Fwd Cond Clas Met Mark Drop Q Sch Fwd Cond Clas Met Mark Drop Q Sch Policy Framework WG - 49th IETF

  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 Policy Framework WG - 49th IETF

  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 doesn’t condition traffic (although it controls the conditioning of traffic) Policy Framework WG - 49th IETF

  7. Issue 2: Scheduling Disciplines • Should specific scheduling disciplines be represented by • subclasses of the SchedulerUsed association? • subclasses of PacketSchedulingService? Policy Framework WG - 49th IETF

  8. Issue 2: Pictures SchedulerUsed Q * 0..1 Sched PrioritySchedulerUsed 0..1 * BoundedPrioritySchedulerUsed 0..1 * etc. SchedulerUsed Q * 1 Sched PriSched BoundedPriSched etc. Policy Framework WG - 49th IETF

  9. Q1 Q2 Q3 Q4 Q5 Issue 2: Multi-Discipline Scheduler Is this combination allowed or not? Priority Priority Scheduler 1 Priority WRR WRR Warning: Instance diagram Policy Framework WG - 49th IETF

  10. Q1 Q2 Q3 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 Policy Framework WG - 49th IETF

  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 Policy Framework WG - 49th IETF

  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 Policy Framework WG - 49th IETF

  13. 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 Policy Framework WG - 49th IETF

  14. 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? Policy Framework WG - 49th IETF

  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? Policy Framework WG - 49th IETF

  16. Any Other Issues? Policy Framework WG - 49th IETF

More Related