IP QoS issues

1. IP QoS issues From IntServ to DiffServ to Adaptive QoS Mangement

2. Agenda • QoS and IP networks • IntServ • DiffServ • Adaptive QoS Management

3. QoS enabling a Network • Goals • Improve network service perceived by applications • Give the network administrator control over network resource usage • These are really the same • If there were infinite network resources, QoS would not be necessary • but - there are congestion points • QoS is about deciding what traffic gets access to resources at these points

4. How can this be achieved? • Correlate packets with traffic sources • sending user, receiving user, application • classify according to common fields in packet headers • Give certain traffic preferential access to resources at congestion points • reserve adequate capacity on transmit interfaces • bypass queues on transmit interfaces • extra buffer space in network elements

5. Specifying traffic: Tspec IDEA: call must describe traffic that it will inject into net leaky bucket proposal: traffic entering net filtered by leaky bucket regulator: • B: maximum burst size • r: average rate • amount traffic entering over any interval of length t, less than b + rt

6. Token Bucket Possible token bucket uses: • shaping, policing, marking • delay pkts from entering net (shaping) • drop pkts that arrive without tokens (policing function) • let all pkts pass through, mark pkts: those with tokens, those without • network drops pkts without tokens in time of congestion (marking)

7. Traffic classes • Networks should match offered service to source requirements (corresponds to utility functions) • Example: telnet requires low bandwidth and low delay • utility increases with decrease in delay • network should provide a low-delay service • or, telnet belongs to the low-delay traffic class • Traffic classes encompass both user requirements and network service offerings

8. Traffic classes - details • A basic division: guaranteed service and best effort • like flying with reservation or standby • Guaranteed-service • utility is zero unless app gets a minimum level of service quality • bandwidth, delay, loss • open-loop flow control with admission control • e.g. telephony, remote sensing, interactive multiplayer games • Best-effort • send and pray • closed-loop flow control • e.g. email, net news

9. GS vs. BE (cont.) • Degree of synchrony • time scale at which peer endpoints interact • GS are typically synchronous or interactive • interact on the timescale of a round trip time • e.g. telephone conversation or telnet • BE are typically asynchronous or non-interactive • interact on longer time scales • e.g. Email • Sensitivity to time and delay • GS apps are real-time • performance depends on wall clock • BE apps are typically indifferent to real time • automatically scale back during overload

10. Traffic subclasses (roadmap) • ATM Forum • based on sensitivity to bandwidth • GS • CBR, VBR • BE • ABR, UBR • IETF • based on sensitivity to delay • GS • intolerant • tolerant • BE • interactive burst • interactive bulk • asynchronous bulk

11. ATM Forum GS subclasses • Constant Bit Rate (CBR) • constant, cell-smooth traffic • mean and peak rate are the same • e.g. telephone call evenly sampled and uncompressed • constant bandwidth, variable quality • Variable Bit Rate (VBR) • long term average with occasional bursts • try to minimize delay • can tolerate loss and higher delays than CBR • e.g. compressed video or audio with constant quality, variable bandwidth

12. ATM Forum BE subclasses • Available Bit Rate (ABR) • users get whatever is available • zero loss if network signals (in RM cells) are obeyed • no guarantee on delay or bandwidth • Unspecified Bit Rate (UBR) • like ABR, but no feedback • no guarantee on loss • presumably cheaper

13. IETF GS subclasses • Tolerant GS • nominal mean delay, but can tolerate “occasional” variation • not specified what this means exactly • uses controlled-load service • controlled load: "a QoS closely approximating the QoS that same flow would receive from an unloaded network element, but uses admission control to assure that this service is received even when the network element is overloaded." even at “high loads”, admission control assures a source that its service “does not suffer” • it really is this imprecise! • Intolerant GS • need a worst case delay bound • equivalent to CBR+VBR in ATM Forum model

14. IETF BE subclasses • Interactive burst • bounded asynchronous service, where bound is qualitative, but pretty tight • e.g. paging, messaging, email • Interactive bulk • bulk, but a human is waiting for the result • e.g. FTP • Asynchronous bulk • junk traffic • e.g netnews

15. Some points to ponder • The only thing out there is CBR and asynchronous bulk! • These are application requirements. There are also organizational requirements (link sharing) • Users needs QoS for other things too! • billing • privacy • reliability and availability

16. Time scales • Some actions are taken once per call • tell network about traffic characterization and request resources • in ATM networks, finding a path from source to destination • Other actions are taken during the call, every few round trip times • feedback flow control • Still others are taken very rapidly,during the data transfer • scheduling • policing and regulation • Traffic management mechanisms must deal with a range of traffic classes at a range of time scales

17. Summary of mechanisms at each time scale • Less than one round-trip-time (cell-level) • Scheduling and buffer management • Regulation and policing • Policy routing (datagram networks) • One or more round-trip-times (burst-level) • Feedback flow control • Retransmission • Renegotiation

18. Summary (cont.) • Session (call-level) • Signaling • Admission control • Service pricing • Routing (connection-oriented networks) • Day • Peak load pricing • Weeks or months • Capacity planning

