Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 30 Quality of Service Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.

Similar presentations


Presentation on theme: "Chapter 30 Quality of Service Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display."— Presentation transcript:

1 Chapter 30 Quality of Service Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.

2 30.1 DATA-FLOW CHARACTERISTICS 30.1 DATA-FLOW CHARACTERISTICS Applications Sensitivity to reliability, delay, jitter, and bandwidth FLOW CONTROL TO IMPLEMENT QoS o Traffic Shaping/Policing: leaky/token bucket o Scheduling (traffic shaping): FIFO, priority, and weighted fair queuing. o Resource reservation and admission control o There are two major models to enhance QoS: 1) Integrated Services 2) Differentiated Services 1) Integrated Services 2) Differentiated Services Chapter 30: QoS

3 INTEGRATED SERVICES (IntServ) o Bandwidth (and other resources) is explicitly reserved based on type of data-flow. o Service Classes:  Quantitative– Guaranteed, an application specifies the amount of delay and data rate.  Qualitative – Controlled-Load, tolerate some delay but sensitive to overloaded networks and packet loss; as , FTP, HTTP applications requesting the possibility of no or low loss. o Resource Reservation (RSVP) for connection-oriented protocol: Reserve in advance the requested resources by a data flow.

4 DIFFERENTIATED SERVICES (DiffServ) o Differentiated Services : Priorities Applications classes. o Traffic Conditioners : Used to implement DiffServ.

5 DATA FLOW CHARACTERISTICS o To provide Internet applications QoS we first need to define what we need for each application. o Traditionally, four types of characteristics are attributed to a flow: reliability, delay, jitter, and bandwidth. o Define them, then investigate for each application type its requirements.

6 Definitions Informal definitions of the four characteristics: Reliability is a characteristic that a flow needs in order to deliver the packets safe and sound to the destination. Delay Source-to-destination packet delivery duration time. Jitter is the variation in delay for packets belonging to the same flow. Bandwidths : Different applications need different b/s channel capacity & duration availability.

7 Sensitivity of Applications Now let us see how various applications are sensitive to some flow characteristics. Table 30.1 gives a summary of application types and their sensitivity.

8 Table 30.1 : Sensitivity of applications to flow characteristics 30.8

9 Flow Classes  Based on the flow characteristics, we can classify flows into groups, with each group having the required level of each characteristic.  The Internet community has not yet defined such a classification formally.  However, we know, for example, that a protocol like FTP needs a high level of reliability and probably a medium level of bandwidth, but the level of delay and jitter is not important for this protocol.

10 FLOW CONTROL TO IMPROVE QoS Although Internet does not define formal classes of flow, an IP v4 datagram has a Type of Service (ToS) field (Priority field in IP v6 ) that define the required service for a set of application’s datagrams.

11 Scheduling  It is mostly at a router that a packet may be delayed, suffer from jitters, be lost, or be assigned the required BW.  Hence, at routers several scheduling techniques are designed to improve QoS: FIFO, priority, and weighted fair queuing.

12 30.12 Figure 30.1 : FIFO queue

13 30.13 Figure 30.2 : Priority queuing ****** Q1Q1 QnQn

14 30.14 Figure 30.3 : Weighted fair queuing

15 Traffic Shaping or Policing  To control the amount and the rate of traffic.  Traffic Shaping is to control the traffic when it leaves the network.  Traffic Policing is to control the traffic when it enters the network.  Two techniques can shape or police the traffic: leaky bucket and token bucket.

