IP Quality of Service (QoS)

Transcription

1 IP Quality of Service (QoS) Muhammad Jaseemuddin Dept. of Electrical & Computer Engineering Ryerson University Toronto, Canada References 1. Larry L. Peterson, Bruce S. Davie, Computer Networks: A Systems Approach, 2 nd edition, Morgan-Kaufmann, Paul P. White, RSVP and Integrated Services in the Internet: A Tutorial, IEEE Communications Magazine, May David Durham, Raj Yavatkar, Inside the Internet s Resource Reservation Protocol, John Wiley, A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, McGraw Hill, D. D. Clark and W. Fang, Explicit Allocation of Best-Effort Packet Delivery Service, IEEE/ACM Transactions on Networking, Vol. 6, No.4, August H. J. Chao and X. Guo, Quality of Service Control in High-Speed Networks, John Wiley & Sons.

2 Queuing Discipline FIFO Scheduler:A scheduler S serves the queues in the order defined by its type Max-Min Fair Share: if scheduler allocates link capacity such that it maximizes the minimum share of a user whose demand is not fully satisfied Protection: A misbehavior user (exceeding its rate limit) does not affect the performance of other users Work Conserving: A scheduler is idle only when the queue is empty Non-work Conserving: A scheduler may be idle even if there is packet in the queue First-In-First-Out (FIFO) Packets are scheduled in the order they arrive does not discriminate between traffic sources Jitter tends to increase with the number of hops, since the delays at different hops are uncorrelated Jitter of all flows are shared by all of them It does not provide max-min fair share nor protection Queue 1 Queue 2 Queue 1 S S Queuing Discipline RR Round Robin (RR) Flow 1 The scheduler polls each queue in cyclic order and serves the packet in a queue if the queue is non-empty It provides protection as a misbehaving user overflows Flow 2 its own queue It gives equal share of bandwidth among users Weighted Round Robin (WRR) Flow 3 The scheduler performs RR scheduling but instead of serving one packet at a time serves packets in proportion to the weight of the queue Flow 4 It shares the link according to weight, e.g. Wa=3 and Wb=7 indicates 30% capacity is allocated to Queue A and 70% to B Deficit Round Robin (DRR) Modifies WRR to handle variable packet size in fair manner A queue i is allocated its quantum number of bits Qi for a round Any left over bits, Deficit Di, are carried in another round In every round Di is updated as Di = Di + Qi and that many bits are served If a packet is large, then it is deferred for the next round when enough bits are available for the service Round-robin service

3 Queuing Discipline WFQ Fair Queuing (FQ) Explicitly segregates traffic based on flows Ensures no flow captures more than its share of capacity it prevents a flow from hogging the queue resource Each flow is guaranteed at least C/n bps, if C is the link capacity in bps and n is the number of flows Equitable sharing of link bandwidth View the queue as a fluid flow system A flow can get more bandwidth if the queue is empty work conserving Variation: weighted fair queuing (WFQ) Problem of FQ? No preemption Short packets may miss its deadline by large packets under transmission Jitter is experienced by the flow causing burstiness it is not shared Jitter may be too high Packet-by-Packet Fair Queuing Queue t=0 Queue t= t Fluid-flow system: both packets served at rate 1/2 Both packets complete service at t=2 Packet from queue 2 waiting 1 Packet from queue 1 being served t Packet-by-packet system: queue 1 served first at rate 1; then queue 2 served at rate 1. Packet from queue 2 being served

