Achieving QoS
Achieving QoS
Over provision!
- Simplest approach
If this fails, then use TOS field or Diffserv
- Much of the problem is on the access network - hence TOS or Diffserv even only on these links may be enough
If this fails, then use RSVP
- Much more complex - especially when done over several operator’s domains
Transcript
[slide463] The problem we have to address now is, if we need to have QoS, because we're going to charge for quality of service, how can we provide it? And of course the simplest and my favorite approach is just over-provision. If we have plenty of resources, then there's not a problem about congestion, delay, jitter, etc. The problem is, that's expensive. The advantage is, hey, it's really simple. But if that fails, then we probably have to go to type of service or Diffserv. We'll have to label the packets and we'll have to say, how do we want these treated? But that generally causes a problem when we go from one operator to another operator. Because do the label one here have the same meaning as label one over there? Or do we have to re-label it? And how do we negotiate for that? And if all else fails, then use RSVP. Why is RSVP really the last resort? Okay, what's RSVP? [student answers: Resource Reservation Protocol.] Right, so it's a response reservation protocol. I think it's the last resort because it reserves the whole path. [student question inaudible] We have to set up the whole path first. But you can't guarantee the return direction, like if you have a traffic control. You define only one way. But you can't guarantee the same quality of service to be in the other direction. That's right. You can't even guarantee that there will be a path in the other direction that meets your desired quality of service. Because it's a separate negotiation, RSVP. And that makes it complex.