Design Philosophy of Scheduler - PowerPoint PPT Presentation

Loading...

PPT – Design Philosophy of Scheduler PowerPoint presentation | free to download - id: 206c69-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Design Philosophy of Scheduler

Description:

A user requests some rates for each of his ftp connections. ... What does the tree representation mean. An edge means parent-children relationship of classes; ... – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 31
Provided by: xia123
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Design Philosophy of Scheduler


1
Design Philosophy of Scheduler
  • Design a very general and flexible scheduler at
    transport layer that can
  • work at different locations in the network
  • provide mechanisms for implementing a wide range
    of traffic classification and bandwidth
    management policies.
  • Encourages traffic aggregation, hence increases
    bandwidth utilization.
  • Have a structured implementation and programming
    interfaces.

2
Original Model Scheduler at the End-Systems
Connection Relationships
3
Corporate Network
T1/T3
ISP
Backbone Network
Corporate Intranet
Client
Rate Control Device
Access Link
4
ISP Network and Server Farms
Server Farm
POP
Layer4/7 Switch
Home Clients
Backbone Network
ISP Network
5
Inter-Domain Scenario
Domain C
Backbone
Domain A
Client
Edge Device
Domain B
Access Link
Fat Pipe
6
Examples of User Requirements
  • A user requests some rates for each of his ftp
    connections.
  • A user requests that his connection be guaranteed
    a delay bound d and a probability 1- a.
  • A manager requests that connections from his
    department be given a combined bandwidth of f1.
  • Based on the company's mission, the administrator
    specifies that database traffic be given a
    bandwidth f2 and realtime video traffic be given
    a bandwidth l. He also specifies that realtime
    video be given a delay guarantee of d with
    probability 1- a.
  • The administrator decides that all users should
    be given equal bandwidth.

7
H-PFQ (Bennett and Zhang 96)
8
A CBQ Implementation Example
  • Ftp class has a minimum bandwidth reservation
    over appropriate time scale.
  • Can be viewed as priority scheduler with link
    sharing constraints.

Link
20
80
Agency A
Agency B
real- time
inter- active
real- time
inter- active
ftp
ftp
3, 30
2, 25
1, 25
3, 10
2, 5
1, 5
9
Our Scheduler
Type I
f11
f12
f13
Type II
Type III
f21
f22
Type II- Infinity
3
1, d1
2, d2
r31
r32
3
1, d3
2, d4
r41
r42
1
2
3
r51
r52
r53
10
An Instance
Link
3
Real- time
Inter- active
Elastic
1, d1
2, d2
Buf. video
ftp
33
67
11
Goal of Scheduling
  • Satisfies requirements (vaguely) from individual
    connections, together with admission control.
  • Satisfies the requirements from individual
    classes, which are aggregation of a set of
    connections with some common characteristics.
  • Distributes extra bandwidth prudently.
  • Participates in flow control and regulates excess
    traffic.
  • Achieve flow isolation and fairness.
  • Always aims at high bandwidth utilization.
  • Optimize operators objectives bandwidth
    utilization, revenue, or combined users
    satisfactions, subject to constraints.

12
Goal of Scheduling Cont.
  • The items in the list have overlap. Need to
    understand these objectives better.
  • One approach is to define a precedence relation
    among the objectives (Shenker et al, 93).
  • It is hopefule to design mechanisms that can
    achieve any suitable arrangement of objectives.
  • Ways to achieve higher utilization
  • Aggregation of realtime traffic
  • Tradeoff between realtime and elastic connections.

13
Key Features of H-PFQ
  • Goals
  • Provides realtime traffic delay bound (loose)
  • Distribute excess bandwidth according to the tree
    hierarchy (link sharing)
  • What does the tree representation mean
  • An edge means parent-children relationship of
    classes
  • a missing edge means disjoint classes
  • children of an class is a partition of the class.
  • Weighted fair-queueing on each level of the tree.

14
Weakness of H-PFQ
  • Bandwidth defined only on the shortest timescale
    cannot trade-off realtime traffic and elastic
    traffic.
  • All requirements are handled by bandwidth
    allocation and hence it discourages aggregation.
  • Unnatural to emulate more than two priority
    levels.
  • It is problematic for time-varying link capacity,
    where delay cannot be guranteed, but multiple
    prioirty levels still makes sense.
  • Limitation of tree representation assumes
    classes are disjoint.

15
CBQ (Floyd and Jacobson 95)
  • Goals
  • Satisfies realtime traffic
  • Provides link-sharing services for classes
  • Each class receives its allocated bandwidth over
    appropriate time interval
  • Prudent distribution of excess bandwidth (It is
    for this purpose the tree hierarchy is defined.)
  • Not an implementation, but a guideline
  • The tree is represents bandwidth-sharing
    requirements.

16
CBQ Realtime Services
  • Realtime class takes priority when the traffic is
    bursty and lightly loaded. (note the bandwidth
    are measured on different time scales)

