Method and apparatus to avoid network congestion

[0001] This application hereby claims priority under 35 U.S.C. § 119 to U.S. Provisional Patent Application No. 60/797,644, filed on 3 May 2006, entitled “ACTIVE BURST CONTROL.” The contents of this provisional patent application are hereby incorporated by reference.

[0002] 1. Field of the Invention

[0003] The present invention generally relates to communication networks. More specifically, the present invention relates to techniques and systems to avoid congestion in a network.

[0004] 2. Related Art

[0005] Network congestion is usually a consequence of nonexistent or inadequate flow controls below the transport protocol layer in conjunction with dynamic traffic bursts that oversubscribe underlying memories and queues. The lack of flow control is usually accepted as the status quo for several reasons. First, congestion mitigation at the transport layer can be reasonably effective for certain types of connections. Second, small networks with well-behaved traffic patterns may not experience congestion. Third, popular datalink layer protocols (e.g., Ethernet) and network layer protocols (e.g., Internet Protocol) are connectionless. Hence, it can be difficult to implement anything but coarse-grained flow control using such protocols. Fourth, the typical networking stack does not provide a control path between low-layer queues and higher-layer flow control entities.

[0006] Conventional techniques usually do not prevent or control congestion onset. Instead, they typically reduce the offered load from hosts by responding after congestion loss has occurred. Conventional techniques are usually based on the following concept: if hosts reduce their load by a sufficient amount when congestion is detected (or suspected), the sum of their loads at congestion points will decrease, thereby mitigating congestion. These conventional techniques were typically developed to keep the network core as simple as possible while pushing adaptation techniques to the endpoints of the network.

[0007] Unfortunately, conventional techniques for combating congestion are not effective in many emerging network applications such as latency-sensitive applications and large-scale distributed applications. Specifically, latency-sensitive applications pay a penalty (e.g., increased and/or variable latency) when conventional techniques are used to mitigate congestion. Further, large-scale distributed applications have bursty traffic loads that are difficult, and sometimes impossible, to mitigate with after-the-event response techniques. Observations within contemporary datacenter networks suggest that congestion loss caused by rapid traffic bursts may be an increasing problem as distributed applications continue to grow and mature.

[0008] One embodiment of the present invention provides a system that avoids network congestion. During operation, the system can detect an onset of congestion in a first queue at a first node. The first node may be coupled to a second node using a first link. Next, the first node can generate a first control-message, wherein the first control-message contains a congestion-point identifier which is associated with the first queue. The congestion-point identifier can be unique within a network, i.e., each queue in the network can be associated with a distinct congestion-point identifier. The first node can then send the first control-message to the second node through the first link, which can cause the second node to delay sending a second message to the first node, wherein the second message is expected to be routed through the first queue at the first node.

[0009] The first queue may contain a first message that was received from the second node. If the first queue does not contain a message that was received from the second node, the first node may not send a control-message to the second node. Upon receiving the first control-message from the first node, the second node may decide not to delay a third message if the third message is not expected to be routed through the first queue at the first node.

[0010] The second node may receive the first control-message which may contain the congestion-point identifier. Next, the second node may receive a second message, which is expected to be routed through the first queue at the first node. The second node may then use information contained in the first control-message to determine whether to delay the second message. Next, the second node may delay the second message by queuing the second message in a second delay-queue at the second node.

[0011] The second node may generate a second control-message at the second node which may contain the congestion-point identifier. Next, the second node may send the second control-message to a third node through a second link, wherein the second node is coupled to the third node using the second link. Note that sending the second control-message to the third node may cause the third node to delay sending a fourth message to the second node which is expected to be routed through the first queue at the first node.

[0012] A system may detect the onset of congestion in the first queue by first determining a difference between an arrival rate of the first queue and an egress rate of the first queue. Next, the system may determine the onset of congestion by comparing the difference with a threshold. Alternatively, the system may detect the onset of congestion by comparing the number of messages in the queue with the threshold. The system may determine the threshold by: determining a burst duration; determining the number of messages in the first queue; and determining the threshold using the number of messages and the burst duration.

[0013] The first node may send a routing-information message to the second node. The routing-information message may contain the congestion-point identifier, and the routing-information message may enable the second node to determine whether the second message is expected to be routed through the first queue at the first node.

