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