






































Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
The concept of Quality of Service (QoS) in computer networks, which is the ability of a network to provide different levels of service to different types of traffic. It explains the need for QoS in real-time applications and the different ways to categorize them. The document also covers the two main approaches to QoS support: fine-grained and coarse-grained, and the Integrated Services architecture developed by the IETF, which includes service classes and RSVP. examples of TSpec and RSpec in flowspec and token bucket filter to characterize a flow's bandwidth requirement.
Typology: Slides
1 / 46
This page cannot be seen from the preview
Don't miss anything!
For many years, packet-switched networks have offered the promise of supporting multimedia applications, that is, those that combine audio, video, and data. After all, once digitized, audio and video information become like any other form of data—a stream of bits to be transmitted. One obstacle to the fulfillment of this promise has been the need for higher-bandwidth links. Recently, however, improvements in coding have reduced the bandwidth needs of audio and video applications, while at the same time link speeds have increased.
Voice and video applications tend to be the canonical examples, but there are others such as industrial control —you would like a command sent to a robot arm to reach it before the arm crashes into something. Even file transfer applications can have timeliness constraints, such as a requirement that a database update complete overnight before the business that needs the data resumes on the next day.
The distinguishing characteristic of real-time applications is that they need some sort of assurance from the network that data is likely to arrive on time (for some definition of “on time”). Whereas a non-real-time application can use an end-to- end retransmission strategy to make sure that data arrives correctly, such a strategy cannot provide timeliness. This implies that the network will treat some packets differently from others—something that is not done in the best-effort model. A network that can provide these different levels of service is often said to support quality of service (QoS).
For example, if voice samples were collected at a rate of one per 125 s, they should be played back at the same rate We can think of each sample as having a particular playback time The point in time at which it is needed at the receiving host In this example, each sample has a playback time that is 125 s later than the preceding sample If data arrives after its appropriate playback time, it is useless
For some audio applications, there are limits to how far we can delay playing back data It is hard to carry on a conversation if the time between when you speak and when your listener hears you is more than 300 ms We want from the network a guarantee that all our data will arrive within 300 ms If data arrives early, we buffer it until playback time
The first characteristic by which we can categorize applications is their tolerance of loss of data, where “loss” might occur because a packet arrived too late to be played back as well as arising from the usual causes in the network. On the one hand, one lost audio sample can be interpolated from the surrounding samples with relatively little effect on the perceived audio quality. It is only as more and more samples are lost that quality declines to the point that the speech becomes incomprehensible.
On the other hand, a robot control program is likely to be an example of a real-time application that cannot tolerate loss—losing the packet that contains the command instructing the robot arm to stop is unacceptable. Thus, we can categorize real-time applications as tolerant or intolerant depending on whether they can tolerate occasional loss
We call applications that can adjust their playback point delay-adaptive applications. Another class of adaptive applications are rate adaptive. For example, many video coding algorithms can trade off bit rate versus quality. Thus, if we find that the network can support a certain bandwidth, we can set our coding parameters accordingly. If more bandwidth becomes available later, we can change parameters to increase the quality.
The term “Integrated Services” (often called IntServ for short) refers to a body of work that was produced by the IETF around 1995–97. The IntServ working group developed specifications of a number of service classes designed to meet the needs of some of the application types described above. It also defined how RSVP could be used to make reservations using these service classes.
Service Classes Guaranteed Service The network should guarantee that the maximum delay that any packet will experience has some specified value Controlled Load Service The aim of the controlled load service is to emulate a lightly loaded network for those applications that request the service, even though the network as a whole may in fact be heavily loaded
Overview of Mechanisms Packet Scheduling (^) Finally, when flows and their requirements have been described, and admission control decisions have been made, the network switches and routers need to meet the requirements of the flows. (^) A key part of meeting these requirements is managing the way packets are queued and scheduled for transmission in the switches and routers. (^) This last mechanism is packet scheduling.
Flowspec There are two separable parts to the flowspec: (^) The part that describes the flow’s traffic characteristics (called the TSpec) and (^) The part that describes the service requested from the network (the RSpec). (^) The RSpec is very service specific and relatively easy to describe. (^) For example, with a controlled load service, the RSpec is trivial: The application just requests controlled load service with no additional parameters. (^) With a guaranteed service, you could specify a delay target or bound.