[0014] The second node may send a second routing-information message to the third node, wherein the second routing-information message may enable the third node to determine whether a message is expected to be routed through the first queue at the first node.

[0024] The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

[0025] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer readable media now known or later developed.

Network

[0026] FIG. 1 illustrates a network in accordance with an embodiment of the present invention.

[0027] Network 100 comprises core router 102, cluster router 104, edge switches 106 and 108, and hosts 110 and 112. Core router 102 is coupled with cluster router 104 using a 10 Gbps (Gigabits per second) link. Cluster router 104 is coupled with edge switches 106 and 108 using 10 Gbps links. Edge switches 106 and 108 are coupled with hosts 110 and 112 using 1 Gbps links.

[0028] Network 100 can be part of a larger network. For example, core router 100 may be coupled with other core routers and/or other cluster routers. Embodiments of the present invention are not limited to the topology, technology, or architecture of network 100.

[0029] A network can generally include network nodes that are coupled together using wired or wireless communication channels. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment, a network can include the Internet.

[0030] A network node (or “node” for short) can generally include any type of device capable of communicating with other devices via a network. This includes, but is not limited to, a computer system based on a microprocessor, a mainframe computer, a printer, a router, a switch, a personal organizer, or a mobile phone. Network nodes shown in FIG. 1 include core router 102, cluster router 104, edge switches 106 and 108, and hosts 110 and 112.

Network Congestion

[0031] Queue capacities are typically engineered to ensure that queue overflow is unlikely. That is, the queues are designed to absorb a certain amount of burst data for a period of time during which the arrival rate of data at a queue exceeds the egress rate. But if the bandwidth and duration of a burst exceeds the queue capacity, the queue may overflow and messages may be dropped. The arrival of 10 Gbps networking gear and 10 Gbps host interfaces—a 10 fold increase in link bandwidth—has not been accompanied by a similar increase in queue capacity. This causes queues and memory buffers to become more vulnerable.

[0032] FIG. 2 illustrates how network congestion can occur at a network node in accordance with an embodiment of the present invention.

[0033] Network node 200 comprises ports 202, 204, 206, and 208. Queue 210 stores messages before they are sent out on port 208. A message can generally comprise any information that can be sent from a source to one or more destinations. Specifically, a message can comprise one or more packets or one or more protocol data units.

[0034] Note that queue 210 has a limited capacity. Hence, queue 210 may overflow if network node 200 receives a sudden burst of messages on ports 202, 204, and 206 which need to be routed through port 208. If queue 210 overflows, messages may be dropped or lost, thereby degrading network performance.

[0035] Some network connections connect a remote machine with a local machine within a company's network. Such connections are usually routed through a variety of network elements that have different bandwidths and which are controlled by different organizations. Hence, it is not surprising that such connections often experience congestion. However, congestion can also occur in a company's internal network where all network elements are controlled by a single organization. This type of congestion may not be due to improper circuit provisioning or poor network design. Instead, congestion may occur because of the bursty and unpredictable nature of network traffic.

[0036] A network is typically designed with a range of traffic patterns in mind. But if the traffic pattern varies beyond that range, congestion can occur. Specifically, in a distributed application, if a host sends a request to a number of nodes in a cluster, the nodes may simultaneously send their responses which may cause congestion at the edge router that is coupled with the host.

[0037] Congestion can be solved for long term connections by appropriately adjusting the transmission rate. However, when a computer exchanges messages (which can be in the megabytes) with thousands of other computers (e.g., in a distributed application), we typically cannot use conventional techniques for combating congestion because they are not that effective in such situations. This is because when a computer exchanges messages with thousands of computers, it can cause extremely heavy loads for a very short duration that can overwhelm a queue and cause congestion loss. Conventional techniques are usually not designed to adapt to such short bursts.

[0038] One approach to combat congestion is to require the network core to constantly communicate with the hosts to tell them the bandwidth that the network can handle at any given time. However, this approach has drawbacks. Specifically, the host may be a number of hops away from the core which will cause a substantial delay between the host and the core, and hence the core may not be able to tell the host to reduce its transmission rate in time to prevent congestion.

[0039] Another approach is to use fast-acting, fine-grained flow control between endpoints. Although such techniques may be appropriate for implementing flow-control between two hosts, they are usually not scalable. Hence, such techniques may not be able to handle situations where the congestion point is multiple hops away from the source nodes, and where the congestion is due to the simultaneous behavior of thousands of hosts.

