Quality-of-Service in IP Networks

Transcription

1 Qualty-of-Servce n IP Networks Roch Guérn Unversty of Pennsylvana IEEE RTAS 2000 Washngton, D.C. May 30, 2000 Introducton Outlne Defnton of Qualty-of-Servce Goals and requrements Freshenng up on basc buldng blocks Traffc contracts Schedulng and buffer management Call admsson The Internet approaches A frst step Dfferentated Servces Gong all the way (maybe) Integrated Servces and RSVP Summary and references Roch Guern 1

2 Delverng Dfferent Levels of Servce Focus so far has been on mechansms related to provdng connectvty,.e., delverng data from source to destnaton Routng protocols establsh forwardng state Forwardng mechansm determnes where to send packets next But what f I want more than just bare connectvty Guarantees regardng Avalable bandwdth (mnmum or sustaned), bounds on delay or delay varatons, losses, etc. Quanttatve (worst case or statstcal) or qualtatve (better than) performance measures Servce classes provde dfferent combnatons of servce guarantees above and beyond connectvty Servce Dfferentaton Two major components to servce dfferentaton Data path dentfes packets elgble for servce guarantees and enforces them Control path determnes f and how guarantees can be provded Data path Packet classfers whch packet s enttled to what Schedulng controls access to transmsson opportuntes Buffer management controls access to storage opportuntes Control path (call admsson) Based on traffc characterstcs type of servce guarantees current network state (avalable resources) Multple tme scales possble from provsonng to on-demand (sgnallng) Roch Guern 2

3 Freshenng Up Buldng Blocks Traffc characterstcs How to descrbe the set of packets that are to receve a certan level of servce? Schedulng Whch packet goes out next? What guarantees? Effcency vs complexty Buffer management Whch packets to store? What guarantees? Effcency vs complexty Couplng to schedulng Roch Guern 3

4 Overvew of Traffc Characterstcs Purpose Specfy the traffc (set of packets) to whch the servce guarantees apples Requrements Smplcty of expresson Ease of verfcaton Implementaton complexty and scalablty Generc method Token bucket a.k.a. leaky bucket Determnstc algorthm that bounds traffc Controls rate and burst sze data Basc Module Operaton Enforce rate lmts whle allowng some burstness Identfy (sldng) tme wndow over whch to enforce rate lmt tag or dscard (or hold) rate + margn rate lost transmsson opportuntes margn tme Roch Guern 4

5 The Pessmst Token Bucket Defnton Token bucket lmts flow of packets nto the network Packets generate tokens (n proporton to ther sze) upon enterng the network Tokens dran at a contracted token rate (r) Lmt (b) on the defct a user can run In the presence of too hgh a defct, packets are Dropped, marked, or shaped packet arrves packet queue (maybe) Token bucket keeps track or your defct Orgns of the bucket analogy Each packet pours water n the bucket Water drans at fxed rate Bucket overflows when full of water enough room? leaky bucket of sze b token dranage rate r packet departs The Optmst Token Bucket Defnton Token bucket lmts flow of packets nto the network Packets requre credts to enter (n proporton to ther sze) Credts/tokens accumulate at a contracted token rate (r) Lmt (b) on the number of credts that can be accumulated In the presence of nsuffcent credts packets are Dropped, marked, or shaped packet arrves packet queue (maybe) enough credts? packet departs Token bucket keeps track or your remanng credt token bucket b token generaton r Roch Guern 5

6 Concatenaton of Buckets Multple buckets can be concatenated to control multple rates Rate s mnmum across all buckets b 1 b 2 b 3 r 1 r 2 r 3 r 1 r 2 r 3 b 3 b 2 b 1 bytes b M t p b M p r The Dual Token Bucket Token bucket lmts short and long term rates pb p r A(t) <= M + mn[pt, rt+b-m] Maxmum burst sze b p r r A(t) Worst case traffc envelope wth max sze (M) packets Worst case traffc envelope wth 1-bt packets Maxmum burst duraton p: peak rate r: token rate b: token bucket M: max pkt sze t Roch Guern 6

