Protocols with QoS Support

Transcription

1 INF5071 Performance in Distributed Systems Protocols with QoS Support 13/

2 Overview Quality-of-Service Per-packet QoS IP Per-flow QoS Resource reservation QoS Aggregates DiffServ, MPLS The basic idea of Network Calculus

3 Quality-of-Service

4 Quality of Service (QoS) Different semantics or classes of QoS: determines reliability of offered service utilization of resources reserved C resources available resources unused max reserved B reserved A time

5 Quality of Service (QoS) Best effort QoS: system tries its best to give a good performance no QoS calculation (could be called no effort QoS) simple do nothing QoS may be violated unreliable service Deterministic guaranteed QoS: hard bounds QoS calculation based on upper bounds (worst case) premium better name!!?? QoS is satisfied even in the worst case high reliability over-reservation of resources poor utilization and unnecessary service rejects QoS values may be less than calculated hard upper bound

6 Quality of Service (QoS) Statistical guaranteed QoS: QoS values are statistical expressions (served with some probability) QoS calculation based on average (or some other statistic or stochastic value) resource capabilities can be statistically multiplexed more granted requests QoS may be temporarily violated service not always 100 % reliable Predictive QoS: weak bounds QoS calculation based previous behavior of imposed workload

7 Quality of Service Applicability: QoS support A dream of early network researchers (lots of research topics) Guarantees that distributed systems work as promised QoS doesn t exist? IP doesn t support QoS Equality is the Internet s mantra (do you listen to the net neutrality debate?) Violates Internet philosophy (shunned by the gurus) QoS requirement Companies and end-users demand guarantees What s being done?

8 Per-packet QoS

9 Internet Protocol version 4 (IPv4) Version IHL Pre ToS 0 Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address PRE D TOptions R C 0 Padding [RFC1349] ToS ToS Type of Service D minimize delay T maximize throughput R maximize reliability C minimize cost PRE Precedence Field Priority of the packet

10 Internet Protocol version 4 (IPv4) Version IHL DSCP 0 0 Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding [RFC2474] Class selector codepoints of the form xxx000 DSCP Differentiated Services Codepoint xxxxx0 reserved for standardization xxxx11 reserved for local use xxxx01 open for local use, may be standardized later

11 Internet Protocol version 6 (IPv6) Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address Traffic class Interpret like IPv4 s DS field

12 Per-flow QoS Resource Reservation

13 Resource Reservation Reservation is fundamental for reliable enforcement of QoS guarantees per-resource data structure (information about all usage) QoS calculations and resource scheduling may be done based on the resource usage pattern reservation protocols negotiate desired QoS transfer information about resource requirements and usage between the end-systems and all intermediate systems reservation operation calculate necessary amount of resources based on the QoS specifications reserve resources according to the calculation (or reject request) resource scheduling enforce resource usage with respect to resource administration decisions

14 Resource Management Phases time Phase 1: user s QoS requirements rejection or renegotiation specification admission test and calculation of QoS guarantees negotiation resource reservation QoS guarantees to user confirmation renegotiation Phase 2: data transmission QoS enforcement by proper scheduling enforcement not necessarily an own phase, some protocols start sending at once monitoring and adaptation notification renegotiation Phase 3: stream termination resource deallocation termination

15 Reservation Directions Sender oriented: sender (initiates reservation) must know target addresses (participants) in-scalable good security sender 1. reserve data flow 2. reserve 3. reserve receiver

16 Reservation Directions Receiver oriented: sender receiver (initiates reservation) needs advertisement before reservation must know flow addresses sender need not to know receivers more scalable in-secure 3. reserve 2. reserve 1. reserve data flow receiver

17 Reservation Directions Combination? start sender oriented reservation additional receivers join at routers (receiver based) sender 1. reserve data flow 2. reserve reserve from nearest router 3. reserve receiver

18 Per-flow QoS Integrated Services