[0040] Although flow control credit schemes and ARQ (Automatic Repeat reQuest) schemes are similar, they usually operate at different levels of granularity and resolution. The term “granularity” generally refers to the information units that are being controlled, e.g., messages, packets, etc. The term “resolution” generally refers to the level at which the controls operate.

[0041] A low-resolution or coarse-grained technique may treat a physical channel as a single flow-controlled entity, even if it is carrying many TCP (Transport Control Protocol) connections. A medium-resolution technique may identify and control multiple TCP flows at once. For example, a medium-resolution technique may bundle TCP flows based on shared destination or shared port or shared buffer resource or perhaps shared QoS (Quality of Service) level. A high-resolution technique may identify and control individual TCP flows.

[0042] Ethernet provides a low-resolution link flow control with 802.3 PAUSE messages. However, this technique is not widely employed because of the indiscriminate head-of-line blocking effect when all traffic on a shared link is stopped. High-resolution controls are usually not used in networks because of their complexity and also because they conflict with existing transport layer flow controls within end systems.

[0043] There are a number of conventional techniques for mitigating congestion. TCP halves its congestion window and reduces its slow start threshold when message loss is detected and congestion is presumed, and acts slowly to resume higher levels.

[0044] Some transport implementations provide rate-limiting and/or constant rate output disciplines. This can be effective for engineered network flows where the rates can be provisioned to avoid congestion or to operate effectively over high delay links, e.g. satellite channels, where it is impractical to maintain window sizes comparable to the delay-bandwidth product of the end-to-end path.

[0045] Routers can forward ECN (Explicit Congestion Notification) messages from the network to an end node. This may be faster than detecting congestion via message loss and can be viewed as an acceleration method for transport layer congestion avoidance. Unfortunately, the end node that receives the ECN is usually not the one causing congestion, so the congestion notification is typically sent back to the originating node where it triggers a transport level back-off.

[0046] In Frame Relay or ATM (Asynchronous Transmission Mode), a switch can send a congestion notification to either endpoint of a virtual circuit. Forward ECN sends the notification toward the destination of a flow, similar to ECN (above). Backward ECN sends notification back to the source, avoiding the boomerang route from destination back to source.

[0047] BCN (Backward Congestion Notification) is a proposed mechanism under consideration in the IEEE (Institute of Electrical and Electronic Engineers) 802.1 working group. A router samples its ingress streams and monitors (only) its rate-controlled output queues for their fullness. A monitored queue is known as a “congestion point” in the BCN framework and must have associated with it a unique congestion-point identifier (CPID). A subset of packets arriving at a congestion point are sampled. BCN packets are transmitted back to the origination points of sampled packets. The Destination Address (DA) and Source Address (SA) of a sampled packet are reversed and become the SA and DA, respectively, of a BCN packet. The BCN packets inform the sender of the degree of fullness of the reporting queue.

[0048] When a queue is congested, the backward-flowing BCN packets cause routers sending to that queue to direct their outgoing packets through rate-limited queues. The rates at these queues may be adjusted upwards or downwards in response to received BCN packets. Over time, the network of originating queues may converge to a fixed point that stabilizes the loads in the congested queues.

[0049] BCN has several interesting properties. First, the queue measurements are triggered by packet arrival rather than being performed periodically. Second, BCN control content is generated based on the number of packets in the queue, not on an assessment of packet rate or rate of change. Third, BCN messages include an encoding for “extreme congestion” which requires the originating queue to halt transmission to the congested queue for a random period of time.

[0050] However, BCN also has drawbacks. First, if a congestion point is being saturated by traffic from 100 senders and the input traffic is sampled with probability p=0.01, the queue may have to receive 10,000 packets or more before all 100 senders receive a BCN control message. Second, the BCN proposal seems to be directed to generate control messages at the core of a network, and to send the control messages out to the edge devices. Hence, the BCN proposal may not be able to enable edge devices to generate flow control messages that would propagate through the core and back out to other edge devices.

Process to Avoid Network Congestion

[0051] Burst congestion loss may occur when the excess bandwidth and duration of a burst exceeds the capacity of one or more queues. The excess bandwidth, or magnitude, of the burst can be the difference between the message arrival rate and the message egress rate at the affected queue. The duration can be the length of time of the excess load. If the product of the magnitude and the duration exceeds the capacity of the queue, messages may be dropped.

