IP Flow Control and QoS

This section summarizes the flow-control and QoS mechanisms supported by IP.

IP Flow Control

IP employs several flow-control mechanisms. Some are explicit, and others are implicit. All are reactive. The supported mechanisms include the following:

• Tail-drop

• Internet Control Message Protocol (ICMP) Source-Quench

• Active Queue Management (AQM)

• Explicit Congestion Notification (ECN)

Tail-drop is the historical mechanism for routers to control the rate of flows between end nodes. It often is implemented with a FIFO algorithm. When packets are dropped from the tail of a full queue, the end nodes detect the dropped frames via TCP mechanisms. TCP then reduces its window size, which precipitates a reduction in the rate of transmission. Thus, tail-drop constitutes implicit, reactive flow control.

ICMP Source-Quench messages can be used to explicitly convey a request to reduce the rate of transmission at the source. ICMP Source-Quench messages may be sent by any IP device in the end-to-end path. Conceptually, the ICMP Source-Quench mechanism operates in a manner similar to the Ethernet Pause Opcode. A router may choose to send an ICMP Source-Quench packet to a source node in response to a queue overrun. Alternately, a router may send an ICMP Source-Quench packet to a source node before a queue overruns, but this is not common. Despite the fact that ICMP Source-Quench packets can be sent before a queue overrun occurs, ICMP Source-Quench is considered a reactive mechanism because some indication of congestion or potential congestion must trigger the transmission of an ICMP Source-Quench message. Thus, additional packets can be transmitted by the source nodes while the ICMP Source-Quench packets are in transit, and tail-drop can occur even after "proactive" ICMP Source-Quench packets are sent. Upon receipt of an ICMP Source-Quench packet, the IP process within the source node must notify the appropriate Network Layer protocol or ULP. The notified Network Layer protocol or ULP is then responsible for slowing its rate of transmission. ICMP Source-Quench is a rudimentary mechanism, so few modern routers depend on ICMP Source-Quench messages as the primary means of avoiding tail-drop.

RFC 2309 defines the concept of AQM. Rather than merely dropping packets from the tail of a full queue, AQM employs algorithms that attempt to proactively avoid queue overruns by selectively dropping packets prior to queue overrun. The first such algorithm is called Random Early Detection (RED). More advanced versions of RED have since been developed. The most well known are Weighted RED (WRED) and DiffServ Compliant WRED. All RED-based algorithms attempt to predict when congestion will occur and abate based on rising and falling queue level averages. As a queue level rises, so does the probability of packets being dropped by the AQM algorithm. The packets to be dropped are selected at random when using RED. WRED and DiffServ Compliant WRED consider the traffic class when deciding which packets to drop, which results in administrative control of the probability of packet drop. All RED-based algorithms constitute implicit flow control because the dropped packets must be detected via TCP mechanisms. Additionally, all RED-based algorithms constitute reactive flow control because some indication of potential congestion must trigger the packet drop. The proactive nature of packet drop as implemented by AQM algorithms should not be confused with proactive flow-control mechanisms that exchange buffer resource information before data transfer occurs, to completely avoid frame/packet drops. Note that in the most generic sense, sending an ICMP Source-Quench message before queue overrun ocurs based on threshold settings could be considered a form of AQM. However, the most widely accepted definition of AQM does not include ICMP Source-Quench.

ECN is another method of implementing AQM. ECN enables routers to convey congestion information to end nodes explicitly by marking packets with a congestion indicator rather than by dropping packets. When congestion is experienced by a packet in transit, the congested router sets the two ECN bits to 11. The destination node then notifies the source node (see the TCP Flow Control section of this chapter). When the source node receives notification, the rate of transmission is slowed. However, ECN works only if the Transport Layer protocol supports ECN. TCP supports ECN, but many TCP implementations do not yet implement ECN. For more information about IP flow control, readers are encouraged to consult IETF RFCs 791, 792, 896, 1122, 1180, 1812, 2309, 2914, and 3168.

IP QoS

IP QoS is a robust topic that defies precise summarization. That said, we can categorize all IP QoS models into one of two very general categories: stateful and stateless. Currently, the dominant stateful model is the Integrated Services Architecture (IntServ), and the dominant stateless model is the Differentiated Services Architecture (DiffServ).

The IntServ model is characterized by application-based signaling that conveys a request for flow admission to the network. The signaling is typically accomplished via the Resource Reservation Protocol (RSVP). The network either accepts the request and admits the new flow or rejects the request. If the flow is admitted, the network guarantees the requested service level end-to-end for the duration of the flow. This requires state to be maintained for each flow at each router in the end-to-end path. If the flow is rejected, the application may transmit data, but the network does not provide any service guarantees. This is known as best-effort service. It is currently the default service offered by the Internet. With best-effort service, the level of service rendered varies as the cumulative load on the network varies.

The DiffServ model does not require any signaling from the application prior to data transmission. Instead, the application "marks" each packet via the Differentiated Services Codepoint (DSCP) field to indicate the desired service level. The first router to receive each packet (typically the end node's default gateway) conditions the flow to comply with the traffic profile associated with the requested DSCP value. Such routers are called conditioners. Each router (also called a hop) in the end-to-end path then forwards each packet according to Per Hop Behavior (PHB) rules associated with each DSCP value. The conditioners decouple the applications from the mechanism that controls the cumulative load placed on the network, so the cumulative load can exceed the network's cumulative capacity. When this happens, packets may be dropped in accordance with PHB rules, and the affected end nodes must detect such drops (usually via TCP but sometimes via ICMP Source-Quench). In other words, the DiffServ model devolves into best-effort service for some flows when the network capacity is exceeded along a given path.

Both of these QoS models have strengths and weaknesses. At first glance, the two models would seem to be incompatible. However, the two models can interwork, and various RFCs have been published detailing how such interworking may be accomplished. For more information about IP QoS, readers are encouraged to consult IETF RFCs 791, 1122, 1633, 1812, 2205, 2430, 2474, 2475, 2815, 2873, 2963, 2990, 2998, 3086, 3140, 3260, 3644, and 4094.