19 Integrated Services (IntServ) Framework by IETF to provide individualized QoS guarantees to individual application sessions Goals: efficient Internet support for applications which require service guarantees fulfill demands of multipoint, real-time applications (like video conferences) do not introduce new data transfer protocols In the Internet, it is based on IP (v4 or v6) and RSVP RSVP Resource reservation Protocol Two key features reserved resources the routers need to know what resources are available (both free and reserved) call setup (admission call) reserve resources on the whole path from source to destination

20 Integrated Services (IntServ) Admission call: receiver traffic characterization and specification one must specify the traffic one will transmit on the network (Tspec) one must specify the requested QoS (Rspec reservation specification) signaling for setup send the Tspec and Rspec to all routers sender per-element admission test each router checks whether the requests specified in the R/Tspecs can be fulfilled if YES, accept; reject otherwise 1. request: specify traffic (Tspec), guarantee (Rspec) 2. consider request against available resources accept or reject 2

21 Integrated Services (IntServ) IntServ introduces two new services enhancing the Internet s traditional best effort: guaranteed service guaranteed bounds on delay and bandwidth for applications with real-time requirements controlled-load service a QoS closely to the QoS the same flow would receive from an unloaded network element [RFC 2212], i.e., similar to best-effort in networks with limited load no quantified guarantees, but packets should arrive with a very high percentage for applications that can adapt to moderate losses, e.g., real-time multimedia applications

22 Integrated Services (IntServ) Both service classes use token bucket to police a packet flow: packets need a token to be forwarded each router has a b-sized bucket with tokens: if bucket is empty, one must wait new tokens are generated at a rate r and added: if bucket is full (little traffic), the token is deleted the token generation rate r serves to limit the long term average rate token generation the bucket size b serves to limit the maximum burst size bucket token wait queue

23 Integrated Services (IntServ) Today implemented in every router for every operating system (its signaling protocol RSVP is even switched on by default in Windows!) and not used Arguments too much overhead too large memory requirements too inflexible net neutrality argument no commercial model

24 QoS Aggregates Protocols

25 Differentiated Services (DiffServ) IntServ and RSVP provide a framework for per-flow QoS, but they give complex routers much information to handle have scalability problems set up and maintain per-flow state information periodically PATH and RESV messages overhead specify only a predefined set of services new applications may require other flexible services DiffServ [RFC 2475] tries to be both scalable and flexible

26 Differentiated Services (DiffServ) ISPs favor DiffServ Basic idea multicast is not necessary make the core network simple - support to many users implement more complex control operations at the edge aggregation of flows reservations for a group of flows, not per flow thus, avoid scalability problems on routers with many flows do not specify services or service classes instead, provide the functional components on which services can be built thus, support flexible services

27 Differentiated Services (DiffServ) Two set of functional elements: edge functions: packet classification and traffic conditioning core function: packet forwarding At the edge routers, the packets are tagged with a DS-mark (differentiated service mark) uses the type of service field (IPv4) or the traffic class field (IPv6) different service classes (DS-marks) receive different service subsequent routers treat the packet according to the DS-mark classification: incoming packet is classified (and steered to the appropriate marker function) using the header fields the DS-mark is set by marker once marked, forward classifier marker forward

28 Differentiated Services (DiffServ) Note, however, that there are no rules for classification it is up to the network provider A metric function may be used to limit the packet rate: the traffic profile may define rate and maximum bursts if packets arrive too fast, the metric function assigns another marker function telling the router to delay or drop the packet classifier marker shaper / dropper forward

29 Differentiated Services (DiffServ) In core routers, DS-marked packets are forwarded according to their per-hop behavior (PHB) associated with the DS-tag the PHB determines how the router resources are used and shared among the competing service classes the PHB should be based on the DS-tag only no other state in the router traffic aggregation packets with same DS-tag are treated equally regardless of original source or final destination a PHB can result in different service classes receiving different performance performance differences must be observable and measurable to be able to monitor the system performance no specific mechanism for achieving these behaviors are specified