19. Renegotiation • An option for guaranteed-service traffic • Static descriptors don’t make sense for many real traffic sources • interactive video • Multiple-time-scale traffic • burst size B that lasts for time T • for zero loss, descriptors (P,0), (A, B) • P = peak rate, A = average • T large => serving even slightly below P leads to large buffering requirements • one-shot descriptor is inadequate

20. Renegotiation (cont.) • Renegotiation matches service rate to traffic • Renegotiating service rate about once every ten seconds is sufficient to reduce bandwidth requirement nearly to average rate • works well in conjunction with optimal smoothing • Fast buffer reservation is similar • each burst of data preceded by a reservation • Renegotiation is not free • signaling overhead • call admission ? • perhaps measurement-based admission control

21. Signaling • How a source tells the network its utility function • Two parts • how to carry the message (transport) • how to interpret it (semantics) • Useful to separate these mechanisms • call setup protocol needed • to perform call admission • to reserve resources at each router on end-end path

22. Signaling semantics • Classic scheme: sender initiated • SETUP, SETUP_ACK, SETUP_RESPONSE • Admission control • Tentative resource reservation and confirmation • Simplex and duplex setup • Doesn’t work for multicast

23. Resource translation • Application asks for end-to-end quality • How to translate to per-hop requirements? • E.g. end-to-delay bound of 100 ms • What should be bound at each hop? • Two-pass • forward: maximize (denial!) • reverse: relax • open problem!

24. maximale Netzkapazität Rest Bandbreite Verb 2 Verb 1 Zeit Resource Control • Tasks • Admission Control Tests at connection setup • enough capacity for new connection • all existing connections should keep their QoS • Reservation of resources at connection setup • Scheduling of resources during runtime • similar to processor scheduling • Release of resources

25. incoming links Link level packet scheduling Outgoing link router Link Layer: critical QoS component Buffering and bandwidth: the scare resources • cause of loss and delay • Scheduler as example for resource controller • packet scheduling discipline, buffer management will determine loss, delay seen by a call • Scheduling disciplines: • FCFS • Fair Queuing (FQ) • Weighted Fair Queueing (WFQ)

26. Scheduling: FCFS • FCFS (First Come First Served) oder FIFO • packets are processed according to their arrival time • buffer overflow-> packets are lost • congestion control at the endpoints of the network necessary • in todays internet IP routers. TCP deals with congestion control • Advantage: simple to implement • Disadvantage: No QoS guarantees, because it does not distinguish between packet priorities • FCFS and Priorities • several queues with different priorities • within each queue: FCFS • highest priority queue served first • no guarantees within each priority class

27. Per Flow packet Queues Flow 1 pkts Outgoing link Flow N pkts Scheduling: Fair Queueing • Idea: Fairness. Each flow gets same amount of bandwidth • Advantages: • misbehaving source does not influence other flows • Problems: • many queues • Insufficient algorithm: service rate depends on packet size • Guarantees minimal throughput • Round-robin service: • assume fixed length pkts, N sessions • session i gets to send 1 pkt each "turn" • if session i has no pkt, i+1 gets chance

28. Scheduling: WFQ • Variant of Fair Queueing: • share per bandwidth varies between flows; negotiated at set-up • Possible implementation: (virtual clock) • TimeStamp: each packet is associated with a timestamp that determines planed sending time • first packet: connection setup time • other packets: increment timestamp by time difference that matches the average negotiated bandwidth of the flow (act_Packetsize/bandwidth) • what packets are sent first? • Inspect timestamps. Sent packets with minimum time first • Advantage: individual bandwidth share per flow • Disadvantage: Overhead due to scheduling • WFQ guarantees minimal throughput and miximal delay

29. Prio Delay TP Rel CU CU IP v 4 Header • QoS in IP-Datagrams • Described by TOS-Byte • Priority • Delay • Throughput • Reliability • RFC 791: do not use TOS • IPv4 can not provide QoS 4-bit version 4-bit hdr length 8-bit type of serv. (TOS) 16-bit total length (in bytes) 16-bit identification 3-bit flags 13-bit fragment offset 8-bit time to live (TTL) 8-bit protocol 16-bit header checksum 32-bit source IP address 32-bit destination IP address Options (if any) data

