1 / 45

QoS in the Internet Better than best-effort

QoS in the Internet Better than best-effort. Andreas Liaker Feroz Zahid. Agenda. Quality of Service – What is it and Why it is needed? IntSrv, ST-II and RSVP Differentiated Services MPLS Constraint Based Routing and Traffic Engineering Difference between ST-II and RSVP.

veata
Download Presentation

QoS in the Internet Better than best-effort

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. QoS in the Internet Better than best-effort Andreas Liaker Feroz Zahid

  2. Agenda • Quality of Service – What is it and Why it is needed? • IntSrv, ST-II and RSVP • Differentiated Services • MPLS • Constraint Based Routing and Traffic Engineering • Difference between ST-II and RSVP

  3. What is Quality of Service? • Guarantees for the predictable results • Unlike Best-effort service • What Guarantees? • Bandwidth • Latency • Robustness • Methods • Resource Reservation (IntServ) • Resource Prioritization (Differentiated Services)

  4. Integrated services (IntServ) and RSVP • Basic Idea • Network components (routers) reserve resources to provide Quality of Service to specific packet streams • Types • Guaranteed • Most strict • IP possible version of dedicated virtual circuit • Controlled-Load • Equivalent to best-effort service under unloaded conditions

  5. Some Terminologies

  6. IntServ Components

  7. RSVP Protocol • Runs on top of the routing protocol • Implementation should be available on sender, receiver, router • Carries resource requests all the way through the network • At each hop • consults admission control • sets up reservation and packet filter. • If fails, inform sender • Reservation Style • Wildcard • Fixed Filter • Dynamic Filter

  8. RSVP Protocol – In IP Stack ULPs IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

  9. RSVP Messages • Sender • PATH message • Traffic specification • Receiver • RECV message containing • Reservation specification • Guaranteed or Controlled • Filter specification • Type of packets

  10. RSVP Signaling Mechanism RESV PATH Quality-bound Communication

  11. ST-II • IP v5 (4 first bit Header) • Experimentalprotocol • Serves as an adjunct to, not a replacement for, IPv4 • ST-II • Multicast distribution tree • Unicast routing table • ST-agent Connect (each hop) • Allocate resources • May reduce resource request. • Receiver must Accept or Refuse • Accept can reduce resource requests

  12. ST-II • ST-II Hole stream is treated homogeneous. • Stream source must wait for all Accept/Refuse reply • Must adapt to lower QoS , or reject group participation (Disconnect message) • Receivers can be added or deleted using IP. • Must reduce QoS or reject if needed • Reliability and Robustness • Manage Stream with hop-by-hop acknowledgment • Hello Message to neighboring ST Agents • Only service model supported is homogeneous point to multipoint simplex distribution tree

  13. ST-II Protocol – In IP Stack ULPs ST-II service interface ST-II SCMP Link layer service interface Link layer modules

  14. IntServ - Conclusions • Pros • Highest level service guarantees • Granularity of resource allocation • Feedback for QoS enabled applications • Cons • Scalability? • Amount of state information increases proportionally with the number of flows • Huge storage and processing overhead on routers • Ubiquitous deployment is required (for Guaranteed Service)

  15. Differentiated Services • Basic Idea • All complex functionality shift to the edge routers • Applied on flow aggregates • Services requirements are classified • A predefined per-hop behavior (PHB) is applied to every service class • Traffic is smoothed according to PHB applied • Types • Assured service • Premium service • Ordinary Best-effort service

  16. Differentiated Services – Assured Service • Defined in terms of user profile • how much assured traffic is a user allowed to inject into the network • Network • provides a lower loss rate than best-effort • In case of congestion • best-effort packets are dropped first • User • sends no more assured traffic than its profile • If it sends more, the excess traffic is converted to best-effort

  17. End to End Service Delivery – Delivery of Assured Service with Static SLA Granted RSVP 8. ER2 performs the same operations as BR1. 1. Host S sends a RSVP message to the local Bandwidth Broker (CN1-BB) requesting for Assured Service for its traffic. 2. CN1-BB configure leaf router LR1 so that LR1 can set the A-bits of the packets of this flow. CN1-BB will also reply to the host S. 3. Host S sends packets to leaf router LR1. 4. LR1 mark A-bits of the packet. 5. Every router from LR1 (excl) to ER1 (incl) does a BA classification. Packets with the A-bit set are considered as in . 9. The packets are eventually delivered to host D. 6. BR1 polices the traffic. If the in traffic exceeds its bit-rate, the excess packets’ A-bits will be reset. 7. All routers between boundary router BR1 and BR2 (incl) perform BA classifications and apply RIO on their AQs.

  18. Differentiated Service – Premium Service • Provides the abstraction of a virtual pipe between an ingress and an egress router • Network • Guarantees that premium packets are not dropped and they experience low delay • User • does not send more than the size of the pipe • If it sends more, excess traffic is delayed, and dropped when buffer overflows

  19. Delivery of Premium Service with Dynamic SLAPhase I - Signaling Granted Granted Granted PATH RESV 7b. CN1-BB will then set RESV message to host S. 8. Host S may now start transmitting data packets. 6b. ISP1-BB then sends RESV message to CN1-BB. 5c. CN2-BB then sends RSVP RESV message to ISP1-BB. 5a. CN2-BB makes an admission control decision. 4a. ISP1-BB makes an admission control decision. 3. If request is accepted, CN1-BB sends PATH message to ISP1-BB. 2. CN1-BB makes an admission control decision. 6a. ISP1-BB configures classification and policing rules on router BR1, and the policing and reshaping rules on router ER2. 1. Host S sends RSVP PATH message to the local bandwidth broker CN1-BB. 7a. CN1-BB will set classification and shaping rules on router LR1 and router ER1. 4b. If request is accepted, ISP1-BB sends PATH message to CN2-BB. 5b. If request is accepted, CN2-BB set the classification and policing rules on router ER2 using LDAP or RSVP.

  20. Delivery of Premium Service with Dynamic SLAPhase II - Data Transmission ` 7. ER2 classifies and polices the premium traffic. Excess premium packets are dropped. 8. The premium packets are delivered to host D. 1. Host S sends packets to the leaf router LR1. 4. ER1 performs a BA classification and reshapes the traffic to make sure that the negotiated peak rate is not exceeded. 5. BR1 classifies and polices the premium traffic. Excess premium packets are dropped. 2. Leaf router LR1 performs a MF classification. If the traffic is non-conformant, LR1 will shape it. It will also set the P-bits of the packets. 3. Each intermediate router between leaf router LR1 and ER1 performs a BA classification, puts the packet in PQ and sends them out. 6. Intermediate router between BR1 and BR2 (incl) performs BA classification. BR2 also reshapes the premium traffic.

  21. Differentiated Services - Conclusions • Pros • Scalable • Edge routers maintain per aggregate state • Core routers maintain state only for a few traffic classes • Easier implementation • Incremental deployment • Cons • Provide weaker service than IntServ

  22. Quality of Service Pyramid Not Strict Less Strict Very Strict

  23. Multi Label Protocol Switching (MPLS) • Basic Idea • Header of the packet contains a label that is used to advance the packet toward its destination • The label simplifies the forwarding decision a node must make for the packet • A group of packets forwarded in the same manner are said to belong to the same Forwarding Equivalence Class (FEC)

  24. Multi Label Protocol Switching (MPLS) • Label Switched Paths (LSPs) • Within an MPLS domain, a path is set up for a given packet to travel based on a Forwarding Equivalence Class (FEC) • The LSP is set up prior to data transmission

  25. Multi Label Protocol Switching (MPLS) • MPLS improves packet forwarding performance • Enhances and simplifies packet forwarding through routers • Layer-2 switching • Simplicity allows for easy implementation • MPLS supports QoS for service differentiation • Use traffic-engineered path set-up and support QoS guarantees • Classification and QoS service are determined by the labels

  26. Multi Label Protocol Switching (MPLS) Picture Source: http://itknowledgeexchange.techtarget.com/network-engineering-journey/how-mpls-works/

  27. Constraint Based Routing and Traffic Engineering • Traffic Engineering • Process of arranging traffic flows so congestion caused by uneven network utilization could be avoided • Constraint-Based Routing • Compute routes that are subject to rules • Multiple constraints possible

  28. Traffic Engineering • Network congestion • Lack of network resources • Uneven distribution of traffic • Lack of network Resources • All routers and links are overloaded • Only solution is to add more resources • Uneven traffic distribution • Dynamic Routing protocols such as RIP and OSPF always select the shortest paths to forward packets • Traffic Engineering can be utilized to: • Avoid congestion • Provide graceful degradation in case of congestion Picture Source: http://www.geoexpertsolutions.com/

  29. Constraint Based Routing • With DiffServ • Select those routes that most likely are to satisfy QoS requirements • Constraint-Based Routing with RSVP • Select the path for RSVP messages • Constraint-Based Routing with MPLS • MPLS as a forwarding scheme • Constraint-based routing as a routing scheme

  30. Differences between ST-II and RSVP • Static Analysis • Self-limiting applications • Support heterogeneous groups • Support channel selection • Dynamic Analysis • Network dynamics • Group membership dynamics

  31. Self-Limiting Applications • Multipoint-to-multipointapplications • Application-levelconstraints • Fewsimultaneous senders • Audioconference • Simulate • 60 routers • 82 Links • 2-65 participants

  32. Self-LimitingApplications

  33. Self-Limiting Applications • RSVP usesWildcardReservation style • Resources arereservedonly for new links • ST-II Independent distribution tree from new participant to all existing members • ST-II Maximum Group Size

  34. Supportingheterogeneousgroups • Global ScaleInterNetwork different demand for QoS • Wide-spreaddistributionservices • Cable-TV distribution • Broadcasting of an audio/video lecture • Multiple data streams/signal quality level to receiver. • ST-II • Entire stream as a homogeneous • Maximum requested resource along all links. • RSVP • Support for heterogeneousreservations

  35. Supportingheterogeneousgroups • Heterogeneous mix of receivers listening to an audio lecture. • Sending the entire data stream on a single multicast tree most efficient. • High quality – 64Kb/s • Low quality – 16Kb/s

  36. Link reservations for RSVP heterogeneous audio lecture (40 receivers).

  37. Supportingchannelselection • Large multipartyconferences • Unableto receivefrom all active participants simultaneously • Select dynamically a subset of the sources • Assuredchannelselection • Independent reservation for each source (ST-II & RSVP) • Dynamic Filter Reservation (RSVP) • Non-assured Channel Selection (ST-II & RSVP)

  38. Channel selectionresourceoverhead

  39. Network Dynamics • Reliability and robustness in the face of network dynamics. • ST-II Reliable controlmessageprotocol and a Helloprotocol • RSVP Datagram control message protocol in combination with a soft state refresh mechanism • Difficulty to compare because they rely heavily on timers. • Comparethe design philosophies • Recovery • ST-II Requires that the network be responsible for correctness • RSVP leaves the final responsibility for maintaining reservations with the ends. “Fate-sharing”

  40. Network Dynamics • Overhead • ST-II: ST agent periodically exchanging one Hello message with each active neighbor. • RSVP: Path and Reservation refreshes • RSVP incorporates a protocol overhead reduction mechanism (merging)

  41. Group membership dynamics • Global distribution of a conference • Participants tuning into and leaving the conference. • ST-II Overhead • Connect and Accept messagebetweensource and receiver • Overhead proportional to thenumberofdownstreamreceivers • HotSpots • Bottleneck • RSVP Overhead • Assuminghomogeneouesrecievers. One protocolmessageoneach link in eachdirection • Heterogeneous. Splices and sufficientresourceallocatedfor more demandingrequests

  42. Protocol overhead for independent group joins for audio lecture

  43. Group membershipdynamics • Latency • ST-II Setup/teardown – One roundtripsourceand receiver. • RSVP Setup. • One initialdelay for Pathrefresh • One hop to end to end dependingpossibilityfor «spliced» • RSVP teardown • Canreleasetheresourceimmediately

  44. Somethoughts… • Internet QoS: A Bigger Picture • 2007 - TM Bohnert et al. • New Generation Networks, Wireless Networks • Net Neutrality • Internet service providers and governments should treat all data on the Internet equally • Talk: ConceptofQoS in theInternet • Geoff Hustonfrom APNiC, September 2012 • Why QoS? • Operators believe that this will allow them to extort revenues from Content service providers • Solution? • Add more bandwidth • Adaptive behavior in applications Picture Source: http://1.bp.blogspot.com/

  45. Summary • Integrated Services • Not Scalable • Difficult to implement even in corporate networks • Differentiated Services • No per flow resource reservations • No assured outcome • Can’t guarantee fixed service response • Can’t measure performance • Internet QoS still not experimented much!

More Related