Network Service Models

1. Network Service Models Based on: Dr. Jon Crowcroft’s www.cs.ucl.ac.uk/staff/jon/mmbook/book/node35.html CECS401- Multimedia Systems Prof. Dr. Xinhua Zhang University of Missouri-Columbia Presented by: Othoniel Rodriguez-Jimenez Arturo Guillen

2. Network Service Models:Outline • Arturo Guillen • Introduction • Sharing and Caring • Service Scheduling and Queues • Evolution of the Internet Service Model • Otho Rodriguez • RSVP • Service Classes and Assurance • Detailed Analysis of the Integrated Services • Host Functions • Resource ReSerVation Protocol (RSVP) • QoS Routing • Futures • Arturo Guillen • IP and ATM • Conclusions

3. Network Service Models: Introduction Definition: Service Model refers both to the interface and to the performance that the network gives us. In this talk we are going to take a look at: - Components of user and network that must interact to provide a network service. - The way internet provides these components and how they can fit together to make the service model that a user requires. - Network service models for supporting multimedia. - Mechanisms to provide varying levels of assurance about performance in terms of delay, throughput, loss and standard protocols.

4. Network Service Models:Introduction - User and Network Service Interface

5. Network Service Models: Sharing and Caring I Situation of the Internet: - At the beginning the Internet was intended to support multiple types of service. - Nowadays the “Best effort” service model is the most used in the Internet. In this type of model, each request to send is honored by the network as best as it can. - The most problematic characteristic of the Best effort service model is the lack of contract between the network and the user. - The way users access the Internet made this model the most useful service model so far. Essentially any computer may attempt to communicate with any other computer at any moment.

6. Network Service Models: Sharing and Caring II Traditional telecommunication networks: - The actual situation of the Internet is in direct contrast with the traditional telecommunication networks. For example, in telephony system, the network can be provisioned for the expected # of calls at any time. - call blocking: congestion or overload. Here the degradation of service is to the users who get none, rather than to users who have established access to the network. - leased line: strong resource commitment between the network and the user.

7. Network Service Models: Sharing and Caring III Internet vs Traditional telecomm. Networks:

8. Network Service Models: Sharing and Caring IV How do we specify a “contract” between the user and the network? - In networks we have different types of traffic from different applications. We can specify a “contract” with the network in terms of a set of performance parameters. Table of service “contract” models:

9. Network Service Model:Sharing and Caring V - User Expectation and Service Models - The service model that a network provides has a profound effect on user expectations. - It’s very important to consider users’ expectations, when considering QoS requirements. - Modern phone network vs mobile phone. - In today’s Internet users have a lack of expectation of quality. Users accept low quality of audio and video communication.

10. Network Service Model:Service Schedules and Queues - Performance of a comm. path is made up of contributions from many places: - technology used: - throughput of each link. - error rate (due to noise). - delay for the path: - propagation time. - Store/forward time. <-- Here is were we can improve performance - To change “Best effort” service used in the Internet we need to: - recognize the user traffic. - give different treatment in the queues to that traffic. - There are different proposed queuing systems: - for example: Fair Queuing: round robin scheduler for each source-destination. - A given device can implement several different queuing mechanisms and sort packets into the appropriate queue based on some notion of packet classification.

11. Network Service Models: Evolution of the Internet Service Model - The “best effort” Internet has provided the worst service possible for multimedia: - packets are forwarded by routers solely on the basis that there is any known route, irrespective of the traffic along the route. - Routers overloaded discard packets (typically at the tail of the queue). - Other types of digital networks have been built. The most notably (for wide public access) it is based on the Integrated Services Digital Network architecture: - gives constant rate from source to sink, irrespective of whether you have something ready to send at any moment or not. - inconvenient: It’s narrow band service. - Most recently, we have seen an evolution towards a more flexible support for multimedia service: Multiservice IP and broadband ISDN (the last one provided by ATM). - At this point, the notion of Traffic Classes (each of which have a range of parameters = QoS parameters) have being designed.

12. Network Service Models: Evolution of the Internet Service Model - Classification and Admission I CLASSIFICATION: - A class is supported by some queuing discipline being applied especially to a particular flow of traffic. - This is set up using a signaling protocol by: - network manager. - programmed into a router. - request by user. - In the Internet the signaling protocol has to provide: - traffic flow category. - the QoS parameters. - a way for a router to recognize the packets belonging to the flow.

13. Network Service Models: Evolution of the Internet Service Model - Classification and Admission II - The classification is simply based on a set of packet fields that remain constant for a flow: - UDP and TCP port #. - IP level transport identifier. - source and destination IP host addresses. - To dynamically create this classification, and map it into routers queues, the Internet has devised RSVP, the Resource Reservation Protocol. ADMISSION: - When a service request is made it can deny access to a flow. Right now a normal IP router cannot do this.