30. IPv6 DS field (DiffServ) Changes to Ipv4: • 128 bit addresses (so we don't run out of IP addresses) • header simplification (faster processing) • more support for type of service • priorities • flow identifier: identifiy packets in a connection • security Notes: • no fragmentation in network • packet too big generates ICMP error to source • source fragmentation via extension header • no checksum (already done at transport and data link layer)

31. Agenda • QoS and IP networks • IntServ • DiffServ • Adaptive QoS Management

32. Integrated Services Model 3 Working Groups RSVP IntServ Layer 3 ISSLL Layer 2

33. IntServ Architecture • RSVP (Resource Reservation Protocol) • Generic Mechanisms • Dynamic, per flow • p-2-p and multicast • IntServ (Integrated Services) • Layer 3 in each entity • classes of service for each flow • Guaranteed • Controlled Load • Best Effort

34. IntServ Architecture • ISSLL (Integrated Services over a Specific Link Layer) • ISSLOW (Slow Links) • Header Compression • Priority Packets • IS802 • uses 802.1p tagging • ISATM • ATM QoS • If no Definition for link layer • Layer 3 packet scheduling

35. IntServ Architecture • What IntServ does NOT: • provide packet forwarding or format specification • still IPv4, IPv6 • routing • no QoS routing • Admission control in the network • if not enough resources, use best effort class

36. Internet signaling transport: RSVP • Main motivation is to efficiently support multipoint multicast with resource reservations • large numbers of heterogeneous receivers • heterogeneity in available bandwidth to receiver • heterogeneity in receiver QoS demands (differing delay requirements) • Progression • Unicast • Naive multicast • Intelligent multicast • Naive multipoint multicast • RSVP

37. RSVP in short • Host-network-host Signaling Protocol • who am I? (user ID, application ID) • how can you recognize my packets? • what do I want? (service type, quantity) • what part of the network will I impact? • Useful for any persistent traffic flows • quantitative (Intserv) • qualitative • Admission control and topology awareness enable stricter guarantees • Unifies other QoS mechanisms

38. RSVP • When no reservation is needed, no change to internet • Receiver initiated • scalability • heterogeneity, each receiver chooses IntServ class • Reservation state per group, instead of per connection • PATH and RESV messages • PATH sets up next hop towards source(s) • no reservations at this point • RESV makes reservation • Travel as far back up as necessary • how does receiver know of success? • DSBM: Designated Subnet Bandwidth Manager for 802 type networks

39. Filters and Soft State • Filters • Allow receivers to separate reservations • Fixed filter • receive from exactly one source • Dynamic filter • dynamically choose which source is allowed to use reservation • Soft State • State in switch controllers (routers) is periodically refreshed • On a link failure, automatically find another route • will go away if not "refreshed" by receivers

40. Call Setup in RSVP Sender sends Tspec out on multicast tree in PATH message Receiver sends RESV message back up tree: • contains senders Tspec and receiver QoS requirement (Rspec) • routers along reverse path reserve resources needed to satisfy receiver's QoS Sender Path R1 R5 R2 R3 R4 RESV Receiver 1

41. RSVP: Multicast Multiple receivers: • may have different QoS requirements • resource reservations merged as RESV travels upstream • resources must be allocated to satisfy strictest demands of downstream receivers • e.g.: receiver 1 first reserves resources for 100 ms max delay • if receiver 2 QoS is 200 ms max delay, no new resources at R2, R1 • if receiver 2 QoS is 50 ms, more resources needed at R2, R1

42. Multiple Receivers Sender R1 R5 RESV (merged) R2 R3 RESV R4 Receiver 2 RESV Receiver 1

43. Multiple Senders Can handle multiple senders as well: • different "styles" of resource reservation • e.g., reserve enough resources in case all senders simultaneous • resource enough resources for two simultaneous senders • can dynamically determine which of N streams is forwarded downstream (switching within the network)

44. Example Data Handling & RSVP Signaling End-to-end RSVP signaling Sender Receiver ATM Network Switched Network (in-house) Large Routed Network (Core) Small RoutedNetwork (ISP)

45. RSVP Drawbacks • QoS guarantees • every router has to use RSVP and Resource Reservation • Scalability • Context per flow in each router, even if no reservation is requested • the RESV message must follow the same path than the PATH message • Internet Routing is asymetrical • per packet classification in router

46. Renegotiation problems • Static descriptors don’t make sense for interactive sources or multiple-time scale traffic • Renegotiation matches service rate to traffic • Renegotiation is not free- incurs a signaling overhead • Open questions • when to renegotiate? • how much to ask for? • admission control? • what to do on renegotiation failure?

47. Agenda • QoS and IP networks • IntServ • DiffServ • Adaptive QoS Management

48. Differentiated Services Model Receiver • Sender • establishes TOS • can control bitrate to assure QOS Edge Router (Egress) • Edge Router (Ingress) • verify conformance (shape/tag/drop) • assigns label to packet DiffServ Cloud • Better than Best Effort • In-Band Signalling (Packet Header) • Complexity shifted towards Edge Router • Simple Charging (Service Level Agreement)

49. DiffServ in short • Aggregate traffic handling mechanism • Defines a small number of per-hop behaviours (PHBs) supported in routers • invoked by per-packet marking • Concatenation of ‘hops’, with admission control, can provide useful services across the DiffServ cloud • Very scaleable • no inherent signaling • little state required

50. Class-based QoS • Internet model requires per session state at each router • 1000s - 1000000s of flows • reluctance on part of network admins to accept • Differentiated service model: 3+ classes • Premium service: • high scheduling priority - aggregate peak rate allocation - low delay • Assured service: • high buffer priority => lower loss • Best effort service: • the usual