4 FQ Algorithm Suppose clock ticks each time a bit is transmitted Suppose each queue is served one bit in a round A round consists of number of clock ticks to serve one bit from all n queues (flows) R(t) is the number of rounds at time t, which is a function of number of active queues dr(t)/dt = C/n active (t) is a piece-wise linear function Let P(i,k) denotes the length of packet k of flow I Let t ik is the arrival time and R(t ik ) be the arrival round of packet P(i,k) Let S(i,k) denotes the round when start transmitting packet k Let F(i,k) denotes the round when finish transmitting packet P(i,k) F(i,k) = S(i,k) + P(i,k) When does router start transmitting packet P(i,k) if queue is not empty, then from the next round after transmitting P(i,k-1) If queue is empty, then start transmitting from R(t ik ) Thus: F(i,k) = MAX (F(i,k-1), R(t ik ) + P(i,k) Finished round number can be used as a priority tag Packet-by-Packet Fair Queuing Queue t=0 Queue t=0 1 2 Fluid-flow system: both packets served at rate 1/2 Packet from queue s served at rate t Packet from queue 2 waiting Packet-by-packet fair queuing: queue 2 served at rate 1 1 Packet from queue 1 being served at rate t

5 FQ Algorithm - Example For multiple flows calculate F i for each packet that arrives on each flow treat all F i s as timestamps next packet to transmit is one with lowest timestamp Not perfect: can t preempt current packet Example Flow 1 Flow 2 Output Flow 1 (arriving) Flow 2 (transmitting) Output F = 8 F = 10 F = 5 F = 2 F = 10 (a) (b) Weighted Fair Queuing (WFQ) Since different users have different requirements Non-equitable fair sharing Giving each flow certain proportion of the bandwidth Each flow is assigned a weight that determines its relative share of the bandwidth F i = MAX (F i -1, A ) i + P i /w i P i /w i shows the depletion of flow i queue at a rate proportional to its bandwidth share determined by its weight WFQ ensures that a flow i with weight w i will get at least (w i /W)C bandwidth W = w i C is the link capacity in Mbps

6 Packet-by-Packet WFQ Queue t=0 Queue t=0 Packet from queue 1 waiting 1 Packet from queue 2 being served 0 Packet from queue 2 served at rate 3/ t Packet-by-packet weighted fair queuing: Flow 1 will receive 1 bit/round (w 1 =1) and Flow 2 will receive 3 bits/round (w 2 =3) queue 2 served first at rate 1 F(2,1) = 0 + 1/3 = 1/3 then queue 1 served at rate 1 F(1,1) = 0 + 1/1 = 1 Packet from queue 1 being served Fluid-flow system: packet from queue 1 served at rate 1/4; Packet from queue 1 served at rate 1 t Real time Applications Require deliver on time assurances must come from inside the network Microphone Sampler, A D converter Buffer, D A Speaker Example application (audio) sample voice once every 125us each sample has a playback time packets experience variable delay in network add constant factor to playback time: playback point

7 Playback Buffer Packet arrival Sequence number Packet generation Network delay Buffer Playback Time Example Distribution of Delays 3 90% 97% 98% 99% Packets (%) Delay (milliseconds) One way delay measured on certain path in Internet on one day 97% of packets experience delay 100ms or less

8 Taxonomy Applications Real time Elastic Tolerant Intolerant Interactive Interactive bulk Asynchronous Adaptive Nonadaptive Rate-adaptive Nonadaptive Delayadaptive Rateadaptive Real time applications Tolerant: tolerant of losses Adaptive: adaptable to delay Delay Adaptive: Applications that can adjust playback point Rate Adaptive: Applications that trade off coding with bit rate Integrated Services Service Classes Guaranteed (RFC 2212) Provide bound on delay Applications set the playback time adjusted to the pre-specified delay bound controlled-load (RFC 2211) provide the same level of service as unloaded best-effort it controls delay and losses under load condition For adaptive real-time applications that can tolerate certain losses and delays Mechanisms signaling protocol E.g. RSVP admission control Parameter-Based Admission Control (PBAC) Measurement-Based Admission Control (MBAC) policing packet scheduling WFQ, PQ, CB

9 Flowspec Rspec: describes service requested from network controlled-load: none guaranteed: delay target Tspec: describes flow s traffic characteristics average bandwidth + burstiness: token bucket filter token rate r must have n tokens to send n bytes bucket depth B start with no tokens accumulate tokens at rate of r per second can accumulate no more than B tokens Router Mechanisms RSVP Signaling RSVP Process Policy Control RSVP Signaling Routing Data Flow in Admission Control Packet Classifier Packet Scheduler Data Flow out Admission Control decide if a new flow can be supported answer depends on service class not the same as policing Packet Processing classification: associate each packet with the appropriate reservation scheduling: manage queues so each packet receives the requested service

10 Guaranteed Service It provides: Assured level of bandwidth Maximal end-to-end delay bound It does not control minimal and average delays No queuing loss for conforming packets It is for playback applications with strict delay bound requirement the maximal delay bound is normally very large, packets usually arrive much earlier The application must be capable of storing packets that arrive early In a fluid flow model the delay bound is b/r provided R >= r To allow deviation, two error terms C and D are defined C is rate dependent error factor measured in bytes For example time taken in the network for serializing IP datagrams into ATM cells at a frequency 1/r D is rate independent error factor measured in micro-seconds For example, in some slotted network specific slots are reserved for guaranteed bandwidth traffic. The packets have to wait for a pre-determined amount of time to grab the slot The delay bound will be: b/r + C/R + D Guaranteed Service Specification Tspec parameters are: P = peak rate of flow (bytes/sec) B = bucket depth (bytes) r = token bucket rate (bytes/sec) m = minimum policed unit (bytes) Packets of smaller size will be counted by the policer as of size m M = maximum datagram size (bytes) Rspec parameters are: R = service rate (bytes/sec) The rate that will be reserved at every router S = slack term (micro seconds) The maximum delay tolerance a router if does not have enough available bandwidth as requested by the receiver in R, then it reserves R that will cause increase in delay d i such that d i < S.

11 Guaranteed Service Each router reserves bandwidth R and buffer space B The traffic is policed at the network entry point Non-conforming packets are treated as best-effort datagram Marked to get the same treatment in the downstream routers Datagrams larger than MTU are policed as non-conformant The traffic is shaped at every heterogeneous source branch points and all source merge points Heterogeneous branch point is the point in the multicast distribution tree where the traffic from a source replicates and get forwarded on distinct paths The Tspec reservation is not the same on all the links Reshaping is required when the Tspec of the outgoing link is less than the Tspec of the immediately upstream link Source merge point is the point in the multicast distribution tree where traffic from different sources sharing the same reservation merge The amount of buffering required at a reshaping point to reshape the traffic to the token bucket specification is b+csum+(dsum*r) Csum and Dsum are the sum of parameters C and D between the last reshaping point and the current reshaping point Guaranteed Service The source and any reshaping point when transmits at peak rate p must not exceed M+pT data transmission in any time T, where M is the maximum packet size The traffic must not exceed at any time T M+min(pT, rt+b-m) Considering only token bucket traffic descriptor (r,b) Q = b/r + Ctot/R + Dtot Buffer space = b + Csum + (Dsum*R) Considering peak rate p and maximum packet size M more accurate bound equations are: Q = (b-m)(p-r)/r(p-r) + (M+Ctot)/R + Dtot when p>r>=r Q = (M+Ctot)/R + Dtot when R>=p>=r Peak rate puts a limit on the rate at which burstiness b can be caused Hence considering peak rate in computing buffer space gives less buffer requirement Considering peak rate, the buffer requirement can be computed as: M+(b-M)(p-r)/(p-r)+(Csum/R+Dsum)*r if (b-m)/(p-r) < (Csum/R+Dsum) M+(b-M)(p-R)/(p-r)+(Csum/R+Dsum)*R if (b-m)/(p-r) > (Csum/R+Dsum) and p >R M+(b-M)(p-p)/(p-r)+(Csum/R+Dsum)*p if (b-m)/(p-r) > (Csum/R+Dsum) and p < R

12 Guaranteed Service Slack term indicates the difference between the required delay bound and the bound on delay estimated by the fluid flow model S = Dreq (b/r + C/r + D), where R>=r It is used by the routers to reserve less than R resource But the overall delay bound advertised by the network remains unchanged A router can employ WFQ to implement this service Applications can set their playback points (b-m)/r*(p-r)/(p-r)+(m+ctot)+dtot where R<p Controlled Load Service The application receiving CL service is assured by the routers along the path to receive the end-to-end behavior tightly approximated to the best-effort datagram delivery under unloaded network condition The application then expects: A very high percentage of packets will be successfully delivered The percentage of packet drop will be closed to that caused by the basic packet error rate of the transmission medium A very high percentage of packets delivered will experience delay that does not greatly exceed the minimum transmit delay of any successfully delivered packet Min. transmit delay includes medium propagation delay and fixed processing time in the routers and other network elements It provides no firm quantitative guarantees on loss or delay It is used by adaptive realtime applications The application is required to provide an estimation of its traffic in Tspec as for guaranteed service

13 Controlled Load If a router accepts a flow for CL, it makes a commitment that the flow will continue receiving the service equivalent to the best-effort service on a lightly loaded network CL service does not deteriorate if the network load increases Regardless of the level of load increase It essentially puts an expectation on the duration of service disruption short term disruption is considered due to statistical effect Long term disruption is indicative of insufficient allocation of resources along the path It employs statistical approach to resource allocation must allocation bandwidth higher than the token rate r employs any scheme to control the burst effect E.g. borrow the bandwidth from other flows to clear a burst It can implement the service using priority queue Higher priority queue for controlled load Lower priority queue for best-effort service It controls the admission of flows into CL queue Reservation Protocol Proposed Internet standard: RSVP Consistent with robustness of today s connectionless model Uses soft state (refresh periodically) Designed to support multicast Receiver-oriented Two messages: PATH and RESV Source transmits PATH messages every 30 seconds Destination responds with RESV message Merge requirements in case of multicast Can specify number of speakers

14 RSVP PATH Message Path Setup PATH Message is generated by the source(sender) and traverse along the route to the destination (receiver) It causes all the RSVP capable router to install path state path setup It contains Phop The address of the last RSVP capable router Updated by every RSVP capable router on the path Sender template Filter specification to identify the traffic Sender Tspec RSVP Path Message Content Adspec - One Pass With Advertisement (OPWA) Updated by every RSVP capable router Contains General Parameter Segment and service specific segment. GPS contains: min. path latency: sum of link propagation delays along the path min. bandwidth: minimum of individual link bandwidth along the path path MTU:min. MTU of individual links along the path IS hop count: incremented by each RSVP capable router along the path, indicating their number Global break bit: This bit is cleared by the sender. It is set by a router that finds the phop router (address) is not directly connected through the incoming interface on which it receives the path message. When the bit is set it indicates that there are routers on the path that do not support RSVP (IS), hence the adspec content may be invalid.

15 RSVP Path Message Processing It is intercepted by every RSVP capable router along the path If the router finds any error, it sends PathErr message back to the sender If it finds no error, updates or creates the path state that contains Sender template, Phop, Adspec Sender TSPec: provides a ceiling to clip an erroneously high reservation request in Rspec Set cleanup timer to cleanup time interval Path state is deleted if the refresh Path message doesn t arrive at least once in the cleanup time interval RSVP soft state RSVP PATH Message Refresh Router generates Path messages if the routing update causes change in outgoing interface in the forwarding path if the router detects any change in the path state Refresh the downstream nodes Refresh period is typically much less than cleanout time interval to tolerate few Path message losses Path tear down Explicit PathTear message can be generated by the sender to remove path state from the routers along the path Expedite path tear down process

16 Reservation Model Reservation Models OPWA Reservation Sender includes Adpsec Receiver determines end-end service resulting from the request One-pass Reservation No adspec receiver reserves the resources without determining the end-end service RSVP RESV Message Receiver sends Resv Message upstream to the sender It is sent hop by hop to the address a RSVP node learns from the Phop object Resv Message contains An indication of the reservation style Filter spec Identifies sender similar to the sender template Flow spec Rspec Calculated value of R and slack term to zero Tspec Typically set to sender Tspec with M changed to PathMTU Optionally a reservation confirmation object, ResvConf, containing the IP address of the receiver. The router at which the reservation ends up the distribution tree if finds ResvConf sends ResvConf message to the receiver indicating that there is a high probability that the reservation succeeds

17 Reservation Style Explicit Wildcard Distinct Fixed Filter (FF) Shared Shared- Explicit(SE) Wildcard- Filter(WF) The Filterspec and the effective Flowspec at any router is obtained as a result of merge process Filterspec identifies the packets to which the reservation applies The merging rules depend upon the reservation style The router calculates the filterspec and flowspec to be sent upstream applying merging rules on the stored state If as a result of merging Resv state changes, then the new Resv message is sent immediately Otherwise the Resv message is sent following the periodic refresh cycle Merging rules apply to the packets of the same session Fixed Filter (FF) The fixed filter indicates a single sender only The router receiving Resv message checks the installed reservation states on the received interface for that particular sender The effective Flowspec of the reservation installed is the maximum of all FF reservation requests received on that interface for that particular sender Outgoing requests after merging Incoming reservation request FF(S1{4B},S2{6B}) Toward S1,S2 FF(S3{2B},S4{5B}) Toward S3,S4 FF(S5{4B},S6{2B}) Toward S5,S6 Reserve S1 {4B} S2 {3B} S3 {5B} Reserve S2 {6B} S4 {4B} S6 {2B} Reserve S2 {3B} S3 {2B} S5 {4B} FF(S1{2B},S2{3B},S4{5B}) FF(S1{4B},S2{2B}) FF(S4{4B}) FF(S2{6B},S4{2B},S6{2B}) FF(S2{3B},S3{2B},S5{4B})

18 Shared Explicit (SE) Type The Filterspec of each stored SE reservation on the interface identifies a set of individual hosts (senders) The Filterspec Outgoing requests after merging Reserve SE((S1,S2){5B}) Toward S1,S2 (S1,S2,S4 {5B}) SE((S3,S4){5B}) Reserve Toward S3,S4 (S4,S6 {3B}) Incoming reservation request SE((S2,S4){5B}) SE((S1,S2){2B}) SE(S4){3B}) SE(S4,S6{2B}) SE((S5,S6){4B}) Toward S5,S6 Reserve (S2,S3,S5 {4B}) SE(S2,S3,S5){4B}) Wildcard Filter (WF) The Filterspec of WF reservation installed at an interface matches any sender from upstream Indicates the reservation shared by all upstream senders The single Resv message sent upstream contains the maximum Flowspec of all WF reservation requests received on that particular interface Outgoing requests after merging WF(*{5B}) Toward S1,S2 WF(*{5B}) Toward S3,S4 WF(*{5B}) Toward S5,S6 Reserve (*{5B}) Reserve (* {3B}) Reserve (* {4B}) Incoming reservation request WF(*{5B}) WF(*{2B}) WF(*{3B}) WF(*{2B}) WF(*{4B})