14. Network Service Models: Evolution of the Internet Service Model - Integrated Service Model • Key features of Integrated Servs. Arch. • Reserved Resources • router must know resources committed for on-going sessions • Call Setup (call admission) • requires participation of all routers in path • router determines available local resources required for the flow

15. Network Service Models: Evolution of the Internet Service Model - Integrated Service Model - Right now there are 5 classes of service:

16. Network Service Models: Evolution of the Internet Service Model - Differentiated Services - Differentiated Services have emerged in the Internet as a Class of Service to provide better than “Best effort” quality, in contrast to Integrated Services which uses more stringent and complex QoS approach. - Essentially, through pricing and understanding of user requirements, it appears that we can control a repertoire of quality of service parameters for each application. - A class of service is selected (by subscription or by marking using class of service bits in each packet header) and the routers along the path have programmed the parameters for each class. - There is great enthusiasm for this approach nowadays.

17. Network Service Models • Outline • RSVP, an Overview • Service Classes and Assurance • Detailed Analysis of Integrated Services Internet (ISI) • Host Functions to Support ISI • Resource ReSerVation Protocol (RSVP), in Detail • QoS Routing • Futures

18. Network Service ModelsResource ReSerVation Protocol • An Overview, will discuss in detail later • RSVP [Zhang-94] • Establishes resources reservations in the network routers for different flow classes • Dual Function Protocol: • Installs knowledge on classes of flows • This is known as the FilterSpec • Details QoS needed by those flows • This is known as the FlowSpec

19. Network Service ModelsResource ReSerVation Protocol • RSVP motivation: • fill the needs of multimedia applications distributed using Multicast Procotocol • Important Concepts of Multicast Prot.: • On each multicast address (MC-IP/port), several senders (identified by their IP/port) source packets and an unspecified and anonymous number of receivers subscribe

20. Network Service ModelsResource ReSerVation Protocol • Filter Specs. are re-usable in two ways: • Senders and Receivers can independently specify flow characteristics • Receivers can select sub-band rates or sub-set of senders most convenient to them • Similar to people choosing among B&W/Color, mono/stereo, NTSC/HDTV • Wild-card filterSpec refers to groups of sources • A user in a teleconference only needs 1 voice chan. that may originate at any of the participants • More when we discuss traffic Merging Styles later

21. Network Service ModelsResource ReSerVation Protocol • Flow Specs • Used for Admission Control and Traffic Re-shaping • For each class of service specify quantitative parameters • mean rate, and burstiness, • modeled through the token-bucket parameters • Tokens are credits that accumulate at rate r, and are expended 1:1 with each byte of packet traffic admitted fixed token rate, r associated with mean rate b (depth) associated to peak burst x L bytes Yes To traffic shaper L <= x ? No Conforming Non-conforming

22. Network Service ModelsService Classes and Assurance • Service Classes and Assurance • Associated with all proposed service classes we find two functions: • Admission control: (before admission) • Can serv. be traffic supported with current resources • Refusal control, or call reservation blocking • Policing action: (after admission) • Does actual flow violates requirements or capacity? • If yes, do we use queue tail packet dropping or Random Early Detection (RED) dropping , or others?

23. Network Service ModelsDetailed Analysis of Integrated Services Internet • IETF and Integrate Services Internet • Services classes are defined with QoS commitments from routers traversed by flow. • End applications request QoS on a per flow basis • Requests specify level of resources, as well as Routers transmission scheduling behavior • Packets in flow are to receive QoS committed • Session identifies flow; a generalized port spec: Session: Destination MC-IP address and Port num, Transport protocol, and List of Senders to session with their IP and Port number

24. Network Service ModelsDetailed Analysis of Integrated Services Internet • Integrated Services Over Specific Lower Layers (ISSLL) • Specify how router negotiates service guarantees from “QoS-active” lower layers • Example: ISSLL required to use ATM as LL • Router receives application’s flow “traffic envelope”, a.k.a. traffic arrival pattern, for example MTU parameter is data link layer media dependent. • Otherwise, Router controls passive link layers directly

25. Network Service ModelsDetailed Analysis of Integrated Services Internet • Installed reservations on Routers along path will not change as long as: • no path changes, no router fails, and requested resources are not exceeded during flow lifetime. • RSVP senders refresh timers allow restablishment • Behaving data flows are protected from non-conforming flows which trigger policy enforcement activity in the Router • IETF has considered many but formally specified two classes: Guaranteed Svc., Controlled Load

26. Network Service ModelsHost Functions for Integrated Service Internet • Host Functions needed to Support ISI • Controlled Load Service • Guaranteed Service • Policing and Conformance • Integrated Services on Specific Link Technology

