Question? Leave a message!




Better-than-best-effort: QoS, IntServ, DiffServ, RSVP, RTP

Better-than-best-effort: QoS, IntServ, DiffServ, RSVP, RTP 30
Betterthanbesteffort: QoS, IntServ, DiffServ, RSVP, RTP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1Overview  Why betterthanbesteffort (QoSenabled) Internet  Quality of Service (QoS) building blocks  Endtoend protocols: RTP, H.323  Network protocols:  Integrated Services(IntServ), RSVP.  Scalable differentiated services: DiffServ  Control plane: QoS routing, traffic engineering, policy management, pricing models Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2Why BetterthanBestEffort (QoS)  To support a wider range of applications Realtime, Multimedia, etc  To develop sustainable economic models and new private networking services Current flat priced models, and besteffort services do not cut it for businesses Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3Quality of Service: What is it Multimedia applications: network audio and video QoS network provides application with level of performance needed for application to function. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4What is QoS  “Better performance” as described by a set of parameters or measured by a set of metrics.  Generic parameters: Bandwidth Delay, Delayjitter Packet loss rate (or loss probability)  Transport/Applicationspecific parameters: Timeouts Percentage of “important” packets lost Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5What is QoS (contd)  These parameters can be measured at several granularities: “micro” flow, aggregate flow, population.  QoS considered “better” if a) more parameters can be specified b) QoS can be specified at a finegranularity.  QoS spectrum: Best Effort Leased Line Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6Fundamental Problems Scheduling Discipline FIFO B B  In a FIFO service discipline, the performance assigned to one flow is convoluted with the arrivals of packets from all other flows  Cant get QoS with a “freeforall”  Need to use new scheduling disciplines which provide “isolation” of performance from arrival rates of background traffic Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7Fundamental Problems  Conservation Law (Kleinrock): (i)W (i) = K q  Irrespective of scheduling discipline chosen:  Average backlog (delay) is constant  Average bandwidth is constant  Zerosum game = need to “setaside” resources for premium services Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8QoS Big Picture: Control/Data Planes Control Plane: Signaling + Admission Control or SLA (Contracting) + Provisioning/Traffic Engineering Router Workstation Router Router Workstation Internetwork or WAN Data Plane: Traffic conditioning (shaping, policing, marking etc) + Traffic Classification + Scheduling, Buffer management Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9QoS Components  QoS = set aside resources for premium services  QoS components: a) Specification of premium services: (service/service level agreement design) b) How much resources to set aside (admission control/provisioning) c) How to ensure network resource utilization, do load balancing, flexibly manage traffic aggregates and paths (QoS routing, traffic engineering) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10QoS Components (Continued) d) How to actually set aside these resources in a distributed manner (signaling, provisioning, policy) e) How to deliver the service when the traffic actually comes in (claim/police resources) (traffic shaping, classification, scheduling) f) How to monitor quality, account and price these services (network mgmt, accounting, billing, pricing) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11How to upgrade the Internet for QoS  Approach: decouple endsystem evolution from network evolution  Endtoend protocols: RTP, H.323 etc to spur the growth of adaptive multimedia applications Assume besteffort or betterthanbesteffort clouds  Network protocols: IntServ, DiffServ, RSVP, MPLS, COPS … To support betterthanbesteffort capabilities at the network (IP) level Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12QOS SPECIFICATION, TRAFFIC, SERVICE CHARACTERIZATION, BASIC MECHANISMS Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13Service Specification  Loss: probability that a flow‟s packet is lost  Delay: time it takes a packet‟s flow to get from source to destination  Delay jitter: maximum difference between the delays experienced by two packets of the flow  Bandwidth: maximum rate at which the soource can send traffic  QoS spectrum: Best Effort Leased Line Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14Hard Real Time: Guaranteed Services  Service contract Network to client: guarantee a deterministic upper bound on delay for each packet in a session Client to network: the session does not send more than it specifies  Algorithm support Admission control based on worstcase analysis Per flow classification/scheduling at routers Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15Soft Real Time: Controlled Load Service  Service contract: Network to client: similar performance as an unloaded besteffort network Client to network: the session does not send more than it specifies  Algorithm Support Admission control based on measurement of aggregates Scheduling for aggregate possible Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16Traffic and Service Characterization  To quantify a service one has two know Flow‟s traffic arrival Service provided by the router, i.e., resources reserved at each router  Examples: Traffic characterization: token bucket Service provided by router: fix rate and fix buffer space  Characterized by a service model (service curve framework) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17Token Bucket  Characterized by three parameters (b, r, R) b – token depth r – average arrival rate R – maximum arrival rate (e.g., R link capacity)  A bit is transmitted only when there is an available token When a bit is transmitted exactly one token is consumed r tokens per second bits slope r bR/(Rr) b tokens slope R = R bps time Shivkumar Kalyanaraman Rensselaer Polytechnic Institute regulator 18Characterizing a Source by Token Bucket  Arrival curve – maximum amount of bits transmitted by time t  Use token bucket to bound the arrival curve bps bits Arrival curve time time Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19Example  Arrival curve – maximum amount of bits transmitted by time t  Use token bucket to bound the arrival curve (b=1,r=1,R=2) Arrival curve bits 4 bps 3 2 2 1 1 0 1 2 3 4 5 1 2 3 4 5 time size of time interval Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20Perhop Reservation  Given b,r,R and perhop delay d  Allocate bandwidth r and buffer space B such that to a a guarantee d slope r a slope r bits Arrival curve b d B a Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21What is a Service Model “external process” Network element delivered traffic offered traffic (connection oriented)  The QoS measures (delay,throughput, loss, cost) depend on offered traffic, and possibly other external processes.  A service model attempts to characterize the relationship between offered traffic, delivered traffic, and possibly other external processes. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22Arrival and Departure Process R Network Element R in out bits R (t) = arrival process in = amount of data arriving up to time t delay buffer R (t) = departure process out = amount of data departing up to time t t Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23Traffic Envelope (Arrival Curve)  Maximum amount of service that a flow can send during an interval of time t b(t) = Envelope slope = max average rate “Burstiness Constraint” slope = peak rate Shivku tmar Kalyanaraman Rensselaer Polytechnic Institute 24Service Curve  Assume a flow that is idle at time s and it is backlogged during the interval (s, t)  Service curve: the minimum service received by the flow during the interval (s, t) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25Big Picture Service curve bits bits R (t) in slope = C t t bits R (t) out t Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 26Delay and Buffer Bounds bits E(t) = Envelope Maximum delay Maximum buffer S (t) = service curve t Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 27Mechanisms: Traffic Shaping/Policing  Token bucket: limits input to specified Burst Size (b) and Average Rate (r).  Traffic sent over any time T = rT + b  a.k.a Linear bounded arrival process (LBAP)  Excess traffic may be queued, marked BLUE, or simply dropped Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28Mechanisms: Queuing/Scheduling Traffic Traffic Sources Classes Class A Class B Class C  Use a few bits in header to indicate which queue (class) a packet goes into (also branded as CoS)  High users classified into high priority queues, which also may be less populated = lower delay and low likelihood of packet drop  Ideas: priority, roundrobin, classification, aggregation, ... Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 29Mechanisms: Buffer Mgmt/Priority Drop Drop RED and BLUE packets Drop only BLUE packets  Ideas: packet marking, queue thresholds, differential dropping, buffer assignments Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 30SCHEDULING Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 31Packet Scheduling  Decide when and what packet to send on output link  Usually implemented at output interface flow 1 Classifier flow 2 Scheduler 1 flow n 2 Buffer management Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 32Focus: Scheduling Policies  Priority Queuing: classes have different priorities; class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc.  Transmit a packet from the highest priority class with a nonempty queue  Preemptive and nonpreemptive versions Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 33Scheduling Policies (more)  Round Robin: scan class queues serving one from each class that has a nonempty queue Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 34RoundRobin Discussion  Advantages: protection among flows  Misbehaving flows will not affect the performance of wellbehaving flows Misbehaving flow – a flow that does not implement any congestion control  FIFO does not have such a property  Disadvantages:  More complex than FIFO: per flow queue/state  Biased toward large packets – a flow receives service proportional to the number of packets Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 35Generalized Processor Sharing(GPS)  Assume a fluid model of traffic Visit each nonempty queue in turn (RR) Serve infinitesimal from each Leads to “maxmin” fairness  GPS is unimplementable We cannot serve infinitesimals, only packets Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 36Generalized Processor Sharing  A work conserving GPS is defined as W (t,t dt) W (t,t dt) i i B(t) w w i j jB(t)  where  w – weight of flow i i  W (t , t ) – total service received by flow i during t , t ) i 1 2 1 2  W(t , t ) – total service allocated to all flows during t , t ) 1 2 1 2  B(t) – number of flows backlogged Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 37Fair Rate Computation in GPS  Associate a weight w with each flow i i  If link congested, compute f such that max( r , f w ) C  i i i f = 2: 8 (w = 3) 1 10 min(8, 23) = 6 4 6 (w = 1) min(6, 21) = 2 2 4 2 min(2, 21) = 2 2 (w = 1) 3 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 38Bitbybit Round Robin  Single flow: clock ticks when a bit is transmitted. For packet i: P = length, A = arrival time, S = begin i i i transmit time, F = finish transmit time i F = S +P = max (F , A ) + P i i i i1 i i  Multiple flows: clock ticks when a bit from all active flows is transmitted round number Can calculate F for each packet if number of i flows is known at all times This can be complicated Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 39Packet Approximation of Fluid System  Standard techniques of approximating fluid GPS  Select packet that finishes first in GPS assuming that there are no future arrivals  Important properties of GPS  Finishing order of packets currently in system independent of future arrivals  Implementation based on virtual time  Assign virtual finish time to each packet upon arrival  Packets served in increasing order of virtual times Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 40Fair Queuing (FQ)  Idea: serve packets in the order in which they would have finished transmission in the fluid flow system  Mapping bitbybit schedule onto packet transmission schedule  Transmit packet with the lowest F at any given time i  Variation: Weighted Fair Queuing (WFQ) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 41Approximating GPS with WFQ  Fluid GPS system service order 0 2 4 6 8 10  Weighted Fair Queueing  select the first packet that finishes in GPS Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 42FQ Example Output Flow 1 Flow 2 F=10 F=8 Flow 1 Flow 2 F=5 Output (arriving) transmitting Cannot preempt packet F=10 currently being transmitted F=2 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 43FQ Advantages  FQ protect wellbehaved flows from illbehaved flows  Example: 1 UDP (10 Mbps) and 31 TCP‟s sharing a 10 Mbps link 10 2 9 1.8 RED FQ 8 1.6 7 1.4 6 1.2 5 1 4 0.8 3 0.6 2 0.4 1 0.2 0 0 1 4 7 10 13 16 19 22 25 28 31 1 4 7 10 13 16 19 22 25 28 31 Flow Number Flow Number Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 44 Throughput(Mbps) Throughput(Mbps)System Virtual Time: V(t)  Measure service, instead of time  V(t) slope – rate at which every active flow receives service C – link capacity N(t) – number of active flows in fluid system at time t V(t) V (t) C  t N(t) time Service 1 2 3 4 5 6 1 2 in fluid flow 3 4 5 time system Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 45System Virtual Time  Virtual time (V ) – service that backlogged GPS flow with weight = 1 would receive in GPS W (t,t dt) W (t,t dt) wi B(t) i i w  j jB(t) W wW V 1W i i GPS i B(t)  t wt t wt j jB(t) j jB(t)  t 2 1W  W (t ,t ) w dti B(t) i 1 2 i  tt  1 wt  j jB(t)  Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 46Service Allocation in GPS  The service received by flow i during an interval t ,t ), while it is backlogged is 1 2 t V 2 GPS W (t ,t ) w dti B(t) i 1 2 i  tt 1 t W (t ,t ) w(V (t )V (t ))iB(t) i 1 2 i GPS 2 GPS 1 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 47Virtual Time Implementation of Weighted Fair Queueing (0) 0 V GPS k k S F if session j backlogged j j k if session j unbacklogged S max( F ,V(a )) j j j k L j F S j j w j k  a– arrival time of packet k of flow j j k  S – virtual starting time of packet k of flow j j k  F – virtual finishing time of packet k of flow j j k  L – length of packet k of flow j j Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 48Virtual Time Implementation of Weighted Fair Queueing  Need to keep per flow instead of per packet virtual start, finish time only  System virtual time is used to reset a flow‟s virtual start time when a flow becomes backlogged again after being idle Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 49System Virtual Time in GPS 1/2 1/8 1/8 1/8 1/8 V (t) GPS 2C C 2C 0 4 8 12 16 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 50Virtual Start and Finish Times k  Utilize the time the packets would start S and i k finish F in a fluid system i k L k k i F S i i w i V (t) GPS k F i k S i 0 4 8 12 16 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 51Big Picture  FQ does not eliminate congestion  it just manages the congestion  You need both endhost congestion control and router support for congestion control endhost congestion control to adapt router congestion control to protect/isolate  Don‟t forget buffer management: you still need to drop in case of congestion. Which packet‟s would you drop in FQ one possibility: packet from the longest queue Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 52QoS ARCHITECTURES Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 53ParekhGallager theorem  Let a connection be allocated weights at each WFQ scheduler along its path, so that the least bandwidth it is allocated is g  Let it be leakybucket regulated such that bits sent in time t , t = g(t t ) +  1 2 2 1  Let the connection pass through K schedulers, where the kth scheduler has a rate r(k)  Let the largest packet size in the network be P K1 K end to end delay / g P / g P / r(k)  k1 k1 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 54Significance  PG Theorem shows that WFQ scheduling can provide endtoend delay bounds in a network of multiplexed bottlenecks WFQ provides both bandwidth and delay guarantees Bound holds regardless of cross traffic behavior (isolation) Needs shapers at the entrance of the network  Can be generalized for networks where schedulers are variants of WFQ, and the link service rate changes over time Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 55Stateless vs. Stateful QoS Solutions  Stateless solutions – routers maintain no fine grained state about traffic  scalable, robust  weak services  Stateful solutions – routers maintain perflow state  powerful services guaranteed services + high resource utilization fine grained differentiation protection  much less scalable and robust Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 56Existing Solutions Stateful Stateless  Tenet Ferrari  DiffServ Verma ‟89 QoS Clark  IntServ Clark et al Wroclawski „97 ‟91 Nichols et al ‟97  ATM late ‟80s  Round Robin Nagle  DecBit Ramkrishnan ‟85 Jain ‟88 Network support for  Fair Queueing Random Early Detection congestion Demers et al ‟89 (RED) Floyd Jacobson control ‟93  Flow Random Early Drop (FRED) Lin  BLUE Feng et al ‟99 Morris ‟97  REM Low at al ‟00 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 57Integrated Services (IntServ)  An architecture for providing QOS guarantees in IP networks for individual application sessions  Relies on resource reservation, and routers need to maintain state information of allocated resources (eg: g) and respond to new Call setup requests Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 58Signaling semantics  Classic scheme: sender initiated  SETUP, SETUPACK, SETUPRESPONSE  Admission control  Tentative resource reservation and confirmation  Simplex and duplex setup; no multicast support Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 59RSVP: Internet Signaling  Creates and maintains distributed reservation state  Decoupled from routing: Multicast trees setup by routing protocols, not RSVP (unlike ATM or telephony signaling)  Receiverinitiated: scales for multicast  Softstate: reservation times out unless refreshed  Latest paths discovered through “PATH” messages (forward direction) and used by RESV mesgs (reverse direction). Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 60Call Admission  Session must first declare its QOS requirement and characterize the traffic it will send through the network  Rspec: defines the QOS being requested  Tspec: defines the traffic characteristics  A signaling protocol is needed to carry the R spec and Tspec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 61Call Admission  Call Admission: routers will admit calls based on their Rspec and Tspec and base on the current resource allocated at the routers to other calls. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 62Stateful Solution: Guaranteed Services  Achieve perflow bandwidth and delay guarantees  Example: guarantee 1MBps and 100 ms delay to a flow Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 63Stateful Solution: Guaranteed Services  Allocate resources perform perflow admission control Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 64Stateful Solution: Guaranteed Services  Install perflow state Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 65Stateful Solution: Guaranteed Services  Challenge: maintain perflow state consistent Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 66Stateful Solution: Guaranteed Services  Perflow classification Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 67Stateful Solution: Guaranteed Services  Perflow buffer management Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 68Stateful Solution: Guaranteed Services • Perflow scheduling Receiver Sender Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 69Stateful Solution Complexity  Data path  Perflow classification Perflow State  Perflow buffer … management flow 1  Perflow scheduling flow 2  Control path Scheduler Classifier  install and maintain flow n perflow state for Buffer data and control paths management output interface Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 70Stateless vs. Stateful  Stateless solutions are more scalable robust  Stateful solutions provide more powerful and flexible services guaranteed services + high resource utilization fine grained differentiation protection Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 71Question  Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures Yes, in some interesting cases. DPS, CSFQ.  Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than endtoend flows Yes: Diffserv Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 72Differentiated Services (DiffServ)  Intended to address the following difficulties with Intserv and RSVP;  Scalability: maintaining states by routers in high speed networks is difficult sue to the very large number of flows  Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide „relative‟ service distinction (Platinum, Gold, Silver, …)  Simpler signaling: (than RSVP) many applications and users may only w ant to specify a more qualitative notion of service Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 73Differentiated Services Model Interior Router Egress Ingress Edge Router Edge Router  Edge routers: traffic conditioning (policing, marking, dropping), SLA negotiation  Set values in DSbyte in IP header based upon negotiated service and observed traffic.  Interior routers: traffic classification and forwarding (near stateless core)  Use DSbyte as index into forwarding table Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 74Diffserv Architecture Edge router: marking scheduling perflow traffic r management . marks packets as in b . . profile and outprofile Core router: per class TM buffering and scheduling based on marking at edge preference given to inprofile packets Assured Forwarding Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 75Packet format support  Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6: renamed as “DS”  6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive  2 bits are currently unused Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 76Traffic Conditioning  It may be desirable to limit traffic injection rate of some class; user declares traffic profile (eg, rate and burst size); traffic is metered and shaped if nonconforming Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 77Perhop Behavior (PHB)  PHB: name for interior router dataplane functions Includes scheduling, buff. mgmt, shaping etc  Logical spec: PHB does not specify mechanisms to use to ensure performance behavior  Examples: Class A gets x of outgoing link bandwidth over time intervals of a specified length Class A packets leave first before packets from class B Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 78PHB (contd)  PHBs under consideration: Expedited Forwarding: departure rate of packets from a class equals or exceeds a specified rate (logical link with a minimum guaranteed rate) Emulates leasedline behavior Assured Forwarding: 4 classes, each guaranteed a minimum amount of bandwidth and buffering; each with three drop preference partitions  Emulates framerelay behavior Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 79Question  Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures Yes, in some interesting cases. DPS, CSFQ.  Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than endtoend flows Yes: Diffserv Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 80Scalable Core (SCORE)  A trusted and contiguous region of network in which  edge nodes – perform per flow management  core nodes – do not perform per flow management edge nodes core nodes edge nodes Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 81The DPS Approach 1. Define a reference stateful network that implements the desired service 2. Emulate the functionality of the reference network in a SCORE network Reference Stateful Network SCORE Network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 82The DPS Idea  Instead of having core routers maintaining per flow state have packets carry perflow state Reference Stateful Network SCORE Network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 83Dynamic Packet State (DPS)  Ingress node: compute and insert flow state in packet‟s header Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 84Dynamic Packet State (DPS)  Ingress node: compute and insert flow state in packet‟s header Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 85Dynamic Packet State (DPS)  Core node: process packet based on state it carries and node‟s state update both packet and node‟s state Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 86Dynamic Packet State (DPS)  Egress node: remove state from packet‟s header Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 87Example: DPSGuaranteed Services  Goal: provide perflow delay and bandwidth guarantees  How: emulate ideal model in which each flow traverses dedicated links of capacity r r r r flow (reservation = r )  Perhop packet service time = (packet length) / r Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 88Guaranteed Services  Define reference network to implement service control path: perflow admission control, reserve capacity r on each link data path: enforce ideal model, by using Jitter Virtual Clock (JitterVC) scheduler JitterVC JitterVC JitterVC JitterVC JitterVC JitterVC JitterVC Reference Stateful Network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 89Guaranteed Services  Use DPS to eliminate perflow state in core control path: emulate perflow admission control data path: emulate JitterVC by CoreJitter Virtual Clock (CJVC) JitterVC CJVC JitterVC JitterVC JitterVC CJVC CJVC JitterVC JitterVC CJVC CJVC JitterVC CJVC Reference Stateful Network SCORE Network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 90Endtoend Adaptive Applications Video Coding, Error Video Coding, Error Concealment, Concealment, Unequal Error Unequal Error Protection (UEP) Protection (UEP) Packetization, Packetization, Marking, playout Marking, Source Buffer Management Buffer Management Congestion control Congestion control Internet Endtoend Closedloop control Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 91Endtoend: RealTime Protocol (RTP)  Provides standard packet format for realtime application  Typically runs over UDP  Specifies header fields below  Payload Type: 7 bits, providing 128 possible different types of encoding; eg PCM, MPEG2 video, etc.  Sequence Number: 16 bits; used to detect packet loss Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 92RealTime Protocol (RTP)  Timestamp: 32 bytes; gives the sampling instant of the first audio/video byte in the packet; used to remove jitter introduced by the network  Synchronization Source identifier (SSRC): 32 bits; an id for the source of a stream; assigned randomly by the source Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 93RTP Control Protocol (RTCP)  Protocol specifies report packets exchanged between sources and destinations of multimedia information  Three reports are defined: Receiver reception, Sender, and Source description  Reports contain statistics such as the number of packets sent, number of packets lost, interarrival jitter  Used to modify sender transmission rates and for diagnostics purposes Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 94Eg: Streaming RTSP  User interactive control is provided, e.g. the public protocol Real Time Streaming Protocol (RTSP)  Helper Application: displays content, which is typically requested via a Web browser; e.g. RealPlayer; typical functions: Decompression Jitter removal Error correction: use redundant packets to be used for reconstruction of original stream GUI for user control Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 95Using a Streaming Server  Web browser requests and receives a Meta File (a file describing the object)  Browser launches the appropriate Player and passes it the Meta File;  Player contacts a streaming server, may use a choice of UDP vs. TCP to get the stream Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 96Receiver Adaptation Options  If UDP: Server sends at a rate appropriate for client; to reduce jitter, Player buffers initially for 25 seconds, then starts display  If TCP: sender sends at maximum possible rate; retransmit when error is encountered; Player uses a much large buffer to smooth delivery rate of TCP Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 97H.323  H.323 is an ITU standard for multimedia communications over besteffort LANs.  Part of larger set of standards (H.32X) for videoconferencing over data networks.  H.323 includes both standalone devices and embedded personal computer technology as well as pointtopoint and multipoint conferences.  H.323 addresses call control, multimedia management, and bandwidth management as well as interfaces between LANs and other networks. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 98H.323 Architecture Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 99Interdomain QoS: Challenge  Provide high quality service across ISPs  Problem: intermediate ISPs don’t have incentive to provide “good” service e.g., “hotpotato” policy ISP 2 ISP 3 ISP 1 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 100Approach: Virtual ISP (VISP)  Avoid crossing ISP boundaries  Each ISP will provide good service; VISP can easily verify it  Allocate/buy service across each ISP and compose them GPoP GPoP (core) (core) ISP 2 Proxy Proxy (edge) (edge) ISP 3 ISP 1 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 101Composition Tools for QoS  Dynamic Packet State (DPS):  Proxy (edge): maintain per flow state; label packets  Giga PoPs (core): maintain no per flow state; process packets based on their labels  Closedloop building blocks:  No core upgrades, smaller QoS service spectrum I E Logical FIFO B I E E I Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 102ClosedLoop Building Blocks for QoS International Link or International Link or Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 103Edgebased QoS building blocks I E Logical FIFO I B E E I New: Closedloop control Policy/ Bandwidth Broker Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 104Closedloop QoS Building Blocks Priority/WFQ FIFO B B   Scheduler: differentiates service on a packetby packet basis  Loops: differentiate service on an RTTbyRTT basis using purely edgebased policy configuration. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 105Recall: Accumulationbased CC Schemes 1 j j+1 J d j f i μ i Λ μ i,j+1 i Λ i j … … f J1 q (t d ) i1 i q (t d ) ij k k j d d f j J1 d i f I (t d ,t) q (t) i i iJ a (t) i t O (t,t) i a (tt) i time 106 1 j j+1 J Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 106Recall: Accumulationbased CC Schemes 1 j j+1 J d j f i μ i Λ μ i,j+1 i Λ i j … … f J1 q (t d ) i1 i q (t d ) ij k k j d d f j J1 d i f I (t d ,t) q (t) i i iJ a (t) i t O (t,t) i a (tt) i time 107 1 j j+1 J Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 107Recall: Acclnbased Control Policy 1 j j+1 J d j f i μ i Λ μ i,j+1 i Λ i j a (t) 0  control objective : keep i i a (t) 0 if , no way to probe increase of available i bandwidth;  control algorithm : if a (t) then i i i if a (t) then i i i f rec :a (t,t)  (t d ,t) (t,t)t i i i i 108 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 108Recall: “Monaco” CC Scheme congestion estimation: outofband and inband control packets congestion response: if q α, cwnd(k+1) = cwnd(k) + 1; m if q β, cwnd(k+1) = cwnd(k) – 1; 1 = α β = 3 m 109 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 109ClosedLoop Service Differentiation: Lossbased or Accumulationbased 110 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 110ClosedLoop QoS: Bandwidth Assurances Flow 1 with 4 Mbps assured Flow 2 with 3 Mbps best effort + 3 Mbps best effort Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 111QoS: an applicationlevel approach sophisticated services in application • architecturally “above” network core • open services: let 1000 flowers bloom simple, fast, diffserv network Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 112QoS: an applicationlevel approach Applicationlevel infrastructure • accommodate networklevel service • additional tailoring of user services Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 113Content Delivery Motivation: congestion Networks Browsers Routers Web Servers Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 114Content Delivery: idea • Reduces load on server • Avoids network congestion Browsers Replicated content Content Sink Content Source Router Web Server Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 115CDN: Architectural Layout Request 4 Routing(RR) 1 Client 5 Distribution 2 Origin System 6 3 Surrogate  Publisher informs RR of Content Availability.  Content Pushed to Distribution System.  Client Requests Content, Requested redirected to RR.  RR finds the most suitable Surrogate  Surrogate services client request. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 116Summary  QoS big picture, building blocks  Integrated services: RSVP, 2 services, scheduling, admission control etc  Diffserv: edgerouters, core routers; DS byte marking and PHBs  Realtime transport/middleware: RTP, H.323  New problems: interdomain QoS, Applicationlevel QoS, Content delivery/web caching Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 117
sharer
Presentations
Free
Document Information
Category:
Presentations
User Name:
Dr.ShivJindal
User Type:
Teacher
Country:
India
Uploaded Date:
19-07-2017