19 Slack Term Receivers includes slack term S and R in its Resv message for guaranteed service It represents the amount by which the end to end delay is below the delay bound requirement of the application It gives flexibility to schedulers Deadline schedulers can overestimate delay while reserve R bandwidth Rate based scheduler incur more delay when reserve less than R bandwidth It must satisfy: S out + b/r out + C toti /R out <= S in + b/r in + C toti /R in where r <= R out <= R in It increases the probability of reservation success For example, for a traffic with r=1.5mbps, the receiver computes (R=2.5Mbps, S=0) reservation request R3 has only 2Mbps unused bandwidth, hence it denies the reservation request and sends ResvErr message to the receiver The receiver computes new reservation (R1=3Mbps, S1>0) R3 uses the margin in delay provided by S1 and reserves 2Mbps < R1, which causes an increase in delay di < S1 It computes and send upstream new reservation request (R2,S2=S1-di) RSVP Example Sender 1 PATH Sender 2 PATH R R RESV (merged) R RESV R Receiver A R RESV Receiver B

20 Integrated Services Implementation Packet Scheduler GS Flows WFQ Existing Flows CLS Flows Class 1 Class 2 PQ BE Flows RSVP New Flows Router Accept Admission Control Reject IntServ Issues Issues with IntServ Scalability Every router needs to keep per flow RSVP state It does not recognize internet domain architecture Autonomously administered domains It is a gross assumption that every domain will provide the same bounded service Service definition is the forte of service providers It is business oriented