27. Network Service ModelsHost Functions for Integrated Service Internet • Controlled-Load Service • Same Tspec (traffic) as for Guaranteed but without the peak-rate parameter. • Service committed is equivalent to that of a lightly loaded network under Best-Effort, with little deterioration upon load increases • Example: For applics. that can tolerate some limited loss and delay: • like existing MBONE applic. with adaptive playout buffering, • or some delay sensitive protocols like LAT, (assumes LAN-like environment latencies, i.e.Local Area Transport)

28. Network Service ModelsHost Functions for Integrated Service Internet • Guaranteed Service • Assured bandwidth (b/w) • Firm end-to-end delay • No queuing loss • Suitable for legacy applic. expecting delivery model similar to Telecom circuits • Router allocates b/w R and buff.spc. B using “fluid model” of service

29. Network Service ModelsHost Functions for Integrated Service Internet • Guaranteed Service • uses perfect Fluid Model: • token bucket at rate r, and depth d, link rate R • delay due to burst b is bounded by b/R when R >=r • router model dev. from ideal, error terms C & D • give delay bound of: b/R+ C/R+ D where C&D correspond to packet size and scheduling delays • GS further bounds the flow peak rate p and the maximum packet size M for more precise bound on delay, • these are summed to obtain the bound on the end to end path delay through all the routers.

