State of the Art in Differentiated

Transcription

1 Outlne Dfferentated Servces on the Internet Explct Allocaton of Best Effort Packet Delvery Servce, D. Clark and W. Fang A Two bt Dfferentated Servces Archtecture for the Internet, K. Nchols, V. Jacobson, L. Zhang Dfferentated Servces on the Internet LIRA: How to Reconclate DffServ and IntServ LIRA: An Approach for Servce Dfferentaton on the Internet, I. Stoca and H. Zhang Proportonal Dfferentated Servces Proportonal Dfferentated Servces: Delay Dfferentaton and Packet Schedulng, C. Dovrols, D. Stlads, P. Ramanathan Clark s Framework Rght now: best effort servce, therefore unpredctable at a congeston pont reles on the total capacty of the congeston pont, regardless of the traffc) Expected capacty: n tmes of congeston, all connectons should slow down to an expected rate Dfferent users => Dfferent expectatons => Dfferent levels => Dfferent rates Push the complexty at the edges of the network only smple modfcatons to the core routers). $ % # "! State of the Art n Dfferentated Servces Clark, Jacobson: two complementary approaches that were the startng pont for DffServ. Resulted after modfcatons n an IETF draft. Clark: expected capacty "Dfferent levels of best effort servce n tmes of network congeston" Jacobson: premum and assured servce Defnes three classes of servce premum, assured, best effort)

2 Sender Based Scheme The expected capacty framework: Issues n Defnng a Profle Traffc Specs: what s exactly provded to the customer e.g., bandwdth) Guaranteed rate Geographc Scope: to whch destnatons) does ths servce apply? Set of IP addresses Statstcal Assurance: wth what level of assurance s the servce provded? Packets losses Sender Based Scheme Cont d) A meter exsts at the entry of the network e, rght at the connecton pont of the user). Ths meter tags the packets as beng n profle or out of profle accordng to the profle defned for the user. The gateways along the path drop then the packets dfferently f they are IN or OUT. Need to desgn the meter carefully: the traffc can be really bursty=> more complexty Two Types of Assurance Absolute: needs some reservaton of the path, hard guarantees: more IntServ lke. Low probablty of falure: approach adopted by Clark and Wang.

3 Recever Based Scheme Problem wth Sender Based: what f the sender cheats? => need for another scheme, based on the recever e.g., the ISP) Recever Based Scheme Cont d) The recever chooses then to turn off the ECN bt f the packet remans n profle or to leave t on f the packet s out of profle. No packets are actually dropped n ths scheme. It reles on the "good wll" of the sender that has to slow down f t receves some acknowledgements wth the ECN bt on. Recever Based Scheme Uses an add n to TCP: the Explct Congeston Notfcaton ECN) bt The ECN bt s set by the gateways f the network s loaded n a normal scheme, they would drop the packet). Ths ECN bt s then coped n the acknowledgement packet to nform the sender that t must slow down. Sender Based vs. Recever Based Advantages of sender based: Explct treatment.e., possble droppng) of packets Dstncton between n profle and out profle packets s straghtforward. Advantages of recever based: No possblty of cheatng for the sender Conveys dynamc nformaton about congeston level along the path

4 ) * The Droppng Algorthm Need to keep t smple scalablty) but general enough so that t wll not be modfed over tme Need to effcently use TCP: two possble behavors when some packets get dropped Fast Recovery: only a couple of packets got dropped. TCP cuts ts wndow sze n half, and then ncrease t by one packet every round trp tme. Slow Start: occurs when a large number of packets got dropped. TCP wats for the retransmsson tmer, the wndow sze s set to one packet and ncreases lnearly after a threshold. => SHOULD BE AVOIDED!!! The TSW Tagger TSW: Tme Sldng Wndow. Two components: A rate estmator used to smooth TCP s nherent burstness. It estmates the rate upon each packet arrval and forgets the past hstory over tme. The goal s to have a rate estmator that s ndependent of the speed of the TCP connecton tself. A taggng algorthm RIO and RED RED: Random Early Drop RIO: Random Early Drop wth In/Out Bt. RIO actually uses twn RED algorthms, one for packets that are n profle, one for packets that are out of profle. The TSW Tagger Cont d) Two approaches are possble for the taggng algorthm: Use a long past hstory one full sawtooth between 0.66Rt and 1.33Rt, Rt s the target rate) and tag packets as beng out when: avg rate avg rate Use a short past hstory of one RTT and look for a sawtooth exceedng 1.33Rt => the packets are then tagged as beng out. The second approach s useful when the tagger s close to the host Rt 0