21 Allocated-Capacity Framework (Clark & Feng) Problem with IntServ: scalability Idea: support two classes of packets Distinguish between packets conforming to the profile and non-conforming packets Can be used to offer different service class premium best-effort P(drop) Predecessor of Differentiated Services Mechanisms packets: in and out bit 1.0 edge routers: tag packets core routers: RIO (RED with In and Out) MaxP AvgLen Min out Min in Max out Max in Framework Implementation Service Allocation Profile Traffic Specification what exactly is provided? (e.g. 5 Mbps average throughput) Geographic Scope To where the service is provided? (e.g. a group of destinations, or all in a particular network, or every where etc) Probability of Assurance With what level of assurance the service is provided? (level of performance uncertainty the user is expected to tolerate) Profile Meter meters the traffic and test it for conformance to the service allocation profile marks the conformant packets in (in-profile) and the packets exceeding the profile as out (out-profile) Preferential Dropping Scheme Every router must be capable of preferentially dropping tagged (marked) packets Some sort of RED

22 Implementation Scenario M2 ISP1 R D M3 M4 ISP2 R D M5 M6 ISP3 R D H1 M1 H2 Location of Profile Meters Inside the source host policy meter it marks the packets based on policy relationship with the ISP At the network entrance point checks the incoming traffic and marks the packets out if they exceed the profile At the network exit point policy meter it chooses the packets to mark based on administrative policy Edge Routers at the access networks interfacing source hosts meter the flows at the network edges interfacing other networks operating under peering relationship with the other network meter flow aggregates (aggregation of flows) Core Routers perform preferential dropping on flow aggregates Implementation Algorithm Differential Dropping RIO: RED routers with in/out bit Twin Algorithm two sets of RED parameters one for in packets one for out packets upon packet arrival router determines whether packet is in or out For in packets router computes avg_in, average number of in packets in the queue three RED parameters are min_in, max_in, and Pmax_in [0, min_in) normal operation [min_in, max_in) congestion avoidance phase [max_in, ) congestion control phase For out packets router computes avg_total, average number of total (in+out) packets in the queue three RED parameters are min_out, max_out, and Pmax_out [0, min_out) normal operation [min_out, max_out) congestion avoidance phase [max_out, ) congestion control phase

