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. Client 1 Server 1 ISP 1 Backbone Network Client 2 Server 2 ISP 2 ISP 3 ISP 4 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 Home Clients Backbone Network POP ISP Network Layer4/7 Switch Server Farm

5. Inter-Domain Scenario Backbone Domain A Client Domain C Domain B Edge Device 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 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.

7. H-PFQ ( Bennett and Zhang 96 ) Link Agency A Agency C Agency B 10% 40%50% real- time ftptelnet 10% 30% real- time ftptelnet 5%2%3% IPDEC- net 20% conn. 1 conn. n 1% ftptelnet 0%5%15% real- time...

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 Agency A Agency B 80% 20% real- time ftp inter- active real- time ftp inter- active 3, 30%2, 25%1, 25%3, 10%2, 5%1, 5%

9. Our Scheduler Type I Type II Type III  11  12  13  21  22 r 41 r 42 r 31 r 32 r 51 r 52 r 53 Type II- Infinity 1, d 1 2, d 2 1, d 3 2, d 4 3 3 123

10. An Instance Link Real- time Elastic Buf. video ftp 33%67% Inter- active 1, d 1 2, d 2 3

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 operator’s objectives: bandwidth utilization, revenue, or combined user’s 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% videoftp 20% 60% video1video2ftp1ftp2 2, 5%2, 15%1, 40%1, 20% 80% videoftp 2 1 ftp1ftp2 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 audiomailftptelnetvideo Link Agency A Agency C Agency B 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  i, which is the rate assignment for the class. –Type II: delay guarantee is characterized by a tuple (d i, p i, r i ), indicating Pr(D > d i ) < p i, where D is the queueing delay. Note that d i can be infinity. The optional r i 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 (m i,r i ), where the m i is the minimum rate and r i 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 Type II Type III  11  12  13  21  22 r 41 r 42 r 31 r 32 r 51 r 52 r 53 Type II- Infinity 1, d 1 2, d 2 1, d 3 2, d 4 3 3 123

26. Time-Varying Pipe r 21 r 22 r 23

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 Scheduler Measurement Classifier Usage Accounting Admission Control / Policing Pricing Kernel User Scheduler Adjustment Class Management