80
80
60
2
20
video
ftp
video
ftp
1
video1
video2
ftp1
ftp2
ftp1
ftp2
2, 5
2, 15
1, 40
1, 20
33
67
17
CBQ Realtime Service Cont. 1
  • Link sharing becomes effective when a backlogged
    lower-priority classes do not get the bandwidth
    assigned over their timescale.
  • Guard against overloading by realtime traffic due
    to admission control error or misbehavior.
  • Give up notion of hard delay guarantee.
  • Allow some realtime applications to adapt
    bandwidth fluctuation.

18
CBQ Realtime Service Cont. 2
  • With more low-priority classes, it becomes harder
    to provide strict priority to the high-priority
    class. It becomes more like processor sharing.
  • If two different priority levels have the same
    timescales, it becomes processor sharing.

19
Weakness of CBQ
  • Since bandwidth are measured on different time
    intervals, weight assignment makes no sense. They
    do not have to add up to 1.
  • Assumes classes are disjoint.

Link
Link
Agency A
Agency C
Agency B
audio
mail
ftp
telnet
video
20
50
10
20
0
10
40
50
20
Weakness of CBQ - Cont
  • The following makes no sense. Has to use the
    previous classification scheme.
  • What if the classes cannot be represented by a
    tree?

Link
Agency A
Agency C
Video
10
40
50
21
Vagueness in User Requirements
  • Bandwidth minimum, maximum and average bandwidth
    and their relevant timescales.
  • Traffic Classes including short-interactive
    flow, bulk transfer, realtime stream, and
    buffered stream
  • Delay average and maximum delay, and
    probabilistic bound
  • Transfer Size special handling of short flows
  • Bandwidth Adaptability the application control
    the data generating rate, and can render the
    received data at different level of quality.

22
Goals of Scheduler Design
  • Want to support the following services
  • Bandwidth guarantee at the shortest time scale
  • Various probabilistic delay-guarantees
  • Bandwidth guarantee on longer time scales
  • Priority class when bandwidth is uncertain.
  • Best effort services
  • Want a structured representation of the above.
  • Want more general notion of connection classes
  • Want a representation that leads directly to
    implementation. Timescales are explicit in the
    representation.

23
Scheduler Definition
  • Define three classes
  • Type I bandwidth guaranteed on shortest time
    scale. Each class is associated with a number fi,
    which is the rate assignment for the class.
  • Type II delay guarantee is characterized by a
    tuple (di, pi, ri), indicating Pr(D gt di) lt pi,
    where D is the queueing delay. Note that di can
    be infinity. The optional ri stands for the
    average rate of this class, and is used for
    admission control.
  • Type III best-effort class, bandwidth guaranteed
    on longer time scale. Each is associated with a
    pair (mi,ri), where the mi is the minimum rate
    and ri is the average rate.

24
Rules for Scheduler Hierarchy
  • Type I class can have Type I, II, or III as
    children.
  • Type II class has no children, except that Type
    II-Infinity may have Type III or Type II-Infinity
    as children.
  • Type III class can have Type III or Type
    II-Infinity as children.
  • All children of a class must themselves be the
    same type.
  • Notice that Type I can only have Type I as
    parent. Type II can only have Type I as parent,
    except for Type II-Infinity. Type III can have
    Type I, III, or Type II-Infinity as parent. Type
    II-Infinity can have type I, III, or Type
    II-Infinity as parent.

25
Our Scheduler
Type I
f11
f12
f13
Type II
Type III
f21
f22
Type II- Infinity
3
1, d1
2, d2
r31
r32
3
1, d3
2, d4
r41
r42
1
2
3
r51
r52
r53
26
Time-Varying Pipe
r21
r22
r23
27
Key Features
  • For all children of a Type I or III class,
    bandwidth is defined on comparable timescale.
  • Priority classes are added.
  • The representation is actually a general
    scheduler (in CBQ terminology), not a
    link-sharing representation (link-sharing
    requirement should be kept separately, not
    necessarily in tree structure).

28
A Scheduler Implementation
  • The immediate children of a class are scheduled
    as follows
  • Type I classes are scheduled by WFQ.
  • A Type II classes are numbered by 1,2,,n, which
    stand for their scheduling priority. For
    instance, a class with a lower delay bound takes
    priority over one with a higher delay bound. When
    two Type II classes have the same delay bound,
    the one with smaller p_i value takes priority
    over the one with larger p_i value. Type
    II-Infinity classes are numbered a priori.
  • Type III classes are scheduled according to WFQ
    among themselves.

29
Admission Control and Usage Accounting
  • To guarantee delay, admission control is
    necessary for ordinary Type II classes.
  • To guarantee minimum rate, admission control is
    necessary for Type III classes.
  • Admission control is aided by usage accounting.
  • Additional connection classes can be defined
    outside the scheduler.

30
Overall Architecture
Usage Accounting
Class Management
Admission Control / Policing
Classifier
Scheduler Adjustment
Pricing
User
Kernel
Scheduler Measurement
Scheduler
About PowerShow.com