[0052] Conventional techniques to avoid congestion are usually not effective when network traffic consists of frequent bursts with large magnitude and short duration. Specifically, conventional techniques such as BCN usually react after the burst has passed, or sometimes not at all (because the burst duration is shorter than the congestion control sampling period). In other words, conventional techniques usually cannot avoid burst congestion because their reaction time constants are typically greater than the burst durations.

[0053] In one embodiment, the system detects an onset of congestion by monitoring message arrival rates and egress rates. Onset detection can then trigger a wavefront of “freeze” control-messages that delays the bursting messages “in flight” as they progress through the network toward the congestion point. The freeze propagates backwards through the network from the congestion point toward the source(s) of the burst(s). The freeze may propagate all the way back to the source node(s) or it may propagate for a given number of hops.

[0054] FIG. 3A presents a flowchart that illustrates a process for avoiding network congestion in accordance with an embodiment of the present invention.

[0055] FIG. 3B illustrates how a network node can avoid network congestion in accordance with an embodiment of the present invention.

[0056] The process can begin by detecting an onset of congestion in a first queue at a first node (step 302).

[0057] First node 352 may be coupled to second node 354 using link 360. Specifically, link 360 couples port 358 on first node 352 with port 362 on second node 354. Queue 356 can contain a message that was received from second node 354. For example, the message may have been received on port 358 from second node 354 through link 360.

[0058] FIG. 4 illustrates how a node can detect an onset of congestion in a queue in accordance with an embodiment of the present invention.

[0059] Queue 402 can be an input queue, an internal queue, an output queue, or any other kind of queue which is used to store messages within a node. Messages may arrive at queue 402 at arrival rate 404, and egress from queue 402 at egress rate 406.

[0060] A system (e.g., a node) may determine an onset of congestion in queue 402 using the following process. First, the system may determine a difference 408 between arrival rate 404 and egress rate 406. The arrival rate and the egress rate may be detected using a message counter that is sampled at a constant rate. The counter may be cleared after each sample is taken. Note that the sampling rate can be a tunable implementation parameter.

[0061] Next, the system may compare difference 408 with a threshold to determine whether an onset of congestion has occurred (step 410). For example, if difference 408 is greater than the threshold, the system may determine that it has detected an onset of congestion in queue 402 (step 414). On the other hand, if difference 408 is less than the threshold, the system may determine that it has not detected an onset of congestion (step 416). The system may detect an onset of congestion when the product of difference 408 and the duration of the burst exceeds a threshold.

[0062] In one embodiment, the system can determine the threshold using table 412 that stores queue levels and burst duration values. Specifically, the system may first determine a queue level (e.g., the number of messages in the queue). Next, the system may determine a duration of the burst. The system can then determine the threshold using the queue level and the duration value. For example, the table can be a 2D (two dimensional) table wherein one dimension is associated with the queue level and the other dimension is associated with the duration value. In this embodiment, the system may lookup the threshold by performing a 2D lookup on the table using the queue level and the duration value.

[0063] Note that conventional techniques usually combat congestion after it occurs. Specifically, conventional techniques typically assume that congestion has occurred in the network when a message is lost. In contrast, an embodiment of the present invention is directed to detect congestion before it occurs.

[0064] Successful detection of an onset of congestion may depend on accurate settings for the thresholds. Incorrect settings could lead to false detects, i.e., the system may trigger a control-message when there isn't any congestion (false positive), or the system could miss a congestion event (false negative). An adaptive technique can be implemented that observes congestion and the rate changes that indicate the onset of congestion. The technique can then adaptively determine the threshold and the values in the 2D lookup table. The system may initialize with default settings or with table entries provided by a system administrator. In one embodiment, the adaptive technique may adjust the threshold and the values in the 2D lookup table to minimize the number of false positives and false negatives.

[0065] Continuing with the discussion of FIG. 3A, the first node can then generate a control-message (step 304). In one embodiment, the control-message can include a congestion-point identifier which is associated with queue 356. Further, the control-message may also include a source address, a destination address, a delay amount, and a hop count.