30 Differentiated Services (DiffServ) Edge router: use header fields to lookup right DS-tag and mark packet core routers Core router: use PHB according to DS-tag to forward packet fast and scalable due to simple core routers

31 Differentiated Services (DiffServ) Currently, two PHBs are under active discussion expedited forwarding [RFC 3246] specifies a minimum departure rate of a class, i.e., a guaranteed bandwidth the guarantee is independent of other classes, i.e., enough resources must be available regardless of competing traffic assured forwarding [RFC 2597] divide traffic into four classes each class is guaranteed a minimum amount of resources each class are further partitioned into one of three drop categories (if congestion occur, the router drops packets based on drop value)

32 Multiprotocol Label Switching (MPLS) Multiprotocol Label Switching Separate path determination from hop-by-hop forwarding Forwarding is based on labels Path is determined by choosing labels Distribution of labels On application-demand LDP label distribution protocol By traffic engineering decision RSVP-TE traffic engineering extensions to RSVP

33 Multiprotocol Label Switching (MPLS) MPLS works above multiple link layer protocols Carrying the label Over ATM Virtual path identifier or Virtual channel identifier Maybe shim Frame Relay data link connection identifier (DLCI) Maybe shim Ethernet, TokenRing, Shim Shim?

34 Multiprotocol Label Switching (MPLS) Shim: the label itself Link Layer Header ShimNetwork Layer Header Shim 20 bits label 3 bits experimental 1 bit 8 bits TTL bottom of stack

35 Routing using MPLS Label 12 IF 1 Label 27 IF Reserved path for this label Remove label Added label

36 MPLS Label Stack The ISP 1 Classifies the packet Assigns it to a reservation Performs traffic shaping Adds a label to the packet for routers in his net ISP 2 ISP 3 ISP 2 ISP 1 ISP 1 The ISP 1 Buys resources from ISP 2 The ISP 2 Repeats classifying, assignment, shaping Adds a label for the routers in his net He pushes a label on the label stack

37 MPLS Label Stack ISP 2 ISP 3 ISP 2 ISP 1 ISP 1

38 QoS Aggregates Network Calculus

39 Using Network Calculus Guaranteed Service An assured level of bandwidth A firm end-to-end delay bound No queuing loss for data flows that conform to a TSpec TSpec traffic specification Describes how traffic arrives from the user in the worst case p Double token bucket (or combined token bucket/leaky bucket) Token bucket rate r Token bucket depth b Peak rate p Maximum packet size M M token bucket b b r leaky bucket

40 Using Network Calculus Use TSpec to DESCRIBE the traffic that arrives in a system All traffic that would slip through this token bucket/leaky bucket combination without packet loss is traffic that adheres to the arrival curve described by (M,p,b,r).

41 Using Network Calculus bandwidth b+rt arrival curve: a ( t) p = M b + pt + rt t t < b M p r b M p r M+pt b time M b r token bucket leaky bucket

42 Using Network Calculus bandwidth p time M b b r token bucket leaky bucket

43 Using Network Calculus Service curve The network s promise Based on a fluid model Service curve: Service rate: Deviations: c( t) = R( t V ) R r V D + (validity condition) (router s delay) R p p R > r r d max M dmax = + D R ( b M )( p R) = + R( p r) M R + D Delays in the network But: delay d max is usually part of the user-network negotiation Required service rate dependent on M R p r R = requested d max dmax D b M p + M p r p R > r R = b M dmax + D p r

44 Using Network Calculus bandwidth arrival curve service curve Rt, p R > r d max time

45 Using Network Calculus Using network calculus to scale Aggregation Less state in routers One state for the aggregate Share buffers in routers Buffer size in routers depends on the TSpec s rates Use scheduling to exploit differences in d max Schedule flows with low delay requirements first

46 Using Network Calculus Aggregation bandwidth Summed TSpec TSpec(r 1 +r 2,b 1 +b 2,p 1 +p 2,max(M 1,M 2 )) Cascaded TSpec Wastage TSpec(r 1,b 1,p 1,M 1 ) TSpec(r 2,b 2,p 2,M 2 ) time

