Quality of Service (QoS) EE 122: Intro to Communication Networks Fall 2006 (MW 4-5:30 in Donner 155) Vern Paxson TAs: Dilip Antony Joseph and Sukun Kim http://inst.eecs.berkeley.edu/~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica, and colleagues at Princeton and UC Berkeley 1 Announcements Homework #3 solutions now available Reminder, phase 1 of Project #3 due this Thurs evening with no slip days 2 1
Goals of Today s Lecture How can we get some sort of reliable performance from the network? If we need it QoS mechanisms from fine-grained to large-scale: Queuing algorithms beyond FIFO (isolation, fairness) End-to-end network reservations (Integrated Services) First Class vs. Coach (Differentiated Services) Why none of this actually works At least, not end-to-end The struggle over network neutrality 3 Scheduling Decide when and what packet to send on output link Classifier partitions incoming traffic into flows each with their own FIFO queue flow 1 1 Classifier flow 2 Scheduler 2 flow n Buffer management 4 2
Link Scheduling: FIFO What if scheduler uses one first-in first-out queue? Simple to implement But, restrictive in providing guarantees Example: two kinds of traffic Video conferencing needs high bandwidth and low delay E.g., 1 Mbps and 100 msec delay E-mail transfers not very sensitive to delay Cannot admit much e-mail traffic Since it will interfere with the video conference traffic 5 Link Scheduling: Strict Priority Strict priority Multiple levels of priority Always transmit high-priority traffic, when present.. and force the lower priority traffic to wait Isolation for the high-priority traffic Almost like it has a dedicated link Except for the (small) delay for packet transmission High-priority packet arrives during transmission of low-priority Router completes sending the low-priority traffic first 6 3
Link Scheduling: Weighted Fairness Limitations of strict priority Lower priority queues may starve for long periods even if the high-priority traffic can afford to wait Traffic still competes inside each priority queue Weighted fair scheduling Assign each queue a fraction of the link bandwidth Rotate across the queues on a small time scale Send extra traffic from one queue if others are idle 50% red, 25% blue, 25% green 7 Max-Min Fairness Denote C link capacity N number of flows r i arrival rate Max-min fair rate computation: 1. compute C/N 2. if there are flows i such that r i C/N, update C and N C = C " $ r i ; N = N " k (for k such flows) i s.t r i #C / N 3. if no, f = C/N; terminate 4. go to 1 Flows receive at most the fair rate, i.e., min(f, r i ) 8 4
Example C = 10; r 1 = 8, r 2 = 6, r 3 = 2; N = 3 C/3 = 3.33 Can service all of r 3 Remove r 3 from the accounting: C = C r 3 = 8; N = 2 C/2 = 4 Can t service all of r 1 or r 2 So hold them to the remaining fair share: f = 4 8 6 2 10 4 4 2 f = 4: min(8, 4) = 4 min(6, 4) = 4 min(2, 4) = 2 9 Fair Queuing (FQ) [DKS 89] Conceptually, computes when each bit in the queue should be transmitted to attain max-min fairness (a fluid flow system approach) Then serve packets in the order of the transmission time of their last bits 10 5
Example Flow 1 (arrival traffic) 1 2 3 4 5 6 time Flow 2 (arrival traffic) 1 2 3 4 5 time Service in fluid flow system 1 2 1 2 3 3 4 4 5 6 5 time Packet system 1 2 1 3 2 3 4 4 5 5 6 time 11 Fair Queuing (FQ) [DKS 89] Conceptually, computes when each bit in the queue should be transmitted to attain max-min fairness (a fluid flow system approach) Then serve packets in the order of the transmission time of their last bits Provides isolation: misbehaving flow can t impair others Doesn t solve congestion: still need to deal with individual queues filling up Generalized to Weighted Fair Queuing (WFQ) 12 6
Reserving Resources End-to-End Source sends a reservation message E.g., this flow needs 5 Mbps Each router along the path Keeps track of the reserved resources E.g., the link has 6 Mbps left Checks if enough resources remain E.g., 6 Mbps > 5 Mbps, so circuit can be accepted Creates state for flow and reserves resources E.g., now only 1 Mbps is available 13 Specifying Bursty Traffic Option #1: Specify the maximum bit rate Maximum bit rate may be much higher average Reserving for the worst case is wasteful Option #2: Specify the average bit rate Average bit rate is not sufficient Network will not be able to carry all of the packets Reserving for average case leads to bad performance Option #3: Specify the burstiness of the traffic Specify both the average rate and the burst size Allows the sender to transmit bursty traffic and the network to reserve the necessary resources 14 7
Characterizing Burstiness: Token Bucket Parameters r average rate, i.e., rate at which tokens fill the bucket b bucket depth (limits size of burst) R maximum link capacity or peak rate A bit is transmitted only when token is available r bps bits Maximum # of bits sent b bits b R/(R-r) slope R slope r regulator R bps time 15 Traffic Enforcement: Example r = 100 Kbps; b = 3 Kb; R = 500 Kbps (a) (b) 3Kb 2.2Kb T = 0 : 1Kb packet arrives 2.4Kb (c) 3Kb T = 2ms : packet transmitted b = 3Kb 1Kb + 2ms*100Kbps = 2.2Kb (d) (e) 0.6Kb T = 4ms : 3Kb packet arrives T = 10ms : packet needs to wait until enough tokens are in the bucket T = 16ms : packet transmitted 16 8
Source Traffic Characterization: Arrival Curve Arrival curve maximum amount of bits transmitted during an interval of time Δt Use token bucket to bound arrival curve bps bits Arrival curve time Δt 17 Arrival Curve: Example Arrival curve maximum amount of bits transmitted during an interval of time Δt Use token bucket to bound arrival curve bits (R=2,b=1,r=1) Arrival curve bps 2 1 4 3 2 1 0 1 2 3 4 5 time 1 2 3 4 5 Δt 18 9
QoS Guarantees: Per-hop Reservation End-host: specify arrival rate characterized by token-bucket with parameters (b,r,r) the maximum admissible delay D, no losses Router: allocate bandwidth r a, buffer space B a such that no packet is dropped no packet experiences a delay larger than D bits slope r a slope r Arrival curve b*r/(r-r) R B a D 19 Ensuring the Source Behaves Guarantees depend on the source behaving Extra traffic might overload one or more links Leading to congestion, and resulting delay and loss Solution: need to enforce the traffic specification Solution #1: policing Drop all data in excess of the traffic specification Solution #2: shaping Delay the data until it obeys the traffic specification Solution #3: marking Mark all data in excess of the traffic specification and give these packets lower priority in the network 20 10
Integrated Services: Required Elements Reservation Protocol How service request gets from host to network Admission control algorithm How network decides if it can accept flow Packet scheduling algorithms How routers deliver service Architecture for solution: IntServ Provides service guarantees at a per-flow granularity 21 Control Plane vs. Data Plane Control plane: How information gets to routers Data plane: What routers do with that information when processing data packets Control Data 22 11
Control Plane: Resource Reservation Sender Receiver 23 Control Plane: Resource Reservation Sender Sender sends specification of traffic profile Receiver 24 12
Control Plane: Resource Reservation Sender Path established (or perhaps admission control denies path) Receiver 25 Control Plane: Resource Reservation Sender Receiver The receiver signals reservation request 26 13
Control Plane: Admission Control Sender Per-flow state (soft state) Receiver 27 Control Plane: Admission Control Sender Per-flow state on all routers in path Receiver 28 14
Data Plane Sender Receiver Per-flow classification on each router 29 Data Plane Sender Receiver Per-flow classification on each router 30 15
Data Plane Sender Per-flow scheduling on each router Receiver 31 5 Minute Break Questions Before We Proceed? 32 16
Admission Control Parameter-based: worst case analysis Guaranteed service Lower utilization Measurement-based: measure current traffic Controlled load service Higher utilization Remember that best-effort service co-exists No need for IntServ traffic to achieve high utilization 33 Problems with IntServ Scalability: per-flow state & classification Aggregation/encapsulation techniques can help Can overprovision big links, per-flow ok on small links Scalability can be fixed - but no second chance Economic arrangements: Need sophisticated settlements between ISPs Contemporary settlements are primitive Unidirectional, or barter User charging mechanisms: need QoS pricing On a fine-grained basis 34 17
Differentiated Services (DiffServ) Give some traffic better treatment than other Application requirements: interactive vs. bulk transfer Economic arrangements: first-class versus coach What kind of better service could you give? Fewer drops Lower delay Lower delay variation (jitter) How to know which packets get better service? Bits in packet header Deals with traffic in aggregate Provides weaker services But much more scalable 35 Diffserv Architecture Ingress routers - entrance to a DiffServ domain Police or shape traffic Set Differentiated Service Code Point (DSCP) in IP header Core routers Implement Per Hop Behavior (PHB) for each DSCP Process packets based on DSCP DS-1 DS-2 Ingress Egress Ingress Egress Edge router Core router 36 18
Differentiated Service (DS) Field 0 5 6 7 DS Field ECN 0 4 8 16 19 31 Version HLen TOS Length Identification Flags Fragment offset TTL Protocol Header checksum Source address Destination address Data IP header DS field encodes Per-Hop Behavior (PHB) E.g., Expedited Forwarding (all packets receive minimal delay & loss) E.g., Assured Forwarding (packets marked with low/high drop probabilities) 37 Comparison to Best-Effort & Intserv Service Service scope Complexity Scalability Best-Effort Connectivity No isolation No guarantees End-to-end No setup Highly scalable (nodes maintain only routing state) Diffserv Per aggregate isolation Per aggregate guarantee Domain Long term setup Scalable (edge routers maintain per aggregate state; core routers per class state) Intserv Per flow isolation Per flow guarantee End-to-end Per flow steup Not scalable (each router maintains per flow state) 38 19
Discussion: Limited QoS Deployment End-to-end QoS across multiple providers/domains is not available today Issue #1: complexity of payment Requires payment system among multiple parties And agreement on what constitutes service Diffserv tries to structure this as series of bilateral agreements but lessens likelihood of end-to-end service Architecture includes notion of Bandwidth Broker for end-toend provisioning Solid design has proved elusive Need infrastructure for metering/billing end user 39 Limited QoS Deployment, con t Issue #2: prevalence of overprovisioning Within a large ISP, links tend to have plenty of headroom Inter-ISP links are not over provisioned, however Is overprovisioning enough? If so, is this only because access links are slow? What about Korea, Japan, and other countries with fast access links? Disconnect: ISPs overprovision, users get bad service Key difference: intra-isp vs. general end-to-end 40 20
Exploiting Lack of End-to-End QoS Suppose an ISP offers their own Internet service E.g., Portal (ala Yahoo), search engine (ala Google) Then it s in their interest that service to Yahoo or Google is inferior So customers prefer to use their value-added services ISP can recognize traffic to competitor and demote it charge competitor if they want well-provision paths just not put effort/$ into high-capacity interconnects w/ other ISPs; congestion provides traffic demotion directly Works particularly well for large providers w/ lots of valuable content 41 Network Neutrality Network neutrality = notion that ISPs supply non-discriminated IP connectivity Opposite counterpoint: a Walled Garden Provider only allows you to access their (often value-added) services E.g., AOL s captive Web portal/email/im Highly contentious; potential legal fray E.g., ISPs blocking Voice-over-IP (VOIP) As does China, Panama, Costa Rica E.g., ISPs blocking 25/tcp (SMTP) to curb spammers 42 21
Network Neutrality, con t Is Internet access something that ISPs provide as common carriers? Transporting goods as service to common public Or: will free market forces serve to shape ISP favoritism efficiently? Is there a danger of monopolies emerging? Many QoS-sensitive apps can be written in an adaptive style to deal with uncertainties But what about stricter apps? Standard example: telesurgery 43 Summary Basic mechanism for achieving better-than-best-effort performance: scheduling Multiple queues allow priority service Fair queuing provides isolation between flows But: still need end-to-end mechanisms Reservations & admission control Descriptions of bursty traffic: token buckets IntServ provides per-flow performance guarantees But lacks scalability DiffServ provides per-aggregate tiers of relative perf. Scalable, but not as powerful Neither is generally available end-to-end today ISPs manipulating what services receive what performance raises issues of network neutrality 44 22