7 Maxmum Burst Sze b Why s maxmum burst sze? p r Tme to use up ntal token pool: t 0 =b/p By tme t 0, N 0 tokens have been accumulated: N 0 =r t 0 =rb/p Those N 0 tokens are used up n tme t 1 = N 0 /p= rb/p 2 After tme t 1, N 1 tokens have been accumulated: N 1 =r t 1 =r 2 b/p 2 And so on b r Total tme to run out of tokens s Tb = p = 0 p Smpler dervaton based on flud model Tme to dran b at rate p-r T b = b p 1 r 1 p b = p r Droppng/Markng Mode bytes dropped or marked A (t) r A(t) b p b M t0 p r p r) t ( b M ) ( p r) = ( 0 M b M p r t 0 t Roch Guern 7

8 Shapng Mode bytes A (t) r M + pt 0 p t1 = t0 r A(t) = rt + b 1 b M r b p M b M p r t 0 t 1 t t 1 -t 0 : Maxmum shapng delay bytes b p Shapng Mode - Buffer (BF) Szng BF + ( b M ) t1 = p r dropped = ( p r) t A (t) A(t) r dropped 0 BF ( b M ) shaped M b M p r t 1 t 0 t 2 t Roch Guern 8

9 Contnuous State Leaky Bucket Algorthm X =X-r*(t a (k)-lct) Approach: Mantan runnng count X of token defct non conformng pkt Y X < 0 N X +pkt > B N Y X = 0 X = X + pkt LCT = t a (k) conformng pkt LCT: last conformance tme t a (k): arrval tme of pkt k X: token defct (n bytes) pkt: packet sze r*(t a (k)-lct): potental credt accumulated snce arrval of last conformant pkt Other Token Bucket Varatons (1) Sngle rate three color marker Extends burst sze lmt to allow two prorty levels Three colors dentfy outcome of conformance test green=conformant yellow=non-conformant but wthn lmt of excess burst red= non-conformant and beyond excess burst Essentally same algorthm as used n Frame Relay Parameters Commtted Informaton Rate (CIR) Commtted Burst Sze (CBS) Commtted token count (Tc) Excess Burst Sze (EBS) Excess token count (Te) Operaton Tc=mn(CBS, Tc+CIR* t) Te= mn(ebs, Te+CIR* t) Tc-p<0? N Tc:=Tc-s green packet packet of sze s arrves at tme t t=t-t0 t:=t0 Y Te-p<0? N Te:=Te-s yellow packet Y red packet Roch Guern 9

10 Other Token Bucket Varatons (2) Two rates three color marker Separate control for peak rate and commtted rate wth ndvdual burst szes Smlar to ATM dual leaky bucket but does not mandate dscardng of packets that do not conform to peak rate contract Markng Red f fals peak rate check Yellow f pass peak rate check but fals commtted rate check Green f pass both checks Parameters Commtted Informaton Rate (CIR) Commtted Burst Sze (CBS) Commtted token count (Tc) Peak Informaton Rate (PIR) Peak Burst Sze (PBS) Peak token count (Tp) Operaton packet of sze s arrves at tme t Tc=mn(CBS, Tc+CIR* t) Tp= mn(pbs, Tp+PIR* t) Tp-s<0? Y red packet t=t-t0 t:=t0 N Tc-s<0? Y Tp:=Tp-s N Tp:=Tp-s Tc:=Tc-s yellow packet green packet Schedulng & Buffer Management Where are they used? Any place where congeston can occur What are they? Data path mechansms that makes storage and transmsson decsons on packets What do they do? enforce servce guarantees and/or far access to resources Packets IN Address Lookup Where to? SWITCH Schedulng Buffer Management How to? Packets OUT Installed by Sgnallng Installed by Routng Installed by Sgnallng Predefned (carred n packet) Roch Guern 10

11 Buffer Management and Schedulng Goals Buffer management When to drop or accept a packet Schedulng Whch packet to send next Man goals Servce guarantees bandwdth, delay, loss, etc. Sharng of excess resources Far sharng Mnmze data and control paths ht Mnmze per-packet processng requrements Smple decsons on whether a new flow can be admtted Input Lnks Buffer management Packet Buffer IN or OUT Scheduler Output Lnk Types of guarantees Schedulng Bandwdth: Make sure that a gven flow gets enough transmsson opportuntes when t has packets watng to be transmtted (s backlogged) Need to defne nterval over whch ths s measured Delay: Ensure upper bound on the maxmum (average) amount of tme a packet can wat n the buffer Jtter: Provde bound on the delay dfference of consecutve packet transmssons (for the same flow) Farness Dstrbuton of excess bandwdth (E) across actve connectons E = C - Σ(reservatons) Far allocaton gves each one of N actve connectons E/N n addton to ther reserved rate Roch Guern 11

12 Schedulng Mechansms and Characterstcs Basc propertes Basc schedulng buldng Flow solaton block Ablty to guarantee servce to one flow ndependent of the behavor of other flows Compute desred transmsson tme of packets Important f ncomng traffc s not constraned Based on servce (leaky bucket) guarantees for each flow Support of excess traffc and farness Transmt packet wth the If you send more than you are enttled to but smallest one resources are avalable, can you take advantage of t and f yes, how much? Schedulers dffer n how they compute desred How much devaton from the farest scheduler transmsson tmes Implementaton complexty Computaton of packet transmsson tmes Selecton and update of next packet to transmt Effcency For a gven set of guarantees and level of avalable resources, how many flows can I accept Local vs end-to-end effcency (network settng) Schedulers Examples (1) Frst-Come-Frst-Served (FCFS) Packets are served n the order they arrve Desred transmsson tme s tme of arrval Propertes Very smple to mplement Delay guarantees proportonal to buffer sze No flow solaton or bandwdth guarantees One flow can hog the entre lnk f unconstraned Prorty queue Multple FCFS queues, where hgh prorty queues always transmt before lower prorty ones Desred transmsson tme s tme of arrval plus very large constant (C 1 <C 2 <...<C N ) Class s guaranteed better delay than class j for <j Lower prorty classes can be starved Isolaton s only from lower prorty classes Remans smple to mplement (for few classes) Roch Guern 12

13 Scheduler Analyss (1) FCFS scheduled can be analyzed usng M/M/1 or M/G/1 queueng models Analyss of prorty queue can be done usng M/G/1 wth prorty Average watng tme W k for packets of class k s W k N 2 λ X = 1 = 2(1 ρ1 L ρk 1)(1 ρ1 L ρk ) where λ s packet arrval rate for class, ρ s load nduced by 2 class (ρ = λ /µ ), and X s the second moment of the transmsson tme of packets of class Can go to nfnty when the total load of hgher prorty classes exceeds 1 More Scheduler Examples Weghted Round-Robn & Vrtual Clock Problems wth prevous schedulers Hard to precsely allocate ndvdual bandwdth guarantees Weghted Round-Robn Each flow has ts own queue and weght w Server vsts each queue n turn and transmts w packets (bts) Smple but lmted flexblty n allocatng bandwdth & handlng varable sze packets Vrtual Clock Basc dea s to make packet prorty a functon of the rate allocated to ts flow Flow j s allocated r j k On arrval of packet k of length L j, prorty of packet k s set to k L k k 1 j W j = W j + rj Packets are transmtted n order of prorty w 1 w 2 w 3 w 4 w = IN r 1 =1/ r 2 =1/ r 3 =1/ OUT FCFS VC Roch Guern 13

14 Problems Wth Vrtual Clock Prorty accumulaton when dle Idle flow can shut-off other flows for extended perods of tme Soluton: Dsallow accumulaton W a k j k j = max( W k 1 j :arrval tme of k L k j, a j ) + r packet k of flow j Problem wth prevous soluton Penalze excess usage even when no one else needed the bandwdth Flow can be shutoff for extended perods f t prevously used dle bandwdth Unacceptable n the context of packet networks and adaptve applcatons j IN r 1 =1/ r 2 =1/ r 3 =1/3 OUT IN r 1 =1/ r 2 =1/ r 3 =1/3 OUT Improvng on Vrtual Clock Weghted Far Queueng (WFQ) Based on dealzed flud flow model,.e., φ 1 Generalzed Processor Sharng (GPS) φ Server can serve an nfntesmal amount 2 r 2 r (one bt) of data at each vst Frequency of vst based on weghts, φ 3 r 3 amount served so far, and actve flows φ 4 r 4 5 Server keeps rate allocated to each flow proportonal to ts weght φ φ 5 r 5 φ = 1 Requrements φ Each flow s assgned ts own queue 1 φ2 φ3 φ4 φ5 Track and contnuously compute amount φ j transmtted for each actve flow rj = r, j = 2,3,4,5 5 Characterstcs Provdes rate and delay guarantees φ = 2 Enforces flow solaton Rate guarantee and far allocaton Far sharng of excess bandwdth of excess bandwdth 1 Roch Guern 14

15 GPS Example Three flows wth weghts/rates φ 1 =1/2, φ 2 =1/3, φ 3 =1/6 Intally, only flows 2 and 3 are actve 1/ 3 1/ 6 r2 = = 2 / 3; r3 = = 1/ 3 1/ 3 + 1/ 6 1/ 3 + 1/ 6 Flows 1, 2, and 3 are ultmately actve 1/ 2 1/ 3 1/ 6 r = 1 = 1/ 2, r2 = = 1/ 3; 3 = = 1/ 6 1/ 2 + 1/ 3 + 1/ 6 1/ 2 + 1/ 3 + 1/ 6 r 1/ 2 + 1/ 3 + 1/ 6 IN r 1 =1/2 r 2 =1/3 r 3 =1/6 OUT From Flud to Packets How much devaton from the flud model (GPS) do packets (PGPS=WFQ) ntroduce and how to mnmze t? Cannot nterrupt packet transmsson once started Granularty n how transmsson opportuntes are allocated Inablty to change decson even f hgher prorty (allocated rate) packets arrve Approach Emulate the flud system (GPS) as closely as possble Desred transmsson tme s fnsh transmsson tme n flud system Select packet wth smallest fnsh transmsson tme n the flud system (assumng there would be no more arrvals after ths tme) Issues Can we bound dscrepances wth flud model (PGPS vs GPS)? Complexty of smulatng the flud system to keep track of ts transmsson tmes Roch Guern 15

16 Boundng The Dfference Wth Flud Model Basc results Packet fnsh transmsson tmes n PGPS are at most one maxmum sze packet later than n GPS Note: Ths s only an upper L p Fˆ max bound,.e., WFQ could be, p Fp < sgnfcantly ahead of GPS r L max s maxmum packet sze, r s lnk rate, F p s fnsh tme of pth packet n GPS, and Fˆp s fnsh tme of pth packet n PGPS Queue szes n PGPS and GPS s at most one maxmum sze packet larger than n GPS t, Qˆ ( t) Q ( t) L Basc mplementaton ssue s computaton of fnsh tmes n flud system max Hard to track and contnuously update Soluton based on vrtual tme approach, Keep track of the margnal rate at whch backlogged sessons receve servce, and update at each event (packet arrval and departures) Vrtual Tme n Flud Model Vrtual tme measures the margnal rate at whch far servce should be gven Enables trackng of how much servce each flow should have receved Prevously dle flow becomng actve changes the rate at whch the vrtual tme evolves Newly actve flow becomes mmedately elgble for servce, but only from the correspondng vrtual tme level No credt for perod when dle Man ssue s to determne smple method for computng vrtual tme evoluton Vrtual tme V(t) evolves as V(t) t t 2 t 1 t 0 dle B j t φ dle φ 1 φ 2 φ 3 φ 4 t 0 t 1 t 2 t Roch Guern 16

17 A Vrtual Tme Implementaton of WFQ The vrtual tme V(t) captures the evoluton of the rate of servce for backlogged connecton V τ ) ( t j 1 + ) = V ( t j 1 + t φ B j Usng vrtual tme to compute packet transmsson tmes (servce tags) n GPS k k 1 k S = max F, V ( a ) Defne vrtual start and fnsh servce tmes for packet k rφ Advantages of vrtual start and fnsh servce tmes Updated only at packet arrvals and departures Vrtual fnsh tme can be determned at packet arrval tme Packet are served n order of vrtual fnsh tme Worst case complexty can be O(N) for N connectons F where B j s the set of backlogged connectons between tmes t j and t j-1 k = S k + { } L k (defnton) (Why?) End-to-End vs Sngle Node Performance (1) Latency Rate Server (LRS) framework Defnton: An LRS server s characterzed by two parameters, r and Θ, for sesson, such that for all tme ntervals (τ, t] durng whch sesson s contnuously backlogged, the amount of servce W,j (τ,t) offered to sesson s lower bounded by W ( τ, t) max Basc model characterstcs ( 0, r ( t τ Θ )), j Ablty to provde rate guarantees to ndvdual flows Bounded rregularty n how servce s delvered,.e., latency L Lmax Example: WFQ has a latency of + r r (L s maxmum packet sze for sesson, and r s lnk speed) Queston s how do sngle node guarantees translate nto end-to-end guarantees,.e., end-to-end delay bound? Roch Guern 17

18 End-to-End vs Sngle Node Performance (2) Traffc envelope In order to bound delay, we need to know how much traffc a flow s njectng Traffc envelope specfed through token bucket (P,ρ,σ ),.,e., ( σ + ρ ( t τ ), P ( t τ )), t, τ andτ t A ( τ, t) mn < Basc result on concatenaton of LRS Two LRS n seres wth latences Θ 1 and Θ 2 are equvalent to a sngle LRS wth latency Θ = Θ 1 + Θ 2 Bound on end-to-end delay through N LRS s then gven by N P r σ j D + Θ r P ρ j= 1 j where Θ s the latency of the jth LRS for flow Bound on buffer requrements at kth LRS s also avalable k σ j B ( P r ) + ρ Θ P ρ j= 1 Call Admsson and Servce Guarantees Wth WFQ Call admsson decdes f a new flow can be accepted Rate guarantee: new flow s enttled to rate r =φ r Delay guarantee: new (P,ρ,σ ) flow needs rate r to ensure ts end-to-end delay bound Call admsson rule smply requres that r r Buffer szng also needed (depends on poston n path - see Guaranteed Servce model) Servce guarantees Rate guarantee End-to-end delay guarantee Far access to excess bandwdth But lmted jtter control Roch Guern 18

19 Other Schedulers n The LRS Famly (1) Self-Clocked Far Queueng (SCFQ) Smlar to WFQ but ams at smpler computatons of vrtual fnsh tmes,.e., avods trackng GPS Vrtual tme s servce tag of packet n servce O(1) complexty of vrtual tme update k Servce tag F computed as for PGPS S F k k = max k k L = S + rφ k 1 k { F, V ( a )} Man dfference s n maxmum dscrepancy from GPS ˆ Lmax p, Fp Fp < ( N 1), N s number of flows r SCFQ Dfference Wth GPS N flows, wth N-1 flows at rate r/2(n-1) and 1 flow at rate r/2 N-1 flows wth rate r/2(n-1) and flow N wth rate r/2 Packets for frst N-1 flows arrve at t=0, packet for flow N arrves at t=ε>0 GPS system N-1 WFQ system 0 ε 2L/r+ε NL/r t SCFQ system 0 NL/r t 0 V(ε)=2(N-1)L/r S N = 2(N-1)L/r F N = 2(N-1)L/r+2L/r=2NL/r NL/r t Roch Guern 19

20 Other Schedulers n The LRS Famly (2) Worst case far weghted far queueng (WF 2 Q) Servce tag s vrtual servce fnsh tme, but only among elgble flows,.e., flows wth vrtual start tme <= current vrtual tme Smlar complexty and same dfference wth GPS as WFQ but better farness propertes GPS behavor WFQ behavor WF 2 Q behavor Farness Crtera Ideally, each sesson should receve exactly ts normalzed amount of servce,.e., as per GPS Packet based transmsson ntroduces dscrepances Goal s to estmate how much dscrepancy each type of scheduler allows Some possble measures Dfference n servce receved W ( τ, t) W ( τ, t) For all tme ntervals (τ,t] where sessons and j are backlogged Worst case Far Index (WFI) d c k, S S a k = max Q + k ( a ) + C r { c } s WFI for scheduler S, s, S GPS s the benchmark as t has Φ and WFI of 0, S and c, S r rc = r, S j r j Φ Roch Guern 20

21 Farness Crtera - WFQ WFQ has a WFI that can grow lnearly wth the number of sesson Flow 1 wth rate r/2 and N flows wth rate r/2n Flow 1 sends N packets at tme 0 and 1 packet at tme N/r, all other flows send 1 packet at tme 0 GPS N-1 N N+1 0 packet N+1 2N/r t WFQ 0 C c 1 1, WFQ WFQ 2 3 N-1 N N-1 N N+1 N/r (2N + 1) N 1 N 1 = r r r / 2 r r1 N 1 C1, WFQ = r 2r 2N/r Exact expresson s avalable for c WFQ t Farness Crtera - WF 2 Q The WFI of WF 2 Q s ndependent of the number of sessons For same example as wth WFQ GPS N-1 N N+1 0 packet N+1 2N/r t W 2 FQ N/2 N/2 N N N+1 0 N/r 2N/r t C (2N + 1) N N / = r r r / 2 1 W 2 1, FQ r Roch Guern 21

22 WFI of WF 2 Q? Farness Crtera - WF 2 Q, contd. Another example Flow 1 wth rate ε has packet at tme 0, flow 2 wth rate r/2 has packet at tme 0 +, and flow 3 wth rate r/2 has packet at tme 0 ++ Packets go out n order 1, 2, and 3, so that 3L 3L L L d3 = C 2 = 3, W FQ r r r / 2 r In general, t s possble to show that L L C 2 = and c 2 =, WF Q WF Q r r As a result WF 2 Q s as far as can be for a packet scheduler But remans complex because of Vrtual Tme computatons WF 2 Q+ provdes the benefts of WF 2 Q wth lower mplementaton complexty by usng a modfed Vrtual Tme functon WF 2 Q+ Defnton of Vrtual Tme functon of WF 2 Q+ V 2 WF Q+ h ( t) t + τ ) = max V ( t) + τ, mn( S ) WF Q+ B ( t) ( 2 where B(t) s the set of backlogged flows at tme t, and vrtual start tme of the packet at the head of flow queue Smplfcaton of Vrtual Start and Fnsh tmes h (t ) S Updated only when a packet reaches the head of ts queue k F, f Q ( a ) 0 S = k k max{ F, V ( a )} f Q ( a ) = 0 s the k L F = S + rφ Both Vrtual Tme updates and sortng of vrtual fnsh tmes can be done n O(LogN) complexty Roch Guern 22

23 Summarzng Where We Are Identfed famly of far queueng (FQ) packet schedulers wth the followng propertes Ablty to guarantee transmsson rate to ndvdual flows ndependent of the behavor of other flows Ablty to guarantee far (proportonal to allocated rate) access to excess bandwdth wth bounded devaton from deal flud model Ablty to guarantee local and end-to-end delay bound to polced (token bucket) flows ndependent of the behavor of other flows Computaton of requred buffer szes at each hop (functon of burstness ncrease as packets propagate through the network) Varous trade-offs between mplementaton complexty and tghtness of delay bounds and farness guarantees Some lmtatons of ths famly of schedulers Delay guarantees provded through rate guarantees Potentally neffcent for low bandwdth flows Lmted (no) control of jtter and burstness ncrease Rate Controlled Servce Dscplnes Basc dea s to decouple delay and rate guarantees Controllers RCSD Scheduler Rate controllers release packets to scheduler only when conformant wth servce contract Enforces rate lmtatons and, therefore, ensures guarantees Scheduler provdes delay dfferentaton Can decde whch packet to send ndependent of rate Roch Guern 23

24 Some Propertes of RCSD Capable of all the servce guarantees of Far Queueng packet schedulers Rate guarantees Tght local and end-to-end delay bounds Introducton of rate controllers does not ncrease maxmum delay And also Tght jtter control Burstness control and, therefore, lower buffer requrements Greater schedulablty regon,.e., can accommodate more flows than FQ schedulers for a gven set of guarantees But Rate controllers ncrease average delay No support for excess traffc and far sharng n base verson Rate controllers make the system non-work-conservng Possble extenson (logcal rate controller) provdes some support for excess traffc Why Lower Buffer Requrements? Rate control at each node means that the traffc s reshaped to ts orgnal envelope Elmnates addtonal burstness ntroduced by upstream nodes (σ Latency θ, ρ ) 1 Latency θ 2 Latency θ 3 Burst σ + ρ θ 1 Burst σ + ρ (θ 1 + θ 2 ) Burst σ + ρ (θ 1 + θ 2 + θ 3 ) (σ, ρ ) Latency θ 1 (σ, ρ ) Latency θ 2 (σ, ρ ) Latency θ 3 Burst σ + ρ θ 1 Burst σ + ρ θ 2 Burst σ + ρ θ 3 Reshapng buffer at node k B ( R) k = ρθ k 1 Schedulng buffer at node k B ( S ) k = σ + ρ θ k Roch Guern 24

25 Why No Impact to Delay Bound? Only early packets are reshaped delay added by reshaper s never more than avalable delay budget Illustraton n the case of deadlne based scheduler Input s characterzed by (σ, ρ ) envelope Scheduler guarantees local deadlne d Reshapng delay at next node? Informal proof If all packets are delayed by d, traffc envelope remans unchanged No need to reshape at next hop Packets delayed (reshaped) at next node f they fnd no tokens They arrved before the token was generated But token s generated on tme f they suffered the maxmum delay The tme spent watng for a token s no more than the dfference between the worst case delay d and the actual delay experenced by the packet Examples of RCSD Rate Controlled Statc Prorty (RCSP) Combnes rate controllers and prorty queues Man benefts Avods starvaton of low prorty classes Allows low delay and low rate allocaton But Delay guarantees are coarse Call admsson s complex (need to account for nteractons between classes before makng a decson) Roch Guern 25

26 Worst Case Delay for RCSP N prorty classes wth rate controllers (σ,ρ ) Let t be the tme at whch the server s fnshed servng the ntal burst of class assumng all classes are greedy t t 1 2 t t s the worst case delay for class σ1 = C r σ 2 + r2t 1 = C r r j σ j + rjt = j C r = 1 j 1 Need to empty burst of hgher prorty classes, and after that servce rate s reduced by rate of hgher prorty classes Substantal burstness ncrease affects delay and bufferng at subsequent nodes A Better RSCD: RC-EDF Use a better scheduler,.e., Earlest-Deadlne-Frst (EDF) Optmal polcy for delay guarantees n the sngle node case Each class (flow) s assgned a deadlne representatve of ts local delay requrements Packets released from the scheduler are marked for transmsson based on ther deadlnes All packets from the same burst have the same deadlne Scheduler pcks for transmsson packet wth the smallest deadlne Key propertes Decouplng of rate (shaper) and delay (scheduler) guarantees allows more effcent operaton than rate based schedulers Accept more flows Lower buffer requrements Lower end-to-end jtter (only delay varaton s contrbuted by last node) Shaper selecton s key to tght end-to-end delay bounds Typcally strcter than orgnal traffc envelope Shaper s non-work-conservng No natve support for excess traffc Possble work conservng extenson Roch Guern 26

27 Impact of Shapers (1) End-to-End delay bound s of the form D = access shapng delay + d = 1 But local deadlne d can be guaranteed to flow (σ, ρ ) only f k k 1 k k + N L + d r d k n k + 1 mn 1, σ ρ ρ n n,1 n n= 1 n= 1 n= 1 { } N A ( t d ) rt N r 1 + r 2 + r 3 lnk rate r 1 + r 2 + p 3 r 1 + r 2 p 1 r 1 r 1 + p 2 d 1 d 2 d 3 Impact of Shapers (2) The smoother the traffc, the tghter the deadlne the network can gve The smoother the traffc, the bgger the access delay No known optmal parttonng of delay budget between access and network delay Depends on number of nodes n network Long paths make access smoothng more effectve Common approach s to use WFQ delay bounds as deadlnes A work conservng shaper Mantan two queues One for non-elgble packets One for elgble packets (sorted accordng to ther deadlne) Select for transmsson the packet from the elgble queue wth the smallest deadlne If the elgble queue s empty select a packet from the nonelgble queue (accordng to some polcy, e.g., sum of deadlne and elgblty tme) Roch Guern 27

28 Buffer Management Scheduler manages access to lnk bandwdth whle buffer manager controls access to storage resources Not always enough room to store arrvng packets Needed to provde servce guarantees Permsson to transmt s of no use f no packets are avalable for transmsson n memory Two major decsons When to dscard a packet? Whch packet to dscard? Classfcaton of buffer management methods Tme of packet acceptance/dscard decsons At tme of packet arrval or at any tme Granularty of nformaton used for makng decsons per flow buffer count (stateful) vs global count (stateless) Major Buffer Management Methods One tme decson (no regrets allowed) Dscard/accept packet based on buffer state at arrval tme Smple on-lne decson but off-lne process pre-allocates resources ahead of tme Example: Threshold based schemes Packets are dscarded when the (total/class/flow) buffer occupancy (or count) exceeds a gven lmt (the threshold) Multple decsons (change your mnd each new packet) For each packet arrval (departure) determne whch packets are n and whch are out No off-lne pre-allocaton but complex on-lne decsons and memory structure Example: Pushout schemes Remove low prorty packet from memory to make room for arrvng new hgh prorty packet Trade-off between Complexty, performance, and predctablty Roch Guern 28

29 Threshold Schemes Accept/dscard decson based on current resource usage Determnstc Incomng packet of type s dropped when buffer content exceeds θ Motvaton Threshold computed such that B-θ s suffcent to guarantee performance of type (or hgher) packets Randomzed Type j packet s dropped wth probablty p j when buffer content θ j Motvatons Preventve method,.e., start droppng before onset of congeston Lkelhood of beng dropped s n proporton to volume of traffc Avods possble synchronzaton,.e., always droppng the same flow Examples: Random Early Dscard (RED) and Weghted RED Varous granularty of allocaton are possble Global (prorty classes), per flow (mantan count) θ Random Early Detecton (RED) The RED algorthm s a popular mechansm to mplement congeston avodance for adaptve traffc such as TCP RED s based on the followng components Computaton of average queue sze Q Exponental averagng: Q n = (1-α) Q n-1 + α q n, α << 1 Probablstc droppng that vares wth average queue sze No droppng f Q s below mnmum threshold θ mn All packets are dropped f Q s above maxmum threshold θ max When θ mn Q θ max packet s dropped wth probablty p(q) p(q) ncreases lnearly from 0 to p max between θ mn and θ max p(q) = p max (Q - θ mn )/(θ max - θ mn ) A count varable s used to track the number of packets snce the last drop and ensure that drops occur wthout too much delay p (Q) = p(q)/[1 - count p(q)] Roch Guern 29

30 RED Status RED home page mantaned by Sally Floyd RED has been mplemented n a number of routers and recommended by the IETF as part of congeston avodance schemes RFC 2309 (Informatonal) Many pros and cons that are stll beng debated Farness Lack of bas aganst bursty flows Avodance of synchronzaton Dffculty n properly settng the many parameters that RED nvolves Wde range of performance fluctuatons Check RED home page for nformaton and updates Pushout rules Pushout Schemes Accept all packets when there s space n the buffer When buffer s full, packet of type s accepted by pushng out a packet of the lowest prorty less than, f any Motvatons Hgh prorty packets have precedence over lower prorty ones only n the presence of congeston Favors effcency by maxmzng buffer utlzaton Implementaton ssues n pushout schemes Need to keep track of poston of all packets of all types at all tmes (lnked lsts for each packet type) Need to update lnked lsts for each packet arrval and departure Dffcult to accommodate varable sze packets (may need to pushout several packets to accommodate a large packet) Selecton of whch packet to dscard (frst, last, random) Roch Guern 30

31 Effcency vs Accuracy Global schemes are smpler but may provde only loose servce guarantees Impact of excess traffc across streams Farness ssue n accessng dle resources Per flow schemes can provde greater control Trackng of ndvdual flow resource usage at the cost of hgher complexty and loss n effcency Loss of effcency s caused n part by resource parttonng Range of possble trade-offs Complete parttonng Complete sharng Mxed polces CP CS MP Buffer Sharng Optons Complete parttonng ( B = B) Each flow gets ts dedcated share of the total memory Potentally neffcent as buffers are left unused Complete sharng ( B = 0 ) Maxmum effcency but unable to ensure strong flow solaton Mnmum complexty (no per flow state) Lmted sharng Maxmum per flow buffer content ( B > B) Trade-off between effcency and flow solaton Mnmum per flow allocaton ( B < B) Base guarantee wth potental for mproved effcency Stll need to specfy method for sharng excess buffer capacty How to control sharng across flows? Preserve servce guarantees whle mprovng effcency What nformaton to rely on? Roch Guern 31

32 Sample Buffer Sharng Choces Basc scheme has total memory sze of B and per flow allocatons of B At each packet arrval (departure), update buffer count of flow and make packet acceptance If (b + p,k <= B ) { accept packet; b = b + p,k ; } else drop packet; Sharng optons Aggressve ( B > B) desgn Greater effcency but lower protecton Conservatve ( B B ) desgn Strong servce guarantees, but need rule for far access to excess buffers Example Sample Buffer Sharng Rule Flow buffer allocaton s B +f (B-B ), where f = 1/N, and N s the number of flows currently actve B s the amount of reserved buffers,.e., Issues Defnton of actve flows, e.g., no packets n buffer, or? Addtonal complexty of trackng actve flows A smpler alternatve B = B b B No flow can occupy more excess buffers than are left avalable Only requres trackng of total excess buffer count Can be shown to result n far allocaton of excess buffers Some mnor neffcency when only few flows need excess buffers For k actve flows, the amount of unusable buffer space s (B-B )/k+1 Roch Guern 32

33 Couplng Buffer Management & Schedulng Schedulng affects the regularty of servce of a flow Buffers are used to absorb rregulartes n both packet arrvals and transmsson opportuntes The more regular the arrval process The smaller the requred buffer sze The more regular the servce The smaller the requred buffer sze, e.g., LRS The smaller the requred buffer sze at the next node (more regular arrvals) Bottom lne s that selecton of scheduler and buffer management strategy needs to be done jontly Goals Gven Call Admsson Desred servce guarantees, e.g., loss or delay probablty Traffc characterstcs, token bucket, max rate, etc., of new request Current avalablty of network resources (bandwdth, buffer) Determne Avalablty of suffcent resources to accommodate new request General constrants Keep t smple! Mnmze storage requrements and computatonal cost Real tme acceptance or rejecton decsons Roch Guern 33

34 Desgn Issues Incremental decsons Avod computatons that nvolve all flows when addng/removng one Accuracy System resources, e.g., fnte buffers Traffc constrants Progressve arrvals Fnte peak rates Complexty Mnmze on-lne computatons Lmt storage requrements Flexblty Traffc patterns Servce guarantees Effectve or Equvalent Bandwdth Queston How much bandwdth gven a desred loss probablty ε, buffer sze X, and source characterstcs ρ, b, and R peak Approach Assume source can be vewed n solaton and use flud flow representaton Invert expresson for overflow probablty and solve for the desred capacty C Overflow probablty s of the form ε = βe δx, where ( C Rpeak ) + ερ( Rpeak C) C ρrpeak β =, δ = (1 ρ) C b(1 ρ)( Rpeak C) C Assume β 1 αb(1 ρ) R Cˆ = peak X + [ αb(1 ρ) R peak 2αb(1 ρ) 2 x] + 4Xαbρ(1 ρ) R peak, whereα = Ln(1/ ε) Roch Guern 34

35 Some Interestng Propertes Effectve bandwdths are (asymptotcally) addtve For large enough buffers, the effectve bandwdth of the superposton of heterogeneous ON-OFF sources s the sum of ther ndvdual effectve bandwdth,.e., Cˆ N cˆ = 1 Based on separablty results for the egenvalues of the soluton to the dfferental matrx equaton descrbng the evoluton of the queue length Beneft s that we can now consder each connecton n solaton when makng a call admsson decson Incremental decson process Some Effectve Bandwdth Lmtatons Based on exponental source assumpton Extensons to general sources are substantally more complex Possble approxmatons Moment matchng Compute equvalent exponental ON and OFF source by reszng ON and OFF perods based on (second) moment Measurement based approach Identfy exponental source that yelds the same measured queue sze (based on measurng level crossng probablty) If bgger than expected, ncrease burst sze, and recompute effectve bandwdth If smaller than expected, decrease burst sze, and recompute effectve bandwdth Contnue untl convergence Does not capture well the effect of statstcal multplexng Conservatve for large number of hgh speed bursty sources Some other (complementary) method s needed Roch Guern 35

36 A Statonary Bt Rate Approxmaton Goal s to complement effectve bandwdth approach n scenaros where t s neffcent Large number of bursty and hgh peak rate sources Basc dea s to gnore the potental usefulness of buffers when peak rate s hgh and bursts are large Buffers are of lttle help when congeston can last Focus nstead on probablty of congeston,.e., probablty that the aggregate rate R tot of smultaneously actve sources exceeds the avalable (allocated) bandwdth Pr( R > ˆ tot C ) ε Dstrbuton of aggregate rate s ndependent of dstrbuton of ON and OFF perods Depends only of probablty of beng ON or OFF S A Statonary Bt Rate Approxmaton - contd. When many sources are multplexed, we can use the law of large numbers to approxmate the dstrbuton of R tot by a Gaussan dstrbuton Computng Ĉ S requres nvertng a Gaussan dstrbuton Good and smple approxmaton can be obtaned ˆ C S m + α σ, where α = 2ln( ε ) ln(2π ) where m s the sum of the average rates of all the connectons multplexed and σ 2 s the sum of the varances of all the connectons ( ) m = ρrpeak σ = m ( R ( ) peak m ) Roch Guern 36

37 Combnng the Two Whch approach to use when? They are complementary as they over-estmate capacty n dfferent regons Combned approach smply amounts to takng the mnmum of both approaches N Cˆ = mn m + α' σ, cˆ = 1 Advantages Reasonably accurate over wde range of connectons Incremental call admsson process L N N N = 2 2 m = m,, Cˆ σ = σ F = = 1 = 1 = 1 L' = L ± 2 ( m, σ, Cˆ ) j j j Cˆ Measurement Based Admsson Control Basc premse Some users may not requre absolute performance guarantees Those users may not have traffc descrptors for ther sessons or more typcally these wll be naccurate Equaton based methods are only as good (bad) as the nformaton they rely on Ths can result n hghly neffcent call admsson rules Basc dea Take the traffc descrptors only as ntal estmates of traffc characterstcs and use measurements to accurately estmate network load and make admsson decsons Roch Guern 37

38 Summary of MBCAC Approaches Two basc components Measurements of current traffc and ts requred resources How to measure? How to derve requred resources from measurements? Accountng for a new request What parameters (peak rate, average rate, burst sze, etc.)? How to ncorporate requrements of new request? A varety of proposed approaches From smple measurements Tme wndow estmator, exponental averagng of load estmates To complex measurements Effectve bandwdth curves, maxmal traffc envelopes Incorporaton of new flow based on peak rate, token rate, effectve bandwdth estmates Current status No clear and proven choce See Infocom 00 paper by Breslau et al. for a recent comparson of proposed schemes IP QoS Approaches Roch Guern 38

39 IP Servces Two broad famles Aggregate servce (relatve and qualtatve guarantees) Dfferentated Servces (RFC 2474, RFC 2475, RFC 2597, RFC 2598) Per flow servce (quanttatve and qualtatve guarantees) Integrated Servces (RFC 2211, RFC 2212) Dfferentated Servce (packets dentfed by DS feld) Pre-confgured set of servce classes (behavors) Expedted Forwardng (local behavor only) Vrtual leased lne type of servce Assured Forwardng (local behavor only) Several servce classes wth drop precedence wthn each class Integrated Servces (flow dentfed by SA/DA & ports) RSVP based sgnallng nstalls per flow state n routers Controlled Load Servce Loose loss and delay guarantees Guaranteed Servce Hard end-to-end delay bound and zero losses Goals and motvatons Data path scalablty Dfferentated Servce Coarse granularty servce classes (no per flow state) Mnmum mpact on packet forwardng performance Realzable through smple mechansms Rapd deployment Standardze servce codeponts n IP header and assocated expected local behavor (Per Hop Behavor - PHB) Wde range of possble mplementatons Avod chcken and egg problem of sgnallng deployment and applcaton/user support Status Intal standardzaton effort complete Defnton of format of DS feld (6 bts) n IP header (IPv4 and IPv6) Two behavors: Expedted Forwardng and Assured Forwardng Interactons wth Int-Serv and servces defnton n progress Coarse sgnallng support (Bandwdth Broker) under nvestgaton Roch Guern 39

40 Dff-Serv Termnology DS feld: Frst sx bts of the IPv4 TOS octet or the IPv6 Traffc Class octet DS Code Pont (DSCP): A specfc value of the DS feld Behavor Aggregate: A collecton of packets (on a lnk) wth the same DSCP Per Hop Behavor (PHB): The descrpton of the forwardng treatment to be appled to a behavor aggregate PHB Group: A set of one or more PHBs that can only be specfed and mplemented smultaneously because of a common constrant Traffc condtoner: An entty that apples some traffc control functon (meterng, markng, polcng, shapng) to ncomng packets Dff-Serv Components Edge functons Flow classfcaton and packet markng Traffc condtonng Core functons Enforcement of Per Hop Behavors Boundary functons Conformance enforcement Components Classfers Select packets and assgns DS code pont Traffc condtoners Enforces rate lmtatons Per Hop Behavors Dfferentated packet treatments DS Domans Roch Guern 40

41 More on DS Functons and Components polcy/classfcaton DA= /32 SA= DA= /24 DA= /28 SA= /24 DA= /26 traffc condtonng and packet markng per hop behavor enforcement per hop behavor enforcement Border Node per hop behavor enforcement traffc condtonng and packet markng polcy/classfcaton DSCP= DSCP=001*** DSCP=010*** DSCP=011*** DSCP=100*** DSCP= Core Node per hop behavor enforcement DS Standardzaton Status Assgnment of Code Ponts n DS feld (DSCP) Space s parttoned n three pools Pool Codepont Space Assgnment Polcy 1 xxxxx0 Standards Acton 2 xxxx11 EXP/LU 3 xxxx01 EXP/LU (*) (*) may be utlzed for future Standards Acton allocatons as necessary DSCP s the recommended value for the default PHB to be used for current best-effort traffc DSCP values xxx000 have been reserved as a set of Class Selector Codeponts to defne up to 8 PHBs Amed as some backward compatblty wth prevous usage of IP precedence feld,.e., bts 0-2 of IPv4 TOS octet DSCP 11x00 has preferental forwardng treatment over The 8 PHBs must yeld at least to ndependent forwardng classes Packet forwardng treatment should mprove the hgher the numercal value of the DSCP of a PHB Roch Guern 41

42 Status Expedted Forwardng (EF) PHB Standardzed n RFC 2598 Recommended DSCP s Goals Enable deployment of low loss, low latency, low jtter, assured bandwdth servce Emulaton of a vrtual leased lne Defnton of EF PHB Mnmum servce rate must equal or exceed a confgurable rate settable by a network admnstrator Ablty to ensure servce should be ndependent of other traffc Mnmum servce rate should average the confgured rate over any tme nterval longer than the tme t takes to send an MTU szed packet at the confgured rate Requrements Maxmum rate of EF traffc must be lmted f EF traffc can preempt other traffc Ingress traffc condtoners dscard (shape?) excess traffc Sample Mechansms for Supportng EF Prorty queue EF traffc has precedence low loss, low latency, low jtter Servce rate s lnk speed whenever EF queue s non-empty Ingress traffc polcng s requred to avod starvaton of other traffc classes Weghted Far Queueng EF s guaranteed a rate and delay bound Low loss and low latency Mnmum rate s confgured rate over tme nterval larger than one MTU transmsson tme Potental for burstness ncrease because of aggregaton Confgure rate to be hgher than ncomng EF rate How much hgher? Roch Guern 42

43 Some Basc Issues wth EF Impact of aggregaton on End-to-end performance Polcng functons at doman boundares What mechansm? Prorty queue vs WFQ Shapng at doman boundares What EF load? Indvdual vs aggregate contracts Some prelmnary answers (no deployment experence) Reshapng s nearly a must to avod substantal nonconformance droppng at doman boundares Aggregate contracts are more effcent n terms of both amount of bufferng and reshapng delay Aggregaton requres low load to avod potental ncreases n burstness, delay varatons, etc. On The Effcency of Aggregate Contracts - N = 10 network hops - n ts = 24 tagged streams - n cs = # cross-streams - Desred level of nonconformance P D =10-5 Total Reshapng Buffer Sze (n # packets) n cs n cs n cs n cs = 25, ˆ ρ = = 25, ˆ ρ = 1 = 120, ˆ ρ = = 120, ˆ ρ = 1 Number of Streams per Contract Aggregaton reduces the total amount of bufferng needed. Furthermore, hgher speeds should also reduce reshapng delays Roch Guern 43

44 Assured Forwardng (AF) PHB Status: Standardzed n RFC 2597 Goals Ensure hgh probablty of packet delvery up to a commtted rate Support excess traffc wth a lower probablty of delvery Defnton of AF PHB group Four separate AF classes are currently defned Each class s allocated ts own amount of resources (buffer & bw) Each class specfes three drop precedence values (DSCP) Low drop precedence packets are protected from loss by preferentally dscardng hgher drop precedence packets Requrements Two of more AF classes must not be aggregated together A class must be allocated a confgurable amount of resources and should acheve ts rate over small and large tme scales Packet forwardng probablty must be nversely proportonal to drop precedence A DS node must accept all three drop precedence values and must yeld at least two levels of loss probablty A DS node must not reorder packets from the same mcroflow that belong to the same AF class Specfcaton of AF PHB Group Recommended values for AF codeponts Low drop prec. Medum drop prec. Hgh drop prec. AF1 AF2 AF3 AF Each class, f supported, has ts own resources No specfc performance relatonshp between classes Performance depends on relatve rato between resources allocated to each class and traffc volume assgned to t Traffc condtonng on ngress can provde desred packet markng Note that fourth bt n DS feld can be used for smple hgh/low prorty dentfcaton Implementaton smplcty Roch Guern 44

45 Sample AF Implementatons FIFO scheduler wth buffer management Assgn buffer shares to each AF class n proporton to ts commtted rate Specfy thresholds wthn each class for dscardng based on drop precedence Determnstc or randomzed a la RED WFQ scheduler wth buffer management Assgn scheduler weght to each AF class n proporton to ts commtted rate Provde per class buffer management, e.g., through the specfcaton of drop precedence based thresholds Smoother servce characterstcs of WFQ can lower lkelhood of droppng hgh drop precedence packets Dff-Serv Summary Standardzaton effort complete Several proposed standard RFCs Intal deployments and vendor support Internet2 QBone effort ( DS feld based classfcaton and prortzaton becomng avalable from most router vendors Some ongong/mssng peces Sgnallng support Bandwdth broker? Senstvty to route changes Sngle change can mpact many flows on unaffected lnks Coexstence wth other Internet technologes under development Integrated servces and MPLS What end-to-end servces can be bult based on PHBs? Roch Guern 45

46 Goals and motvatons Integrated Servces End-to-end guarantees for ndvdual flows From end-system to end-system Range of servce guarantees From determnstc performance to loose bandwdth/delay guarantees Tght couplng wth sgnallng (RSVP) Status Intal standardzaton effort complete Two servces have been standardzed Controlled Load Servce Guaranteed Servce Standardzed sgnallng mechansm (RSVP) Lmted deployment experence Scalablty concern (especally n the backbone) Few applcatons exst that can nvoke the servces (ths s changng) Issues regardng end-to-end avalablty What s RSVP RSVP s a sgnallng protocol to request allocaton of resources to a flow n an IP network Major characterstcs of RSVP Applcaton ntated (fne granularty of reservaton) Desgned for scalablty to very large multcast group Recever orented model, e.g., as wth ATM LIJ Reservatons are for smplex flows Support for heterogeneous reservatons (multcast) and renegotaton of reservatons Allows sharng of reservatons across multple flows Soft state approach for smple error recovery Roch Guern 46

47 Overvew of RSVP Role and Interfaces RSVP aware applcaton RSVP daemon Routng nterface Routng protocol/table Socket API RTP RAPI Local resources management Packet classfer API Control path Admsson control Packet classfer Lnk scheduler Data path Some RSVP Defntons Sesson: set of packets addressed to a partcular destnaton and transport protocol Flow descrptor: Flowspec + Flter spec Flowspec: Reservaton request (RSpec & TSpec) Flter spec: Sender address and TCP/UDP port number RSVP flow: Sesson + Flter spec Reservaton style: dstnct/shared; explct/mplct Sender selecton Explct Implct Dstnct Fxed-Flter (FF) style none defned Reservatons Shared Shared-Explct (SE) style Wldcard-Flter (WF) style Roch Guern 47

48 RSVP Messages : sets up state along path followed by packets : Request for reservaton back along setup path _TEAR: Explct removal of state along path _TEAR: Explct removal of reservaton _ERR: Reservaton falure & errors _ERR: Path error _CONFIRM: Reservaton confrmaton* * Not an end-to-end guarantee Basc RSVP Operaton Setup path n the network through messages from sender(s) Reserve resources on path through messages from recever(s) R1 S1 R2 S2 _TEAR _TEAR _ERR _ERR CONFIRM R3 Roch Guern 48

49 RSVP Soft State Soft state means that any RSVP related state ( and states) s temporary (tmer) Needs to be refreshed n order to stay Wll (eventually) dsappear f not refreshed Refresh and state clean-up Send new message every t sec (30sec) If fal to receve any refresh n n*t sec, delete state (n=3) Smplfcaton of error recovery as you know you wont stay forever n a bad state Don t need to be too pcky n takng care of all error scenaros Trade-off between addtonal protocol overhead and smpler processng rules RSVP messages are sent unrelably RSVP Message From sender to recever(s) to establsh path state n network elements (routers) between sender and recever(s) Addressed drectly to destnaton Includes Router alert opton ensures ntercepton at each RSVP hop Prevous hop (PHOP): The prevous RSVP aware entty on the path Sender template: Flter spec for the sender Sender TSpec: Traffc characterstcs of sender Sender ADSPEC: Used to capture path characterstcs message s processed and updated at each RSVP aware hop on the path Create or refresh path state Update ADSPEC Roch Guern 49

50 Format of Sender TSpec reserved reserved Token bucket rate [r] (32-bt IEEE floatng pont number) Token bucket sze [b] (32-bt IEEE floatng pont number) Peak data rate [p] (32-bt IEEE floatng pont number) Mnmum polced unt [m] (32-bt nteger) Maxmum packet sze [M] (32-bt nteger) 0: Message format verson number 7: Overall length (7 words wthout header) 1: Servce header, servce number 1 (default/global nformaton) 6: Length of servce 1 data (6 words wthout header) 127: Parameter ID, parameter 127 (Token_Bucket_TSpec) 0: Parameter 127 flags (none) 5: Parameter 127 length (5 words wthout header) TSpec Conformance Rules Lmtaton on when and how much data to send t A(t) <= M + mn[pt, rt+b-m] Lmtaton on mnmum packet sze Per packet processng tme τ, e.g., lookup, must be smaller than packet transmsson tme m τ, c = nput lnk speed c Packet smaller than m are counted as beng of sze m Lower effectve rate f smaller packets are used m m m r = r m Lmtaton on maxmum packet sze (M) Bound the maxmum transmsson tme of packets Packets larger than M are deemed non-conformant Roch Guern 50