[0066] In general, a congestion-point identifier is an identifier that enables a network node to uniquely identify a congested queue within a relevant portion of the network. The relevant portion of the network can depend on the network connectivity and the number of hops that a message traverses. For example, if the message traverses a large number of hops in a network with high connectivity, the relevant portion of the network may be larger than if the message traverses a few hops in a network with low connectivity. In one embodiment, a congestion-point identifier can include a node-identifier that uniquely identifies a node within a network, and a queue-identifier which uniquely identifies a queue within a node. The node-identifier can be a network address such as an IP address that uniquely identifies the node within the network. The queue-identifier can be a port number that uniquely identifies an output queue within a node. In some cases, and particularly where the congested queue is associated with a host computer system or other end node, the destination IP address of a message may adequately identify a congestion point without need for a separate queue or port number.

[0067] In one embodiment, the control message can be an appropriately modified BCN message which uses the reserved bits in BCN control packet to indicate that the control message should not be treated as a standard BCN message. Note that the present invention is not limited to using the BCN message format. A control message can have a format that is similar to a BCN message, or the control message can have a completely different format that serves the purpose.

[0068] The first node can then send the control-message to a second node (step 306). For example, first node 352 can send the control-message to second node 354 through link 360. By sending the control-message, first node 352 can indicate to second node 354 that queue 356 may experience congestion if second node 354 continues to send messages at the current rate. In one embodiment, the control-message can be an Ethernet “PAUSE” message.

[0069] Once a node detects an onset of congestion in a queue, each new incoming message may generate a control message. The control message may be sent according to a moderation rule. Specifically, the control message may be sent only if no prior control message has already been sent for the same burst and to the same port. A benefit of using the moderation rule is that it enables the network to notify interior routers and switches as soon as possible without flooding the return path.

[0070] Note that control messages may be generated and transmitted using a number of techniques. For example, a single control message may be multicast to the port on which the triggering message was received. Alternatively, a single control message may be multicast to all ports. In yet another embodiment, a control message may be unicast to a congestion source.

[0071] Note that an embodiment may not detect individual flows that are causing congestion. Detecting individual flows can be costly based on current technology, and can also be the wrong approach for certain types of traffic patterns. Further, keeping track of individual flows may not be practical as the number of flows increases.

[0072] Continuing with the discussion of FIG. 3A, the control-message may then be received by the second node (step 308). Note that the control-message may contain the congestion-point identifier. The control-message may also contain routing information which enables the second node to determine whether a message is expected to be routed through a specific queue at the first node. In one embodiment, the congestion-point identifier may be stored in memory, e.g., in a routing table.

[0073] The second node can then receive a message that is expected to be routed through the first queue at the first node (step 310).

[0074] For example, second node 354 may receive a message on port 364. Information contained in the control message may enable second node 354 to determine whether the message that was received on port 364 is expected to be routed through queue 356 at first node 352.

[0075] Next, the second node can use the information contained in the control message to determine whether to delay the message (step 312).

[0076] If the second node determines that the message is to be delayed, it can delay the message by queuing the message in a delay queue at the second node (step 314). For example, second node 354 can delay the message by queuing the message in delay queue 370.

[0077] On the other hand, if the second node determines that the message is not to be delayed, it can send the message to the appropriate egress port (step 316). For example, second node 354 can send the message to egress port 372.

[0078] Note that conventional techniques usually suffer from head-of-line blocking. Specifically, in conventional techniques, when a queue experiences congestion (e.g., drops messages), all traffic is stopped. In contrast, an embodiment of the present invention may only delay traffic that is destined to the queue for which an onset of congestion has been detected.

[0079] In one embodiment, first node 352 can send a rapid sequence of pause messages to second node 354. The pause message can generally be any message that causes the receiving node to pause sending messages for a specified duration to the node that sent the pause message. By setting the duration of the pause messages to a very short interval, first node 352 can throttle down the amount of traffic it receives from second node 354, thereby alleviating the congestion in queue 356. In one embodiment, a pause message can be an Ethernet “PAUSE” frame.

[0080] FIG. 5 illustrates how a node may determine whether to delay a message in accordance with an embodiment of the present invention.

[0081] In one embodiment, a node may use a routing table or a forwarding table to determine whether to delay a message. For example, node 354 may use routing table 502 to determine whether to delay a message. Routing table 502 may include fields such as, egress port field 504, congestion-point identifier field 506, delay amount field 508, and hop field 510. Routing table 502 may also include an empty flag 512 which indicates whether delay queue 370 contains a message that is to be routed through the egress port specified in the egress port field 504. Note that routing table 502 may include other fields (not shown) which may help node 354 to determine how to route messages through the network. Routing table 502 has been presented only for purposes of illustration and description, and is not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations of routing table 502 will be apparent to practitioners skilled in the art. In general, a routing table contains information that enables a node to determine how to route messages through a network. A routing table can be implemented using hardware, or software, or a combination thereof.