23 RIO Characteristics P(drop) P(drop) Pmax_out Min out Max out Pmax_in Avg_total Min in Max in Avg_in RIO router drops out packets more aggressively than in packets it drops out packets much earlier than in packets, by choosing min_out smaller than min_in it drops out packets with a higher probability than in packets during congestion avoidance phase by setting Pmax_out higher than Pmax_in it goes into congestion control phase for out packets much earlier by choosing max_out smaller than max_in it drops out packets first when it detect incipient congestion, and drops all out packets if the congestion persists It drops in packets only as a last resort when the router is flooded with in packets this should not happen in a well-provisioned network if the router consistently operates in congestion control phase indicated by in packet drop rate, it shows that the router is under-provisioned Simulation Using ns-2 Ten TCP connections via a single ISP All connections share a common link with BW 33 Mbps The connections have different RTTs from 20 to 100 ms Their target rates R T are either 1 Mbps or 5 Mbps All TCP connections run for 20 s A 33 Mbps 5 ms B

24 Result TCP connections only Connection RTT RED routers R T With RIO # (ms) (Mbps) (Mbps) (Mbps) Total Parameters for RED (10, 30, 0.02) Parameters for RIO - for in packets (40, 70, 0.02) and for out packets (10, 30, 0.2) TCP Reno Result TCP + CBR connections Connection RTT Today s Internet R T With RIO # (ms) (Mbps) (Mbps) (Mbps) CBR Total Parameters for RIO - for in packets (40, 70, 0.02) and for out packets (10, 30, 0.2) TCP SACK CBR is UDP traffic at 6 Mbps