30. Network Service ModelsHost Functions for Integrated Service Internet • Fluid Model equations (missing in Website) • End to End Delay Bound , • Eq.(1) for case p > R >= r  =(b-M)(p-R) / (R(p-r)) + (M + Ctot)/R + Dtot • Eq.(2) for case R >= p>= r  = 0 + (M + Ctot)/R + Dtot • In (2) with R>=p there is no peak rate shaping delay term because there is no need to use queuing to re-shape traffic • Reference: (McDysan, David; QoS & Traffic Management in IP & ATM Networks, 2000, McGraw-Hill, ISBN 0-07-134959-6, available at EBW Engineering Library

31. Network Service ModelsHost Functions for Integrated Service Internet • Guaranteed Service • FlowSpec made up of: • Tspec parameters: (traffic) • p: peak rate of flow (bytes/sec) • b: bucket depth (bytes) • r: token bucket rate (bytes/sec) • m: minimum policed unit (bytes) • M: maximum datagram size (bytes) • Rspec parameters: (reservation) • R: bandwidth, i.e. service rate (bytes/ sec) • S: slack Term (ms), when end-to-end delay < applic req. • Besides Rspec R & Tspec router needs terms Csum and Dsum since last reshape point, uses these to calculate queuing buffer size B

32. Network Service ModelsHost Functions for Integrated Service Internet • Guaranteed Service • Traffic policed at network Access points • Traffic reshaping required at points where: • possible to exceed the Tspec even though all senders associated to data flow conform to their individual Tspecs. • at branch points in distribution tree • at merge points in the distribution tree for sources sharing the same reservation • this reshaping incurs in additional queuing delay

33. Network Service ModelsHost Functions for Integrated Service Internet • Policing and Conformance • Routers must check flows for conformance to Tspecs • Prevent non-conforming flows from negatively impacting QoS of conforming or best effort pkt • Alternatives for handling non-conformance: • handle as Best Effort traffic • assign lower effort than Best Effort • degrade individual packets or all packets in flow • Pricing policies might force lesser service to non-conforming traffic

34. Network Service ModelsHost Functions for Integrated Service Internet • Integrated Srvcs with Specific Link Layer • Routers must implement ISSLL: • Queue servicing disciplines like Weighted Fair Queuing, hierarchical round-robin are a baseline requirement to support Guaranteed Service, while simple priority queuing may suffice for Controlled Load. • Need a mechanism for controlling the link interconnect technology • IP across ATM switches maps RSVP QoS requests into AMT Q.2931 requests.

35. Network Service ModelsResource Reservation Protocol • Resource ReSerVation Protocol (RSVP) • Enables senders, receivers and routers of communication sessions to communicate • to setup the necessary router state to support the services required by a session. • Novel signaling protocol in three ways: • multicast, receiver-driven request model • uses soft-state • low cost in implementation in end-sys. and routers • RSVP operations apply to packets of a session

36. Network Service ModelsResource Reservation Protocol • A signaling, not a routing protocol • uses any pre-existing route set up by underlying routing protocol, i.e. Multicast distribution tree • Path message originates from traffic sender • installs reverse-routing information for routers in path • inform receivers of characteristics of path to sender • Reservation message originates from traffic recvr • carry reservation requests to routers along distribution tree from receivers toward senders (upstream) • receivers must periodically issue refresh reservation message to their reservation upstream router • Router issues periodic refresh Reservation msg to upstream router, while reservation is active

37. Network Service ModelsResource Reservation Protocol UPSTREAM DOWNSTREAM Resv ResvTear PathErr Path PathTear ResvConf ResvErr RC1 S1 R1 R2 R3 RC2 R4 RC3

38. PathMsg modified PathMsg refreshRsvMsg (periodic local origin) refreshRsvMsg (from dowstream) RsvTearMsg RsvTearMsg Network Service ModelsResource Reservation Protocol Router Interface Soft State FlowSpec FilterSpec refresh timers clean-up timers Refresh PathMsg (from upstream) refresh PathMsg (periodic local origin) merged RsvMsg RsvMsg PathTearMsg FlowSpec FilterSpec PathTearMsg Refresh Rsv/Path msgs originate locally while Reservation/Path exists. Local Rsv state refreshed by downstream refresh Reservation msgs Local Path state is refreshed by upstream refresh Path messages Refresh messgs locally originated every refresh time-out interval Received Reservation/Path messages reset respective clean-up timer

39. Network Service ModelsResource Reservation Protocol • Reservation styles and Merging • FilterSpec and FlowSpec are obtained by • merging resource requests from arriving Resv messages • Reservation style • Determines the way Reservation Specification merging is performed when reservation message arrives • Three reservation styles: • Fixed Filter (FF) • Wildcard Filter (WF) • Shared Explicit(SE)

40. Network Service ModelsResource Reservation Protocol RSVP Reservation Options Reservation Distinct Shared Choice of Sender Explicit Shared-Explicit (SE) Style Fixed-Filter (FF) Style Wildcard Wildcard Filter (WF) Style Not Defined Merging can only occur with Resv of the same Style and for the same Session (Source: Multimedia Comm. Protocols and Applic, Kuo,Effelsberg,Garcia-Luna)

41. Network Service ModelsResource Reservation Protocol forwards S  session sources B  b/w units Fixed Filter (FF) Reservation Example

42. Network Service ModelsResource Reservation Protocol Wildcard Filter Reservation Example WF reservation scope must apply to outgoing intrf to agregate

43. Network Service ModelsResource Reservation Protocol Shared Explicit Reservation Example

44. Network Service ModelsResource Reservation Protocol • Path Messages information • Phop(previous hop): addr. of last RSVP-capable node to forward this message, updated by routers • Sender Template FilterSpec: sender IP/port • Sender Tspec: sender source traffic characteristics • Optional Adspec (OPWA) updated at routers along path, and informs receivers of level of resources required to obtain a given end-to-end QoS

45. Network Service ModelsResource Reservation Protocol • Processing and Propag. of Path Mssgs. • Update, or create Path state within router • Path state stored includes: Sender Tspec, the address Phop of previous upstream router, and optional Adspec • Sender Tspec provides ceiling to guard against overspecified Reservation requests • Reset cleanup-timer, used for soft-state time-out • Router updates and forwards Path message • periodically sends path message to refresh path state • Reception of a PathTear messg removes path and reservation state , usually at session-end

46. Network Service ModelsResource Reservation Protocol • Adspec • Optional service descriptor in Path mssgs • Advertises to recvrs characteristics end-end path • Consists of: • Message header • Default General Parameters part • At least one of: • Guaranteed Service part • Controlled-Load Service part

47. Network Service ModelsResource Reservation Protocol • Adspec: Default General Part contains: • Minimum Path Latency: end-to-end link latency, needs adding queuing delay to obtain real end-end delay • Path Bandwidth: minimum link b/w along path • Global Break bit: flags RSVP not supported by some router • Integrated Svcs Hop Count: incremented by RSVP/IS router • Path MTU: Max Trans. Unit, is minimum of links’ MTU.

48. Network Service ModelsResource Reservation Protocol • Adspec: Guaranteed Service Part • Ctot and Dtot - end to end composed values for C and D • C is rate dependent queuing delay • D is rate independent queuing delay • Csum and Dsum - composed value for C and D since last re-shaping point, used/modified by flow reshaping processes • Guaranteed Service Break bit - flags no support for G.Svc. • Guaranteed Service General Parameters Headers/Values - will override corresponding Default parameters with respect to Guaranteed Service.

49. Network Service ModelsResource Reservation Protocol • Adspec: Controlled Load Part • Controlled-Load Service Break bit - set by any RSVP/IP router that does not support Controlled -Load • Controlled-Load Service Parameters Headers/Values - Override specific General Parameters as far as receiver wishing to make a Controlled-Load reservation is concerned. • Omission of either Controlled Load Part or Guaranteed Service part means that such QoS is not available. Can be used to force receivers to choose the same service.

50. Network Service ModelsResource Reservation Protocol • Reservations using One Pass with Advertising (OPWA) • Sender must include Adspec on its Path message, otherwise it is called One Pass (OP) • RSVP goal is to minimize the number of handshakes either for One Pass or OPWA