e for avoiding congestion, and it works best for congestion-responsive flows such as TCP. But voice has constant bit rate and, hence, is not usually responsive, and it uses UDP. So although RED is a good mechanism for many network applications, it is not the most effective for IP voice. Weighted Fair Queuing (WFQ)-With WFQ, each flow gets a share of the server link bandwidth in proportion to its weight. Per-packet delay guarantee in a WFQ scheduler depends on the accuracy of the WFQ implementation. IntServ RSVP architecture-As discussed in Chapter 10, RSVP is the pri- mary specification for handling multimedia traffic over IP subnets (see Figure 9.3). RSVP messages are carried over IP/UDP. RSVP enhances con- nectionless best-effort service by providing QoS requests and guarantees. There are two main classes of service: RFC 2211 specifies control-load or best-effort service, and RFC 2212 is the guaranteed class of service (CoS), offering bandwidth and delay guarantees. RSVP relies on a router-to-router signaling scheme, which allows IP applications to request priority, delay, and bandwidth guarantees. The connection is established link by link and Source Destination Figure 9.3 VolP QoS: IntServ RSVP is denied if a router cannot accept the request. Signaling is distinct from routing. Transparent operation across non-RSVP routers is possible. RSVP supports shared and distinct reservations, applies to unicast and multicast applications, and is simplex and receiver oriented. RSVP is well suited for real-time applications and delay-sensitive traffic. However, it does not scale well in large networks, so it is not used much in WANs. IP precedence-IP precedence is the poor-man's approach to QoS. The IP precedence or DiffServ Code Point (DSCP; discussed in detail in Chapter 8, "The Internet and IP Infrastructures") is set higher on voice packets. This puts them in a different queue, resulting in isolation from best-effort traffic. It can be done by the endpoint, by a proxy, or in routers through heuristics. IP precedence 