25 Conclusion Scalable edge routers do metering, marking and differential dropping core routers only perform differential dropping edge routers in access network potentially perform per flow policing all other routers perform actions on in and out packets aggregate flow Service profile contains service assurance qualitative it delivers service assurance by protecting TCP from non-responsive to congestion flows Recognizes ISP domain boundaries Service delivery requires proper provisioning RIO provides basis of Differentiated Services Architecture Differentiated Service Architecture (RFC 2475) Differentiated Service Architecture defines an architecture for implementing scalable service differentiation in internet Service A "Service" defines some significant characteristics of packet transmission in one direction across a set of one or more paths within a network. These characteristics may be specified in quantitative or statistical terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources. Architectural Components Per-hop forwarding behavior Packet classification functions Traffic conditioning functions including metering, marking, policing and shaping Scalable introduce complex classification and traffic conditioning at network boundary nodes network core nodes apply per-hop behavior on packets marked by edge routers with appropriate DS code point DS code code point indicates per-hop behavior to be invoked It provides service differentiation in only one direction asymmetric

26 Per-Hop Behavior (PHB) A per-hop behavior is externally observable forwarding behavior at a DS node applied to a DS behavior aggregates DS behavior aggregate: a group of packets with the same DS code point crossing the link in a particular direction observable forwarding behavior: loss, delay and jitter in the event that only one behavior aggregate occupies a link, the observable forwarding behavior often depends upon relative link loading when multiple behavior aggregates compete for the link resources, the distinctions in observable behavior can be made a simple example of a PHB is one that guarantees certain minimal share X% of link bandwidth (over a reasonable time interval) to a behavior aggregate The PHB is the means by which a router allocates resources to a behavior aggregate It can be specified: in terms of its resource requirement, e.g. buffer space, bandwidth in terms of its priority relative to other PHBs in terms of relative observable traffic characteristics, e.g. delay, loss PHBs are implemented at a node by buffer management and scheduling DiffServ (DS) Code Point 8-bit field in IP Header defined in RFC 2474 The DS Field contains the DS Code Point (DSCP) DS Field DS Field is not compatible with ToS ToS Field