5 The TSW Tagger Example) The actual algorthm used s: Jacobson s Approach Proposes three dfferent levels of servce: Premum Servce Assured Servce smlar to Clark s approach) Best Effort Servce Two bt archtecture: Packets gets dfferentated by two bts n ther header e.g., the IP Type Of Servce TOS) byte) Premum bt P bt) Assured Servce bt A bt) Issues n desgnng TSW/RIO Dfferent RTT mply dfferent behavor for the TCP wndow => closer connectons are able to recover more quckly. Need to know the RTT to acheve farness, or to guess t Need to avod taggng a full cluster of packets as beng out n order to stay n FastRecovery mode Need to use a probablstc functon to space the packets beng tagged out The Premum Servce Hard lmted to ts peak provsonng rate Shaped to prevent the traffc bursts from beng njected nto the network Specfed by a desred peak bt rate Equvalent to a vrtual leased lne

6 The Premum Servce Cont d) How does t work? The frst hop router leaf router) turns the P bt on and shapes/smoothes the traffc Modfcatons needed n the routers: send Premum packets frst, and the rest after Ths mples two levels of prortes, and possbly two queues n the routers to avod sortng. The polcy s set up at the edges of the network wth a token bucket mechansm The Complete Framework The routers shall provde three dfferent types of servce Premum, Assured, or Best Effort) Packets pass through markers: ther A and P bts are cleared, then set f the flow s n conformance wth ts profle The P bt s turned on possbly after the packet has been hold to reman n conformance wth the peak rate: Non work conservng approach Ths shall be handled at the leaf router The Premum Servce Cont d) What does happen when the packets exceed the rate? Two possbltes: Dscard them. Downgrade ther prorty: ths s actually bad snce t can enttal out of order packet delvery. => Need to correctly sze the queues of Premum packets to prevent them from beng dropped Low delay varaton than Clark s approach f the queue s correctly szed. The Packet Marker Descrbed by the followng pcture:

7 Output Confguraton of the Router The Border Router The Implementaton The Marked Traffc Leaf routers need a flow specfcaton and a general classfer. The flow specfcaton can be assured by a sgnalng protocol such as RSVP or SNMP. Bt pattern classfer Bt setter Prorty queues Shapng Token Bucket) Polcng Border routers) Two ways of allocatng the level of marked traffc throughout the Internet: Provsonng: statc guarantees Call set up: flow specfcatons are used for a gven flow. The scheme can evolve nto a more complex archtecture f needed Herarchcal flters to dfferentate the flows among the dfferent levels of servce provded.

8 The Bandwdth Brokers The Bandwdth Brokers Example) Needed to automate the dfferentaton Two functons: Settng up the local routers leaf routers) to allow the dfferentaton. Managng the messages passed at the edges of the network e, doman boundares) The user "talks" wth the BB to set up the property of a gven flow. The BB s actually a knd of polcy server possbly usng authentcaton methods) Let us consder the followng example: The Complete Archtecture Concluson of the frst part We have shown two complementary schemes. The second s more general, and uses the results of the frst one. Noton of dfferent levels of mportance => has evolved nto a concept of classes. Share some characterstcs wth IntServ, but: less overhead: the sgnalng s not performed on a per hop bass, but only at the edges of the network Interestng n the sense that the core routers should not be affected works on aggregate traffcs, and not on a specfc flow n general contradcton wth Jacobson s analyss?)

9 , Towards Proportonal Dfferentated Servces The ntal approach was perhaps too greedy "any" destnaton n the Internet s stll a problem depends on the RTT: need to evaluate t. Or other problem: underutlzaton of the lnk n case of large spatal granulartes. New approach: provde proportonal dfferentated servces LIRA, PDS The Bg Pcture Problem: The network needs to provson resources to all destnatonsbecause t does not know where the packets shall go => dffcult to support a fxed bandwdth profle and a hgh utlzaton of the lnk at the same tme LIRA s dea based on shapng): Use a token bucket to determne whch packets can go through LIRA Takes Clark s approach as ts startng pont: "The key dfference between Intserv and Dffserv s that whle Intserv provded end to end QoS servce on a per flow bass, Dffserv s ntented to provde servce dfferentaton among the traffc aggregates to dfferent users over a long tmescale " LIRA=Locaton Independent Resource Accountng. Man goal: allevate the "any" destnaton problem The Resource Token Bucket Idea: the number of tokens needed to admt a preferred packet s a dynamc functon of the path t traverses Example of functon: the number of tokens can be equal to the cost of the lnk, defned by: C +a 1 u t wth u t -Rt), C beng the capacty C of the lnk The cost functon has to dverge when the utlzaton tends to 100%, and has to be a constant "dle cost" when the lnk s not utlzed.

10 0 / 1. The Resource Token Bucket Cont d) Problem wth the prevous functon: not adapted to a real envronment: Such a functon has to be computed perodcally because of the overhead. Therefore, results mght be obsolete when they are used! Crtcal problem, snce the functon dverges and the lnk utlzaton can drastcally change n a short amount of tme Multpath Routng n LIRA Need to ensure that all packets belongng to the same flow are forwarded along the same path. Otherwse: possble out of order delvery of the packets => bad performance, ncreases overall nstablty. A "Better" Cost Functon The soluton: use an teratve formula to mnmze the varatons Advantages: Defned even f the lnk s congested. Smoother when the lnk utlzaton approaches 100% ncreases by a every teraton). Problem: c t Actually too smooth! When the lnk becomes congested, only a couple of teratons should be needed, otherwse we ll need to drop tagged packets. Soluton: use C = traffc a c t 1 Rt),t 1)) C C for the marked Multpath Routng n LIRA Cont d) Soluton: the "XOR" scheme:

