This topic points out some of the important aspects of a service-level agreement (SLA) that might affect your quality of service (QoS) implementation.
QoS is a network solution. To receive network priority outside your private network, you might need to have an SLA with your ISP.
You only need a SLA if your policies require priority outside your private network. If you are using outbound policies to throttle traffic leaving your server, then no service guarantee is required. For example, on the server, you can create a policy that gives one application higher priority than another application. Your server recognizes this priority, but anything outside the server might not recognize the priority. If you have a private network and configure your routers to recognize codepoint markings (used to give outbound policies a service-level), then the routers will give priority through your private network. However, if the traffic leaves your private network, there are no guarantees. Without an SLA, you do not control how network hardware will handle traffic. Outside your private network, you will need a SLA to guarantee priority for a class of service or resource reservation.
Your policies and reservations are only as good as the weakest link. This means, that QoS policies enable applications to receive priority through the network. However, if one node anywhere between the client and the server is unable to perform any of the traffic-handling characteristics discussed in the differentiated service or integrated service topics, your policies will not be handled as you intended. If your SLA does not allow you enough resources, even the best policies will not help your network's congestion problem.
This also involves agreements across ISPs. Across domains, every ISP must agree to support QoS requests. Interoperability might cause some challenges.
Make sure that you understand the service-level that you are actually receiving. Traffic conditioning agreements specifically address how traffic is handled, what is dropped, marked, shaped, or retransmitted. The key reasons to provide QoS involve controlling latency, jitter, bandwidth, packet loss, availability, and throughput. Your service agreements must be able to give your policies what they request. Verify that you are receiving the amount of service you need. If not, you might waste your resources. For example, if you ask to reserve 500 Kbps for IP telephony but your application only needs 20 Kbps, you might pay extra without receiving any notice from your ISP.