[0082] Node 354 may receive messages 514, wherein each message may contain a destination address 516. Node 354 may use destination address 516 and routing table 502 to determine whether to delay the message or not (step 518).

[0083] In one embodiment, node 354 may determine an egress port for a message using the message's destination address 516. Further, node 354 may use destination address 516 to determine whether the message is expected to be routed through a specific queue in a downstream node.

[0084] For example, node 354 may use the destination address to determine that a message will be routed through port 362 and through queue 356. Next, node 354 may use the egress port field 504 and congestion-point identifier field 506 to identify a row in routing table 502 that matches port 362 and queue 356. Node 354 may then use the delay field 508, hop field 510, and the empty flag 512 to determine whether to queue the message in delay queue 370.

[0085] Specifically, node 354 may queue the message in delay queue 370 if (a) the delay timer specified in the delay field 508 has not expired, and the number of hops from node 354 to the node that contains the queue associated with the congestion-point identifier is less than the number of hops specified in the hop field 510, or (b) the delay timer specified in the delay field 508 has expired, but the empty flag 512 indicates that delay queue 370 contains a message that is expected to be routed through the queue associated with the congestion-point identifier.

[0086] On the other hand, if the node determines not to delay the message, the node may send the message to an egress port. For example, node 354 may send the message to egress port 360.

[0087] The delay amount can be specified in the control message. In one embodiment, the delay amount can be determined during onset detection. Specifically, when the system detects an onset of congestion, it can also determine the delay required to combat the congestion. In one embodiment, the system can learn the parameters which indicate an onset of congestion. The system can also learn the duration of the burst and learn an optimal delay using these parameters. Alternatively, a system administrator may also set the delay amount.

[0088] Once the delay timer expires, an embodiment may transmit messages at a lower rate from the delay queue. For example, in one embodiment, the system may rearrange the messages in the delay queue so that the system alternately sends messages associated with a first congestion-point identifier and a second congestion-point identifier.

[0089] In one embodiment, once node 352 detects an onset of congestion in queue 356, it may delay message in a delay queue (not shown) at node 352. Node 352 may generate a control message only if the number of messages in the delay queue rises above a certain threshold. In a shared memory switch, this technique may not be very useful. However, in a non-shared-memory switch (e.g., a cross-bar switch), this technique may be useful because it may allow the output queues in the non-shared-memory switch to share the delay queue to store overflow messages.

[0090] FIG. 6A presents a flowchart that illustrates a process for avoiding network congestion by propagating a control message through the network in accordance with an embodiment of the present invention.

[0091] FIG. 6B illustrates how a control message can be propagated through the network in accordance with an embodiment of the present invention.

[0092] The process can begin when a second node receives a first control message (step 602). For example, second node 354 may receive a first control message from first node 352. Note that the first control message may contain a congestion-point identifier which indicates that an onset of congestion was detected in queue 356.

[0093] Next, the second node may generate a second control message (step 604). The second control message may contain information from the first control message. Specifically, the second control message may contain the congestion-point identifier associated with queue 356. Further, if the control messages include a hop count, the second node may decrement the hop count.

[0094] The second node may then send the second control message to a third node (step 606). For example, second node 354 may send the second control message to third node 652 through link 654. Note that link 654 couples second node 354 with third node 652. In one embodiment, second node 354 may send the second control message to third node 652 only if the hop count of the second control message is greater than zero.

[0095] Next, the third node may receive the second control message (step 608). For example, third node 652 may receive the second control message from second node 354 via link 654.

[0096] The third node may then receive a fourth message (step 610). For example, third node 652 may receive the fourth message on port 658. The second control message may enable third node 652 to determine whether the fourth message is expected to be routed through queue 356 at first node 352.

[0097] Next, the third node can use the information contained in the second control-message to determine whether to delay the fourth message (step 612).

[0098] If the third node determines that the fourth message is to be delayed, it can delay the fourth message by queuing the fourth message in a delay queue at the third node (step 614). For example, third node 652 can delay the fourth message by queuing the fourth message in delay queue 670.