27 Class Selector (CS) Code Point RFC 2474 Provides backwards compatibility with legacy routers Uses 3 IP Precedence bits in ToS Field ToS Field 8 Code Points CS7 (Highest priority).. CS0 (Lowest priority) Packet Treatment at Network Edge Policing Shaping Marking DSCP Scheduling Multi-Field Classification Filtering based on: Source/Destination IP Address, TCP/UDP Port, Protocol ID Policing Does the flow conform to policy? Marking Mark DS Code Point (DSCP) based on network policy Congestion Management Drop Precedence Congestion Avoidance: RED Shaping Improves efficiency of link speed Scheduling Ensures queues get serviced according to priorities

28 Packet Treatment at Network Core Policing Shaping Scheduling Marking DSCP Scheduling Shaping Behavior Aggregate (BA) Classification Filtering based on: DS Code Point (DSCP) Congestion Management Drop Precedence Congestion Avoidance: RED Shaping Improves efficiency of link speed Scheduling Ensures queues get serviced according to priorities Assured Forwarding PHB (RFC 2597) AF PHB provides different level of forwarding assurances It is designed in response to a demand for some kind of assured forwarding of IP packets e.g. a company with several sites desire to receive assurance on packet forwarding at high probability for its intranet traffic as long as its traffic aggregate from each site does not exceed some agreed upon subscribed bit rate if the packets exceed the profile (out-profile), then they are not delivered at high probability as the probability of in-profile packet delivery packets of the same micro-flow are not re-ordered regardless whether they are in or out packets AF PHB Four classes, where each class is allocated certain bandwidth and buffer resources within each AF class there are three drop precedence at time of congestion the drop precedence within a class determines the drop probability of a packet in that class congested router protect packets marked with lower drop precedence code point by preferentially dropping packets marked with higher drop precedence code point within a DS router the level of forwarding assurance depends upon: the amount of bandwidth and buffer space allocated to an AF class the current load within the AF class the drop precedence marking of the packets

29 AF PHB AF PHB implementation A DS router must implement at least two loss probability within each AF class this will be suffice in a network, e.g. enterprise network, where congestion is a rare and brief occurrence it can implement three loss probabilities with an AF class in a network where congestion is more frequent and persistent it must not re-order packets belong to the same AF class regardless of their drop precedence values it can delay the packet without any quantified bound on delay and jitter an AF implementation must avoid long term congestion while respond to short term congestion (packet bursts) by queuing packets it can drop packets to minimize long term congestion it can queue packets to respond short term congestion e.g by employing AQM the packet drop algorithm must be insensitive to short term traffic characteristics of micro-flows using an AF class micro-flows with same long term rate but different short term burst shapes receive the same loss probability it should treat packets at same drop precedence within an AF class equally this means that the loss probability of a micro-flow depends upon its share of bandwidth within that drop precedence level AF PHB Classes Lowest Discard Highest Discard Drop Precedence Class 1 Class 2 Class 3 Class 4 Low AF11 AF21 AF31 AF41 Medium AF12 AF22 AF32 AF42 High AF13 AF23 AF33 AF43 Olympic Service Drop Precedence Gold Bronze Silver Low AF11 AF21 AF31 Medium AF12 AF22 AF32 High AF13 AF23 AF33

30 Expedited Forwarding PHB (RFC 3246) Provide low delay, low jitter, and low loss service It ensures that an aggregate is served at a certain configured rate Dominant cause of delay in internet is propagation delay and queuing delay Queuing delay introduces delay variation or jitter to packet forwarding Jitter is defined as variation between maximum and minimum delay The packets suitably marked to receive EF PHB treatment in the network encounters short or empty queue As a corollary effect short or empty queue causes low losses To ensure short queue encountered by EF packets 1. The service rate at a given output interface offered to the EF packets must exceed their arrival rate at that interface for long and short time intervals 2. Independent of the load of other traffic EF PHB The EF PHB ensures that each receives guaranteed service at or above configured rate provides means to quantify the accuracy with which the configured service rate is delivered over any time interval also provides a means to quantify the maximum delay and jitter that a packet may experience under bounded operating conditions Designed to emulate a leased line Packets Egress the node with minimal delay Preempts Lower Priority Traffic Classes Uses Priority Queuing Drops packets that exceed maximum configured rate