350 likes | 491 Views
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.
E N D
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 ArchitectureSLA Between AS1 and AS2 Autonomous System 1 Egress Router may have to reshape premium traffic relative to SLA between systems First Hop Router – “edge” of network Interior Router maintains two queues Destination Ingress Router – doesn’t need to classify, but does need to police Autonomous System 2
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 Company A Packets in premium flows have bit set Premium packet flow restricted to R bytes/sec internal router ISP host border router first hop router border router Unmarked packet flow
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 Marker Classifier Marker
When a Packet Arrives at Leaf Router Marker 1 Flow 1 Marker N Flow N Forwarding engine Clear A & P bits Packet classifier Arriving packet Best effort Markers: service class (Premium or assured), rate (peak for premium, expected for assured), permissible burst size (may not apply to premium)
P-bit Set? 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 Best Effort Queue No Yes 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
No token token Packet output Packet input Test if token Set A bit Marker Diagram Drop on overflow Packet input Packet output Wait for token Set P bit
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.
Forced drop Maxthreshold Probabilisticearly drop Minthreshold No drop Initial drop probability 100% maxp Weighted Average Queue Length minth maxth RED Drop Probabilities Instantaneous queue length Maxqueue length Time
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 Pin with probability Pin, 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 P(drop) 1.0 MaxP AvgLen Minout Minin Maxout Maxin
Router Output Interface for Two-bit Architecture yes P-bit set? High-priority Q Packets out no If A-bit set incr A_cnt Low-priority Q If A-bit set decr A_cnt RIO queue management
Border Router Input Interface Profile Meters no Token available? Clear A-bit A set token Forwarding engine Arriving packet Not marked Is packet marked? token P set no Token available? Drop packet
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