Design Philosophy of Scheduler Design a very general and flexible scheduler at transport layer that can –work at different locations in the network –provide.

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.

Client 1

Server 1

ISP 1

Backbone Network

Client 2Server 2ISP 2

ISP 3

ISP 4

Original Model – Scheduler at the End-Systems

Connection Relationships

Corporate Network

T1/T3ISP

Backbone NetworkCorporate Intranet

Client

Rate Control Device

Access Link

ISP Network and Server Farms

Home Clients Backbone Network

POP

ISP Network

Layer4/7 Switch

Server Farm

Inter-Domain Scenario

Backbone

Domain A

Client

Domain C

Domain B

Edge Device

Access Link

Fat Pipe

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 manager requests that connections from his department be

given a combined bandwidth of .• Based on the company's mission, the administrator specifies

that database traffic be given a bandwidth 2 and realtime video traffic be given a bandwidth . He also specifies that realtime video be given a delay guarantee of d with probability 1- .

• The administrator decides that all users should be given equal bandwidth.

H-PFQ (Bennett and Zhang 96)

Link

AgencyA

AgencyC

AgencyB

10%40%50%

real-time

ftptelnet

10%10%

30%

real-time

ftptelnet

5%2%3%

IP DEC-net

20%

20%

conn.1

conn.n

1%1%

ftptelnet

0%5%15%

real-time...

...

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

AgencyA

AgencyB

80%20%

real-time

ftpinter-active

real-time

ftpinter-active

3, 30%2, 25%1, 25%3, 10%2, 5%1, 5%

Our SchedulerType I

Type II

Type III

11 12 13

21 22

r41 r42

r31 r32

r51 r52 r53

Type II-Infinity

1, d1 2, d2

1, d3 2, d4

3

3

1 2 3

An Instance

Link

Real-time

Elastic

Buf.video ftp

33%67%

Inter-active

1, d1 2, d2

3

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 operator’s objectives: bandwidth utilization, revenue, or combined user’s satisfactions, subject to constraints.

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.

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.

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.

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.

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%

video ftp

20%60%

video1 video2 ftp1 ftp2

2, 5%2, 15%1, 40%1, 20%

80%

video ftp

2

1

ftp1 ftp2

33%67%

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.

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.

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

audio mailftptelnetvideo

Link

AgencyA

AgencyC

AgencyB

20% 50% 10% 20% 0% 10%40%50%

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

AgencyA

AgencyC

Video

10%40%50%

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.

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.

Scheduler Definition

• Define three classes – Type I: bandwidth guaranteed on shortest time scale. Each

class is associated with a number i, which is the rate assignment for the class.

– Type II: delay guarantee is characterized by a tuple (di, pi, ri), indicating Pr(D > di) < 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.

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.

Our SchedulerType I

Type II

Type III

11 12 13

21 22

r41 r42

r31 r32

r51 r52 r53

Type II-Infinity

1, d1 2, d2

1, d3 2, d4

3

3

1 2 3

Time-Varying Pipe

r21 r22 r23

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).

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.

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.

Overall Architecture

SchedulerSchedulerMeasurement

Classifier

Usage Accounting

AdmissionControl /Policing

Pricing

Kernel

UserSchedulerAdjustment

Class Management