A Two-bit Differentiated Services Architecture K. Nichols, V. Jacobson, L. Zhang presented by Wendy Edwards

Outline Motivation Better quality internet services Differentiated services –Overview –How it works –Who gets what? –Discussion

Motivation “If That’s Your Best, Your Best Won’t Do” Twisted Sister (Heavy Metal Band) Internet is currently best- effort. We want better service for some applications. Telephony, multimedia have problems with delays and variable bandwidth.

Approaches Integrated Services Differentiated Services

Integrated Service Components Reservations Admission Control Scheduling Traffic shaping

Why IntServ Won’t Fly Scalability problems Per flow state at each router Each router has to classify each packet On-demand reservations are complex

Differentiated Services In this paper, two different levels of service proposed, Premium and Assured Recommends we use both, using one bit to represent each.

DiffServ Vs. IntServ Goals are same, but mechanisms are different Bandwidth, rather than delay, will be key parameter Mostly static allocation

DiffServ Goals Keep forwarding path simple Push complexity to edges of network No assumptions about types of traffic (don’t assume multicasting) Allocation policy works with long-term and short- term provisioning Dominant Internet model remains best effort (most of the traffic will be best effort)

DiffServ Architecture SLA Between AS1 and AS2 Autonomous System 2 Autonomous System 1 Destination Interior Router maintains two queues Egress Router may have to reshape premium traffic relative to SLA between systems Ingress Router – doesn’t need to classify, but does need to police First Hop Router – “edge” of network

Premium Services Guaranteed peak rate Shaped/hard-limited, so no bursts Cannot be oversubscribed, so it may be under-provisioned Gets priority over all other traffic Extra traffic may be dropped

Premium Traffic Flow From End-host to Organization’s ISP first hop router internal router border router host border router ISP Company A Unmarked packet flow Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec

Assured Services Better than best-effort, though it’s not clear how much better “Expected capacity” usage profile Unlikely to be dropped if it stays within profile Described by average and burst rates Extra traffic is sent as best-effort

First Hop/Edge Router Classification (detect A or P bit traffic) Marking (if traffic conforms to profile, mark) Forwarding – premium queue is forwarded first

First Hop Router Overview Configuration Info Classifier Marker

When a Packet Arrives at Leaf Router Clear A & P bits Packet classifier Marker 1 Marker N Forwarding engine Arriving packet Best effort Flow 1 Flow N Markers: service class (Premium or assured), rate (peak for premium, expected for assured), permissible burst size (may not apply to premium)

Two Queues There are two queues, one for premium and one for assured and best-traffic. The routers check the P-bit of a packet and assign it to the appropriate queue P-bit Set? No Yes Best Effort Queue Premium Queue

Assured Service In best-effort queue, no congestion = no problem. When there is congestion, –Assured packets within profile are served first, and best-effort traffic is dropped using RED algorithm. –When some assured packets are not within profile, uses two-tiered RED mechanism called “RIO” (RED with In or Out).

Markers Leaf routers have traffic profiles - they classify packets based on packet header If no profile present, pass as best effort If profile is for Assured Traffic: –mark in-profile packets (token is available) with A, forward others unmarked where they will be treated as best effort If profile is for Premium Traffic: –delay out-of -profile packets in queue until token becomes available. If queue overflows, drop packets

Marker Diagram Wait for token Set P bit Packet input Packet output Test if token Set A bit token No token Packet input Packet output Drop on overflow

RED Overview Random Early Detection – a mechanism by which the router can more accurately manage its queue length. Each router monitors its own queue length and notify sources of imminent congestion. RED does this implicitly by dropping packet earlier than it would have to (before buffer space is exhausted) to encourage source to slow down. Two thresholds – first one drops packets with probability p, and second drops packets completely. Uses weighted running queue length because traffic is bursty. Since RED drops packets randomly, the probability that RED decides to drop a particular flow’s packets is roughly proportional to the share of bandwidth flow is getting.

RED Drop Probabilities Time Max queue length Min threshold Max threshold Instantaneous queue length Forced drop No drop Probabilistic early drop 100% Initial drop probability max p Weighted Average Queue Length min th max th

RIO – RED With In or Out Similar to RED, but with two separate probability curves Has two classes, “In” and “Out” (of profile) “Out” class has lower minimum threshold, so packets are dropped from this class first As avg queue length increases, “in” packets are dropped Since best-effort is included in the “Out” class, assured traffic can starve best-effort

RIO Algorithm For each packet arrival if it is an In packet calculate the average In queue size avg_in; calculate the average queue size avg_total; If it is an In packet. if min_in < avg_in < max_in calculate probability P in with probability P in, drop this packet; else if max_in < avg_in drop this packet. If it is an Out packet if min_out < avg_total < max_out calculate probability Pout; with probability Pout drop this packet; else if max_out < avg_total drop this packet.

RIO Drop Probability Curve MaxP 1.0 Min out Min in Max in Max out P(drop) AvgLen

Router Output Interface for Two-bit Architecture P-bit set? If A-bit set incr A_cnt High-priority Q Low-priority Q If A-bit set decr A_cnt RIO queue management Packets out yes no

Border Router Input Interface Profile Meters Arriving packet Is packet marked? Token available? Token available? Clear A-bit Drop packet Forwarding engine A set P set token Not marked no

TSW- Time Sliding Window Alternative to RED as a mechanism for traffic policing Two components –Rate estimator smooths out burstiness of TCP traffic and is sensitive to instantaneous sending rate –Tagging algorithm tags packets as out once traffic exceeds certain threshold

TSW Design Three state variables –Win_length – measured in units of time –Avg_rate – rate estimate of last packet arrival –T_front – time of last packet arrival Avg_rate and T_front are updated each time a packet arrives, but Win_length is preconfigured TSW contains “decaying” function that forgets history over time

TSW Algorithm Initially Win_length = a constant; Avg_rate = connection’s target rate RT T_front = 0; Upon each packet arrival Bytes in TSW = Avg_rate * Win_length; New_bytes = Bytes_in_TSW + pkt_size; Avg_rate = New_bytes / (now – T_front + Win_length); T_front = now;

Static Allocation Pre-determined, long-term static allocations End-to-end bandwidth guarantees based on series of bilateral agreements Automatic aggregation Manual configuration

Bandwidth Brokers “Who gets to use the bandwidth when?” Agents that allocate and control bandwidth shares Receives requests from peers (or domain it controls) and responds. Only need to have limited trust relationships with peers (rather flowspecs in all routers in an end-to-end path) Responsibilities –Parcel out region’s marked traffic –Manage messages sent across boundaries to adjacent BBs

Example 1: Bandwidth Broker Statically configured example with BB messages exchanged

Example 2: Bandwidth Broker End-to-end example with static allocation

Example 3: Bandwidth Broker End-to-end static allocation with no remaining allocation