[0099] On the other hand, if the third node determines that the fourth message is not to be delayed, it can send the fourth message to the appropriate egress port (step 616). For example, third node 652 can send the fourth message to egress port 656.

[0100] In one embodiment, the first node can send a routing-information message to the second node, which can enable the second node to determine whether a message is expected to be routed through the first queue at the first node. Further, the second node can send a routing-information message to the third node, which can enable the third node to determine whether a message is expected to be routed through the first queue at the first node. In one embodiment, a routing-information message may include one or more congestion-point identifiers.

[0101] The first node may send the routing-information message to the second node on a periodic basis. Alternatively, the first node may send the routing-information message to the second node in response to a request from the second node. Specifically, the second node may receive a control message that contains a congestion-point identifier. Next, the second node may send a routing-information request to the first node to request information that will enable the second node to determine whether a message is expected to be routed through the queue associated with the congestion-point identifier. In response to the request message, the first node may send a routing-information message to the second node.

[0102] The routing-information message may include a list of address prefixes, wherein a message is expected to be routed through the queue associated with the congestion-point identifier if and only if the message's destination address matches an address prefix in the list of address prefixes.

[0103] In one embodiment, the routing information can be piggybacked with an existing routing protocol. In a distance-vector routing protocol, a node usually receives routing tables from its immediate neighbors. Hence, additional information about the routing tables of other nodes may need to be sent. However, in link-state routing protocols, the topology of the entire network may be available at each node. Hence, additional routing-information may not need to be exchanged. Specifically, once a node knows which link is congested, it may be able to use the network topology to determine which messages are expected to be routed through the congested link.

[0104] FIG. 7 illustrates how a control message can be propagated through the network in accordance with an embodiment of the present invention.

[0105] Network 700 comprises nodes 702, 704, 706, 708, 710, 712, and 714. Node 702 is coupled with nodes 704, 706, and 708; node 706 is coupled with nodes 712 and 714; and node 704 is coupled with node 710.

[0106] A node may send a control message to only some of its neighbors. For example, even though node 702 is coupled with node 708, node 702 may not send a control message to node 708.

[0107] In one embodiment, a node may send a control message to a neighboring node only if the node has received a message from a neighboring node that is expected to be routed through a congested downstream queue. For example, node 702 may detect an onset of congestion in a queue. Next, node 702 may determine that the queue contains messages that were received from nodes 704 and 706, but does not contain any messages that were received from node 708. Hence, node 702 may send control messages to nodes 704 and 706, but not to node 708.

[0108] In another embodiment, node 702 may send control messages to all neighboring nodes regardless of whether the congested queue contains a message from the neighboring nodes.

[0109] The number of hops that a control message is propagated may depend on the size of the queues and the duration of the traffic bursts. If the queues are large and the traffic bursts are short, the control messages may only need to be propagated one hop. On the other hand, if the queues are short and the traffic bursts are long, the congestion messages may need to be propagated for more than one hop. At one extreme, the system can inform all upstream nodes about an onset of congestion.

[0110] In one embodiment, control messages are propagated through the network using a high priority or a guaranteed path. This can ensure that control messages are quickly propagated through the network even if the network is heavily congested. Further, in one embodiment, messages held in delay queues are “unfrozen” in a staggered fashion in inverse order of the control message propagation. That is, messages nearest to the congestion point may resume before messages that are farther away.

[0111] The above techniques for propagating control messages have been presented only for purposes of illustration and description, and are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art.

[0112] In one scenario, node 702 may send control messages to nodes 704 and 708 to indicate that it has detected an onset of congestion in a queue. Upon receiving the control message from node 702, node 706 may send control message to nodes 712 and 714. Similarly, upon receiving the control message from node 702, node 704 may send a control message to node 710. Further, nodes 710, 712, and 714 may send further control messages to their neighbors (not shown).

[0113] Note that the propagation of the control message can be viewed as a propagating wavefront as shown in FIG. 7. Wavefront 1 comprises the control messages that are sent by node 702. Wavefront 2 comprises the control messages that are sent by nodes 704 and 706. Wavefront 3 comprises the control messages that are sent by nodes 710, 712, and 714. Note that the control message may reach the source. Further, queues in the destination node typically do not congest because we assume that the destination node can handle data at the line rate.

[0114] The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.