16 30.16 Bursty Traffic Policing VS. Shaping: (http://www.cisco.com/c/en/us/support/docs/quality-of- service-qos/qos-policing/19645-policevsshape.html#traffic) The following diagram illustrates the key difference. Traffic Policing propagates bursts. When the traffic rate reaches the configured maximum rate, excess traffic is dropped (or remarked). The result is an output rate that appears as a saw-tooth with crests and troughs. Traffic Shaping In contrast to policing, retains excess packets in a QUEUE and then schedules the excess for later transmission over increments of time. The result of traffic shaping is a smoothed packet output rate. Shaping implies the existence of a queue and of sufficient memory to buffer delayed packets, while policing does not buffer excess packets.

17 30.17 Bursty Traffic Policing VS. Shaping: (http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html#traffic)

18 30.18 Leaky Bucket A water bucket leaks (outputs) in a constant rate of water regardless of the input flow of water. Hence, a network can regulate the output data rate of its bursty input traffic rate.

19 30.19 Figure 30.4: Leaky bucket Mbps

20 30.20 Figure 30.5: Leaky bucket implementation Algorithm byte-counting LB for variable size packets 1: count = n; (at the clock tick) While ((count => packet-size) & (Queue is not empty)) {send packet; count = count - packet-size} go to 1;

21 30.21 Figure 30.6 : Token Bucket Since the Leaky Bucket is not fai r for idle host for long times then gets bursty data, it still transmits the average rate (ignoring its long idle time)! Hence, we have Token Bucket (TB).

22 30.22 (http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html#wpxref22120(http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html#wpxref22120)  The bucket gets tokens at a certain rate (data unit per sec, du/s).  A token is permission for the source to send a certain number of du’s into the network.  To send a packet, remove from the bucket a number of tokens equal in representation to the packet size in du’s.  If not enough tokens are in the bucket to send a packet, the packet either: o queued waiting until the bucket has enough tokens (in the case of a shaper ), OR o discard/marked-down (in the case of a policer).  If the bucket fills to its specified capacity (max burst size), newly arriving tokens are discarded.  A token bucket permits burstiness, but bounds ( shape / police ) it.

23 30.23  The token bucket algorithm provides users with three actions/categories for each in-bound (incoming) packet, in case of Traffic Policing configured : o a conform action– Config. to transmit packet, o an exceed action– Config. to transmit packet but with lower priority, and o an optional violate – Drop the packet.

24 Let assume that the bucket capacity is 10,000 tokens and tokens are added at the rate of 1000 tokens per second. If the system is idle for 10 seconds (or more), the bucket collects 10,000 tokens and becomes full. Any additional tokens will be discarded. The maximum average rate is shown below. Example

25 Resource Reservation A flow of data needs resources such as a buffer, bandwidth, CPU time, and so on. The quality of service is improved if these resources are reserved beforehand. Below, we discuss a QoS model called Integrated Services, which depends heavily on resource reservation to improve the quality of service.

26 Admission Control Admission control refers to the mechanism used by a router or a switch to accept or reject a flow based on predefined parameters. Before a router accepts a flow for processing, it checks the flow specifications to see if its capacity can handle the new flow. It takes into account bandwidth, buffer size, CPU speed, etc., as well as its previous commitments to other flows. Admission control in ATM networks is known as Connection Admission Control (CAC), which is a major part of the strategy for controlling congestion..

27 INTEGRATED SERVICES (INTSERV) IETF developed the Integrated Services (IntServ) model. In this model, which is a flow- based architecture, resources such as bandwidth are explicitly reserved for a given data flow. In other words, the model is considered a specific requirement of an application in one particular case regardless of the application type.

28 Flow Specification We said that IntServ is flow-based. To define a specific flow, a source needs to define a flow specification, which is made of two parts: 30. Rspec (resource specification). Rspec defines the resource that the flow needs to reserve (buffer, bandwidth, etc.). 2. Tspec (traffic specification). Tspec defines the traffic characterization of the flow, which we discussed before.

29 Admission After a router receives the flow specification from an application, it decides to admit or deny the service. The decision is based on the previous commitments of the router and the current availability of the resource.

30 Service Classes Two classes of services have been defined for Integrated Services: guaranteed service and controlled-load service.

31 RSVP Since IP is a connectionless protocol, a new protocol is designed to run on top of IP to make it connection-oriented. A connection-oriented protocol needs to have connection establishment and connection termination phases, as we discussed in Chapter 18. Before discussing RSVP, we need to mention that it is an independent protocol separate from the Integrated Services model. It may be used in other models in the future.

32 30.32 Figure 30.7 : Path messages

33 30.33 Figure 30.8 : Resv messages

34 30.34 Figure 30.9 : Reservation merging

35 Problems with Integrated Services There are at least two problems with Integrated Services that may prevent its full implementation in the Internet: scalability and service-type limitation: scalability and service-type limitation.

36 DIFFERENTIATED SERVICES (DIFFSERV) In this model, packets are marked by applications into classes according to their priorities. Routers and switches, using various queuing strategies, route the packets. This model was introduced by the IETF to handle the shortcomings of Integrated Services.

37 DS Field In DiffServ, each packet contains a field called the DS field. The value of this field is set at the boundary of the network by the host or the first router designated as the boundary router. IETF proposes to replace the existing ToS (type of service) field in IPv4 or the priority class field in IPv6 with the DS field, as shown in Figure

38 30.38 Figure : DS field

39 Per-Hop Behavior The DiffServ model defines per-hop behaviors (PHBs) for each node that receives a packet. So far three PHBs are defined: DE PHB, EF PHB, and AF PHB.

40 30.40 Figure 30.11: Traffic conditioner


Download ppt "Chapter 30 Quality of Service Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display."

Similar presentations


Ads by Google