47 Using Network Calculus Aggregation Cascaded TSpec: n+1 token buckets p 1 +p 2 r 1 +p 2 max(m 1,M 2 ) b + b 1 1 p2 p1 b + b + b r1 p2 r 1 +r 2 token bucket token bucket leaky bucket

48 Summary

49 Directions of Network QoS [Liebeherr] Old-style QoS is dead ATM, IntServ, DiffServ, Service overlays didn t take hold Causes? No business case Bothed standardization Naïve implementations No need [Crowcroft,Hand,Mortier,Roscoe,Warfield] Old-style QoS is dead X.25 too little, too early ATM too much, too late IntServ too much, too early DiffServ too little, too late IP QoS not there MPLS too isolated QoS through overlays can t work Future QoS Look for fundamental insights Develop design principles Develop analytical tools Network calculus Future QoS Single bit differentiation Edge-based admission control Micropayment

50 Directions of Network QoS [Liebeherr] AT&T Old-style QoS is dead ATM, IntServ, DiffServ, MPLS Service overlays didn t take hold Causes? ATM No business case MPLS Bothed standardization Naïve implementations SDH No need WDM ATM Future QoS Companies do provide QoS MPLS Equant Cable and Wireless TeliaSonera Nortel Look for fundamental insights Develop design principles MPLS Develop analytical SONET/SDH tools Network calculus WDM [Crowcroft,Hand,Mortier,Roscoe,Warfield] Old-style QoS is dead X.25 too little, too early ATM too much, too late IntServ too much, too early DiffServ too little, too late IP QoS not there MPLS too isolated QoS through overlays can t work Future QoS Single bit differentiation Edge-based admission control Micropayment

51 Summary Timely access to resources is important for multimedia application to guarantee QoS reservation might be necessary Many protocols have tried to introduce QoS into the Internet, but no protocol has yet won the battle... often NOT only technological problems, e.g., scalability flexibility... but also economical and legacy reasons, e.g., IP rules everything must use IP to be useful several administrative domains (how to make ISPs agree) router manufacturers will not take the high costs (in amount of resources) for per-flow reservations pricing...

52 Summary What does it means for performance in distributed applications? QoS protocols either not present or used for traffic multiplexes Applications must adapt to bandwidth competition either to generic competing traffic or to traffic within a multiplex End-to-end QoS can be statistically guaranteed Overprovisioning in access networks Network calculus in long-distance networks

53 Some References 1. ATM Forum, 2. ATM Forum: ATM Service Categories, 3. Danthine, A., Bonaventure, O.: From Best Effort to Enhanced QoS, in: Spaniol, O., Danthine, A., Effelsberg, W. (Eds.): Architecture and Protocols for High-Speed Networks, Kluwer Achademic Publishers, 1994, pp Kurose, J. F., Ross, K. W.: Computer Networking: A Top-Down Approach Featuring the Internet, 2nd edition, Addison Wesley, Steinmetz, R., Nahrstedt, C.: Multimedia: Computing, Communications & Applications, Prentice Hall, Tenet group: The RFC repository maintained by the IETF Secretariat can be found at The following RFCs might be interesting with respect to this lecture: RFC 791: Internet Protocol RFC 1883: Internet Protocol, Version 6 (IPv6) RFC 2460: Internet Protocol, Version 6 (IPv6), Obsoletes: 1883 RFC 2212: Specification of Guaranteed Quality of Service RFC 2205: Resource ReSerVation Protocol (RSVP) RFC 1363: A Proposed Flow Specification RFC 2475: An Architecture for Differentiated Services RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior) RFC 2597: Assured Forwarding PHB Group RFC 1190: Experimental Internet Stream Protocol, Version 2 (ST-II) RFC 1819: Internet Stream Protocol Version 2 (ST2): Protocol Specification - Version ST2+