11 More farness Path Selecton How to choose a route? Use a probablstc functon to select a route: Each tme a cost s updated, the routes are splt n two sets: Hgher cost Lower cost Then the probablty of pckng a route n the lower cost set s ncreased by Converges to the optmal soluton wthn steady state system. n a Smulaton Results Load balancng and dynamc routng may hurt when the load s already balanced: Overhead due to the computaton of the cost functon and the probablstc choce may actually pck a longer route Otherwse we acheve a better lnk utlzaton Better throughput Route Aggregaton Generalzaton of the prevous algorthm for egress nodes nstead of destnatons. Need to perform cost aggregaton: cost r 1, d 0,d 3cost r1,d 0 1 R r 1,d 0 R r 1,d 0 R r 1,d 1 5cost r1,d 1 R r 1,d 0 R r 1,d 1 R r 1,d 1 Problem wth ths approach: need to mantan per flow state and perform packet classfcaton at a core router r1 n the prevous example) Concluson on LIRA Abandon the dea of absolute bandwdth Smple mechansm token bucket lke) manages to acheve better lnk utlzaton Frst step towards Proportonal Dfferentated Servces

12 < B A C N B A C B A Requrements Relatve dfferentaton between classes should be: 2 Predctable: Dfferentaton ndependent of the varaton and dstrbuton of the class loads. 1 Controllable: Should be adjusted by tunng any selected crtera In terms of queung delays, we want to have somethng of the form: d I d j I j 1) The Dynamcs Cont d) 3) n turns leads to the followng propertes: N The average delay of a class s ncreasng wth the arrval rate of every class 2 1 Increasng load n hgher classes cause larger ncreases n the class average delays than ncreasng load n lower classes Proportonal Dfferentated Servces If the delay dfferentaton parameter of a certan class ncreases, the average delay of all other classes decreases whle the average delay of that class ncreases Ongong research: the paper has been wrtten n January 1999! Based on the assumpton that "some form of route pnnng may be necessary for mplementng such servces [Premum, Assured]". Does not offer absolute bandwdth guarantees, only relatve guarantees Two levels of dfferentaton: Queung delays we wll focus on ths ssue) Packets losses The Dynamcs be the aggregate arrval rate n the system, the ndvdual arrvals of each flow. Let and 2) N; d < = d We have: Where d) s the average queung delay that would result s the aggregate traffc was servces by a work conservng FCFS server of the same capacty as the scheduler that enforces the proportonal delay model. > A d >? 1) and 2) mply: d C D

13 E H J E E GF GF GF L L O N M Feasblty of a Set of Deltas Exstng Schedulers Statc Prorty: Does not work because one cannot adjust the delay between the classes. Besdes the lower classes can experence servce starvaton Weghted Far Queung: Proportonal bandwdth does not mply proportonal delay dfferentaton, unless the characterstc of the flow are known a pror Earlest Deadlne Frst: could work but n an absolute mode only The WTP Scheduler Watng Tme Prorty Is there a work conservng sched that satsfes 1)? Proposed by Klenrock n 1964 We need to have an "feasble" set of average delays d d Characterzed by: p t w t s Problem: need a dynamc reorderng of the prorty queues: H I J K H I n the set of nonempty Ths set of nequaltes should hold for all proper subsets of {1,2,...,N}. The second term on the rght s the average delay that the aggregate traffc of the classes n would experence n a work conservng FCFS server. To summarze: The average backlog of a subset of classes cannot be lower than the backlog of these classes n a FCFS server. The BPR Scheduler Backlog Proportonal Rate The servce rate allocaton satsfes: q t q j t s j s j r t r j t Where {s} are the Scheduler Dfferentaton Parameters, drectly lnked to the {} they are the nverse of the latter, r s the rate and q s the queue length. s Clam: the relatve watng tmes tend to j s Drawback: Need to be approxmated flud j flow model)

14 R The WTP Scheduler Cont d) Second drawback: If R<R peak nput rate) and: then a sequence of n consecutve class j packets that starts arrvng at tme t wll be servces before any class packets that arrved at t or later Can lead to starvaton n the lower classes untl a burst n a hgher class s completely servced! 1 PR R I Qs wth s s j s j Concluson on PDS Interestng approach, more lkely to be feasble and scalable than Absolute Dfferentated Servces. However, the studes are ncomplete hgh utlzaton of the lnk only) Current work n progress Probably need to use some of the IntServ capabltes e.g., RsvP) to acheve all of these goals. Evaluaton Both BPR and WTP satsfy the crtera when the lnk utlzaton tends to 100%. Actually the results seem vald for a lnk utlzaton greater than 90%. It seems that WTP s more approprate tends more quckly to the desred dfferentaton) Does t work also for short lved flows? short tmescales)