Source: http://patents.com/us-7016971.html
Timestamp: 2019-01-19 13:02:50
Document Index: 170405401

Matched Legal Cases: ['arts 0', 'art 0', 'art 1', 'art 1', 'art 2', 'art 3']

US Patent # 7,016,971. Congestion management in a distributed computer system multiplying current variable injection rate with a constant to set new variable injection rate at source node - Patents.com
United States Patent 7,016,971
Recio , et al. March 21, 2006
Inventors: Recio; Renato J. (Austin, TX), Garcia; David J. (Los Gatos, CA), Krause; Michael R. (Boulder Creek, CA), Thaler; Patricia A. (Carmichael, CA), Krause; John C. (Georgetown, TX)
Appl. No.: 09/980,760
PCT Filed: May 24, 2000
PCT No.: PCT/US00/14294
371(c)(1),(2),(4) Date: April 15, 2002
PCT Pub. No.: WO00/72169
PCT Pub. Date: November 30, 2000
60135664 May., 1999
60154150 Sep., 1999
Current U.S. Class: 709/233 ; 709/234
Field of Search: 709/232-235,8,237 370/232,231
4475192 October 1984 Fernow et al.
5063562 November 1991 Barzilai et al.
5193151 March 1993 Jain
5506964 April 1996 Beukema
5701292 December 1997 Chiussi et al.
5734653 March 1998 Hiraiwa et al.
5802051 September 1998 Petersen et al.
5802295 September 1998 Fukui et al.
5812527 September 1998 Kline et al.
6026448 February 2000 Goldrian et al.
6088736 July 2000 Manning et al.
6286052 September 2001 McCloghrie et al.
6434624 August 2002 Gai et al.
Brakmo, Lawrence S. et al., "TCP Vegas: End to End Congestion Avoidance on a Global Internet," IEEE Journal on Selected Areas in Communications, vol. 13, No. 8, pp. 1465-1480 (Oct. 1995). cited by other .
Cisco Systems, Inc., "Optimizing Your Network Design," Macmillan Publishing USA, pp. 1-23, (1999). <www.cisco.com>. cited by other .
Elloumi, Omar et al., "Improving Congestion Avoidance Algorithms for Asymmetric Networks," IEEE, pp. 1417-1421 (1997). cited by other .
Henderson, Thomas R. et al., "On Improving the Fairness of TCP Congestion Avoidance," IEEE, pp. 539-544 (1998). cited by other .
IBM Corp., "Direct Memory Access Tag Architecture," IBM Technical Disclosure Bulletin, vol. 32, No 4B, pp. 143-151 (Sep. 1989). cited by other .
Kim, Jin-Ho et al., "TCP Deadlock Due to Coarse Timer Granularities in Unix-Based Systems," Electronic Letters, vol. 35, No. 14, (Jul. 8, 1999). cited by other .
Misra, Archan et al., "The Window Distribution of Idealized TCP Congestion Avoidance with Variable Packet Loss," IEEE, pp. 1564-1572 (1999). cited by other .
Moldeklev, Kjersti et al., "How a Large ATM MTU Causes Deadlocks in TCP Data Transfers," IEEE/ACM Transactions on Networking, vol. 3, No. 4, pp. 409-422 (Aug. 1995). cited by other .
Parsa, Christina et al., "Improving TCP Congestion Control over Internets with Hetergeneous Transmission Media," IEEE Computer Society, Seventh International Conference on Network Protocols (ICNP'99), pp. 213-221 (Oct. 31-Nov. 3, 1999). cited by other .
Ren, Jing-Fei et al., "Flow Control and Congestion Avoidance in Switched Ethernet LANs," IEEE, pp. 508-512 (1997). cited by other .
Rohrs, Charles E. et al., "A Control Engineer's Look at ATM Congestion Avoidance," IEEE, pp. 1089-1094 (1995). cited by other .
Rosenberg, Jonathan et al., "Timer Reconsideration for Enhanced RTP Scalability," IEEE, pp. 233-241 (1998). cited by other .
"Congestion Avoidance Overview," pp. QC-69-QC76. cited by other .
"Weighted Random Early Detection on the Cisco 12000 Series Router," pp. 1-26. cited by other.
1. A distributed computer system comprising: links; and end stations coupled between the links, wherein types of end stations include endnodes which originate or consume frames and routing devices which route frames between the links and do not originate or consume frames, wherein the end stations include a first source endnode which originates frames at a variable injection rate, wherein the first source endnode includes: a congestion control mechanism responding to detected congestion by multiplicatively decreasing the variable injection rate, wherein the variable injection rate (IR) is multiplicatively decreased according to IR(i+1)=IR(i)*1/F1, wherein F1 is a constant, wherein IR(i) is equal to a previous variable injection rate and IR(i+1) is equal to a new variable injection rate.
4. The distributed computer system of claim 1 wherein the end stations include a first destination endnode which consumes frames originated from the first source endnode, wherein the first destination endnode includes: a congestion control mechanism detecting congestion on a path the frames route from the first source endnode to the first destination endnode.
8. The distributed computer system of claim 1 wherein at least one routing device includes: a congestion control mechanism detecting congestion on a path the frames route through the at least one routing device.
10. Previously Presented) The distributed computer system of claim 1 wherein at least one routing device includes: a congestion control mechanism responding to detected congestion by dropping frames that are marked droppable for a time period.
11. The distributed computer system of claim 1 wherein at least one routing device includes: a congestion control mechanism responding to detected congestion by applying link back pressure by reducing a number of credits available for routing frames though the routing device from a link.
12. A method of controlling congestion in a distributed computer system having links and end stations coupled between the links, wherein types of end stations include endnodes which originate or consume frames and routing devices which route frames between the links and do not originate or consume frames, the method comprising: originating, from a first source endnode, frames at a variable injection rate; detecting congestion; and multiplicatively decreasing the variable injection rate in response to the detected congestion including multiplicatively decreasing the variable injection rate (IR) according to IR(i+1)=IR(i)*1/F1, wherein F1 is a constant, wherein IR(i) is equal to a previous variable injection rate and IR(i+1) is equal to a new variable injection rate.
13. The method of claim 12 further comprising detecting subsiding of congestion; and multiplicatively increasing the variable injection rate in response to the detected subsiding of congestion.
15. The method of claim 12 further comprising: consuming, at a first destination endnode, frames originated from the first source endnode; and detecting congestion on a path the frames route from the first source endnode to the first destination endnode.
16. The method of claim 15 wherein the detecting congestion on the path the frames route from the first source endnode to the first destination endnode includes detecting congestion based on Forward Explicit Congestion Notification (FECN) conditions, and the method further comprises: forwarding the FECN conditions to the first source endnode.
17. The method of claim 12 further comprising: consuming; at a first destination endnode, frames originated from the first source endnode; and detecting congestion on a path the frames route from the first source endnode to the first destination endnode by monitoring a previous variable injection rate and a round trip time for a frame to reach the first destination endnode and an acknowledgement (ACK) for the frame from the first destination endnode to reach the first source endnode.
19. The method of claim 12 further comprising: detecting congestion on a path the frames route through the at least one routing device.
21. The method of claim 12 further comprising: dropping frames that are marked droppable for a time period in response to the detected congestion.
22. The method of claim 12 further comprising: applying link back pressure by reducing a number of credits available for routing frames though the routing device from a link in response to the detected congestion.
23. A distributed computer system comprising: links; and end stations coupled between the links, wherein types of end stations include endnodes which originate or consume frames and routing devices which route frames between the links and do not originate or consume frames, wherein the end stations include a first source endnode which originates frames at a variable injection rate, wherein at least one routing device includes a congestion control mechanism responding to detected congestion by dropping frames that are marked droppable for a time period, and wherein the first source endnode includes: a congestion control mechanism responding to detected congestion by multiplicatively decreasing the variable injection rate and responding to detected subsiding of congestion by multiplicatively increasing the variable injection rate, wherein the variable injection rate (IR) is multiplicatively decreased according to IR(i+1)=IR(i)*1/F1, wherein F1 is a constant, wherein the variable injection rate (IR) is multiplicatively increased according to IR(i+1)=IR(i)*F2, wherein F2 is a constant, wherein IR(i) is equal to a previous variable injection rate and IR(i+1) is equal to a new variable injection rate.
Distributed computer system 30 includes a system area network (SAN) 32 which is a high-bandwidth, low-latency network interconnecting nodes within distributed computer system 30. A node is herein defined to be any device attached to one or more links of a network and forming the origin and/or destination of messages within the network. In the example distributed computer system 30, nodes include host processors 34a 34d; redundant array independent disk (RAID) subsystem 33; and I/O adapters 35a and 35b. The nodes illustrated in FIG. 1 are for illustrative purposes only, as SAN 32 can connect any number and any type of independent processor nodes, I/O adapter nodes, and I/O device nodes. Any one of the nodes can function as an endnode, which is herein defined to be a device that originates or finally consumes messages or frames in the distributed computer system.
In distributed computer system 30, host processor nodes 34a 34d and RAID subsystem node 33 include at least one system area network interface controller (SANIC) 42. In one embodiment, each SANIC 42 is an endpoint that implements the SAN 32 interface in sufficient detail to source or sink frames transmitted on the SAN fabric. The SANICs 42 provide an interface to the host processors and I/O devices. In one embodiment the SANIC is implemented in hardware. In this SANIC hardware implementation, the SANIC hardware offloads much of CPU and I/O adapter communication overhead. This hardware implementation of the SANIC also permits multiple concurrent communications over a switched network without the traditional overhead associated with communicating protocols. In one embodiment, SAN 32 provides the I/O and IPC clients of distributed computer system 30 zero processor-copy data transfers without involving the operating system kernel process, and employs hardware to provide reliable, fault tolerant communications.
The host processors 34a 34d include central processing units (CPUs) 44 and memory 46.
I/O adapters 35a and 35b include an I/O adapter backplane 48 and multiple I/O adapter cards 50. Example adapter cards 50 illustrated in FIG. 1 include an SCSI adapter card; an adapter card to fiber channel hub and FC-AL devices; an Ethernet adapter card; and a graphics adapter card. Any known type of adapter card can be implemented. I/O adapters 35a and 35b also include a switch 36 in the I/O adapter backplane 48 to couple the adapter cards 50 to the SAN 32 fabric.
Channel semantics and memory semantics are typically both necessary for I/O and IPC. A typical I/O operation employs a combination of channel and memory semantics. In an illustrative example I/O operation of distributed computer system 30, host processor 34a initiates an I/O operation by using channel semantics to send a disk write command to I/O adapter 35b. I/O adapter 35b examines the command and uses memory semantics to read the data buffer directly from the memory space of host processor 34a. After the data buffer is read, I/O adapter 35b employs channel semantics to push an I/O completion message back to host processor 34a.
An example host processor node 34 is generally illustrated in FIG. 2. Host processor node 34 includes a process A indicated at 60 and a process B indicated at 62. Host processor node 34 includes SANIC 42. Host processor node 34 also includes queue pairs (QP's) 64a and 64b which provide communication between process 60 and SANIC 42. Host processor node 34 also includes QP 64c which provides communication between process 62 and SANIC 42. A single SANIC, such as SANIC 42 in a host processor 34, can support thousands of QPs. By contrast, a SAN interface in an I/O adapter 35 typically supports less than ten QPs.
Host processor node 34 also includes completion queue 70a interfacing with process 60 and completion queue 70b interfacing with process 62. The completion queues 70 contain information about completed WQEs. The completion queues are employed to create a single point of completion notification for multiple QPs. A completion queue entry is a data structure on a completion queue 70 that describes a completed WQE. The completion queue entry contains sufficient information to determine the QP that holds the completed WQE. A completion queue context is a block of information that contains pointers to, length, and other information needed to manage the individual completion queues.
Host processor node 102 includes a QP 116 having a send work queue 116a and a receive work queue 116b; a QP 118 having a send work queue 118a and receive work queue 118b; and a QP 120 having a send work queue 120a and a receive work queue 120b which facilitate communication to and from process A indicated at 108. Host processor node 104 includes a QP 122 having a send work queue 122a and receive work queue 122b for facilitating communication to and from process B indicated at 110. Host processor node 104 includes a QP 124 having a send work queue 124a and receive work queue 124b for facilitating communication to and from process C indicated at 112. Host processor node 106 includes a QP 126 having a send work queue 126a and receive work queue 126b for facilitating communication to and from process D indicated at 114.
The reliable connection service of distributed computer system 100 associates a local QP with one and only one remote QP. Thus, QP 116 is connected to QP 122 via a non-sharable resource connection 128 having a non-sharable resource connection 128a from send work queue 116a to receive work queue 122b and a non-sharable resource connection 128b from send work queue 122a to receive work queue 116b. QP 118 is connected to QP 124 via a non-sharable resource connection 130 having a non-sharable resource connection 130a from send work queue 118a to receive work queue 124b and a non-sharable resource connection 130b from send work queue 124a to receive work queue 118b. QP 120 is connected to QP 126 via a non-sharable resource connection 132 having a non-sharable resource connection 132a from send work queue 120a to receive work queue 126b and a non-sharable resource connection 132b from send work queue 126a to receive work queue 120b.
The reliable connection service requires a process to create a QP for each process which is to communicate with over the SAN fabric. Thus, if each of N host processor nodes contain M processes, and all M processes on each node wish to communicate with all the processes on all the other nodes, each host processor node requires M.sup.2.times.(N-1) QPs. Moreover, a process can connect a QP to another QP on the same SANIC.
Host processor node 152 includes QP 166 having send work queue 166a and receive work queue 166b for facilitating communication to and from process A indicated at 158. Host processor node 154 includes QP 168 having send work queue 168a and receive work queue 168b for facilitating communication from and to process B indicated at 160. Host processor node 154 includes QP 170 having send work queue 170a and receive work queue 170b for facilitating communication from and to process C indicated at 162. Host processor node 156 includes QP 172 having send work queue 172a and receive work queue 172b for facilitating communication from and to process D indicated at 164. In the reliable datagram service implemented in distributed computer system 150, the QPs are coupled in what is referred to as a connectionless transport service.
For example, a reliable datagram service 174 couples QP 166 to QPs 168, 170, and 172. Specifically, reliable datagram service 174 couples send work queue 166a to receive work queues 168b, 170b, and 172b. Reliable datagram service 174 also couples send work queues 168a, 170a, and 172a to receive work queue 166b.
The reliable datagram service greatly improves scalability because the reliable datagram service is connectionless. Therefore, an endnode with a fixed number of QPs can communicate with far more processes and endnodes with a reliable datagram service than with a reliable connection transport service. For example, if each of N host processor nodes contain M processes, and all M processes on each node wish to communicate with all the processes on all the other nodes, the reliable connection service requires M.sup.2.times.(N.times.1) QPs on each node. By comparison, the connectionless reliable datagram service only requires M QPs+(N-1) EE contexts on each node for exactly the same communications.
An example host processor node is generally illustrated at 200 in FIG. 5. Host processor node 200 includes a process A indicated at 202, a process B indicated at 204, and a process C indicated at 206. Host processor 200 includes a SANIC 208 and a SANIC 210. As discussed above, a host processor endnode or an I/O adapter endnode can have one or more SANICs. SANIC 208 includes a SAN link level engine (LLE) 216 for communicating with SAN fabric 224 via link 217 and an LLE 218 for communicating with SAN fabric 224 via link 219. SANIC 210 includes an LLE 220 for communicating with SAN fabric 224 via link 221 and an LLE 222 for communicating with SAN fabric 224 via link 223. SANIC 208 communicates with process A indicated at 202 via QPs 212a and 212b. SANIC 208 communicates with process B indicated at 204 via QPs 212c 212n. Thus, SANIC 208 includes N QPs for communicating with processes A and B. SANIC 210 includes QPs 214a and 214b for communicating with process B indicated at 204. SANIC 210 includes QPs 214c 214n for communicating with process C indicated at 206. Thus, SANIC 210 includes N QPs for communicating with processes B and C.
A portion of a distributed computer system is generally illustrated at 250 in FIG. 6. Distributed computer system 250 includes a subnet A indicated at 252 and a subnet B indicated at 254. Subnet A indicated at 252 includes a host processor node 256 and a host processor node 258. Subnet B indicated at 254 includes a host processor node 260 and host processor node 262. Subnet A indicated at 252 includes switches 264a 264c. Subnet B indicated at 254 includes switches 266a 266c. Each subnet within distributed computer system 250 is connected to other subnets with routers. For example, subnet A indicated at 252 includes routers 268a and 268b which are coupled to routers 270a and 270b of subnet B indicated at 254. In one example embodiment, a subnet has up to 2.sup.16 endnodes, switches, and routers.
An example embodiment of a switch is generally illustrated at 280 in FIG. 7. Each I/O path on a switch or router has an LLE. For example, switch 280 includes LLEs 282a 282h for communicating respectively with links 284a 284h.
In the example transactions, host processor node 302 includes a client process A indicated at 320. Host processor node 304 includes a client process B indicated at 322. Client process 320 interacts with SANIC hardware 306 through QP 324. Client process 322 interacts with SANIC hardware 308 through QP 326. QP 324 and 326 are software data structures. QP 324 includes send work queue 324a and receive work queue 324b. QP 326 includes send work queue 326a and receive work queue 326b.
Process 320 initiates a message request by posting WQEs to send queue 324a. Such a WQE is illustrated at 330 in FIG. 9A. The message request of client process 320 is referenced by a gather list 332 contained in send WQE 330. Each entry in gather list 332 points to a virtually contiguous buffer in the local memory space containing a part of the message, such as indicated by virtual contiguous buffers 334a 334d, which respectively hold message 0, parts 0, 1, 2, and 3.
Referring to FIG. 9B, hardware in SANIC 306 reads WQE 330 and packetizes the message stored in virtual contiguous buffers 334a 334d into frames and flits. As illustrated in FIG. 9B, all of message 0, part 0 and a portion of message 0, part 1 are packetized into frame 0, indicated at 336a. The rest of message 0, part 1 and all of message 0, part 2, and all of message 0, part 3 are packetized into frame 1, indicated at 336b. Frame 0 indicated at 336a includes network header 338a and transport header 340a. Frame 1 indicated at 336b includes network header 338b and transport header 340b.
As indicated in FIG. 9B, frame 0 indicated at 336a is partitioned into flits 0 3, indicated respectively at 342a 342d. Frame 1 indicated at 336b is partitioned into flits 4 7 indicated respectively at 342e 342h. Flits 342a through 342h respectively include flit headers 344a 344h.
Frames are routed through the SAN fabric, and for reliable transfer services, are acknowledged by the final destination endnode. If not successively acknowledged, the frame is retransmitted by the source endnode. Frames are generated by source endnodes and consumed by destination endnodes. The switches and routers in the SAN fabric neither generate nor consume frames.
Referring to FIG. 10A, the send request message 0 is transmitted from SANIC 306 in host processor node 302 to SANIC 308 in host processor node 304 as frames 0 indicated at 336a and frame 1 indicated at 336b. ACK frames 346a and 346b, corresponding respectively to request frames 336a and 336b, are transmitted from SANIC 308 in host processor node 304 to SANIC 306 in host processor node 302.
As illustrated in FIG. 10B, flits 342a h are transmitted from SANIC 306 to switch 310. Switch 310 consumes flits 342a h at its input port, creates flits 348a h at its output port corresponding to flits 342a h, and transmits flits 348a h to switch 312. Switch 312 consumes flits 348a h at its input port, creates flits 350a h at its output port corresponding to flits 348a h, and transmits flits 350a h to SANIC 308. SANIC 308 consumes flits 350a h at its input port. An acknowledgment flit is transmitted from switch 310 to SANIC 306 to acknowledge the receipt of flits 342a h. An acknowledgment flit 354 is transmitted from switch 312 to switch 310 to acknowledge the receipt of flits 348a h. An acknowledgment flit 356 is transmitted from SANIC 308 to switch 312 to acknowledge the receipt of flits 350a h.
Acknowledgment frame 346a fits inside of flit 358 which is transmitted from SANIC 308 to switch 312. Switch 312 consumes flits 358 at its input port, creates flit 360 corresponding to flit 358 at its output port, and transmits flit 360 to switch 310. Switch 310 consumes flit 360 at its input port, creates flit 362 corresponding to flit 360 at its output port, and transmits flit 362 to SANIC 306. SANIC 306 consumes flit 362 at its input port. Similarly, SANIC 308 transmits acknowledgment frame 346b in flit 364 to switch 312. Switch 312 creates flit 366 corresponding to flit 364, and transmits flit 366 to switch 310. Switch 310 creates flit 368 corresponding to flit 366, and transmits flit 368 to SANIC 306.
Under this approach, the injection rate (i.e., bytes per second) is adjusted by monitoring the previous injection rate and the cycle time of frames within the network. The cycle time calculation needs to be made on the basis of the round trip time between a frame and it's corresponding ACK. The cycle time calculation cannot be made based on the time gap between ACKs, because the source may not always have frames to send and compensating for the frame sending time gap is not possible. If the source's frame injection rate is not continuous (i.e., the sources' send rate has time gaps), then those time gaps need to be accounted for in a cycle time calculation that strictly looks at time gaps between ACKs. This compensation becomes very problematic. Let's say, the source calculates the time delay caused by the congested switch stage by calculating the time gap between incoming frame ACKs. For example, the ACK for frame 1 was received at time A and the ACK for frame 2 was received at time B, so that time gap would be B-A. This approach would correctly reflect the time gap caused by the congested stage, so long as the source injection rate has no time gaps. However, if the source's frame injection rate also has a tie gap, then the time gap would have to be compensated for by calculating the time gap between frame sends. For example frame sequence number 1 was sent at time X, frame sequence number 2 was sent at time Y the time gap would be Y-Z. Unfortunately, the frame injection time (Y-X) cannot be easily removed from the time gap caused by the congested state (B-A), because the (B-A-Y-X) calculation would not longer just reflect the effect of the congested stage. This assumption is invalid for SAN traffic. The way this approach works is as follows.
One standard approach is to maintain two counters per QP: FECN0 and FECN1. FECN0 counts the number of ACK/NAKs received with a zero FECNCount. FECN1 accumulates FECNCount(s) received from ACK/NAKs. The counts are accumulated over a time period FECN_Time of 4.times. static end--end RTT. If FECN1>=FECN0 over FECN_Time, then set the max QP injection rate to half (often percentage values can be used, such as 0.875). The previous max QP injection rate to twice the previous max QP injection rate FN two more bits and one more timer can be implemented to dampen and settle down the injection rate oscillations. This basically uses aggressive QP injection rate acceleration, which can cause larger fluctuations in traffic, but also aggressively removes congestion. For a SAN, where the large fluctuations may impact performance, a more reasonable approach seems to be to modify the max QP injection rate more linearly, say by reducing max QP injection rates at 85% under congestion and increasing max QP injection rates at 1.15% when congestion subsides.
This approach requires the following state per VL at the source's scheduler: FECN0 accumulates the number of frames with no congestion. FECN1 accumulates the FECN count FECN_Time counts down to zero. When it pops FECN 0 and FECN1 are compared. Increment Injection Rate when set its used to increment the injection rate.
Decrement Injection Rate when set decrements the injection rate.
The switch will continue to drop frames marked droppable for a time period of 2.times. the NormalCongestionTimer. This provides weighted fairness (a NormalCongestionTime period) for droppable frames. The switch will then rest the NC_state and restart the NormalCongestionTime timer.
Detection: Switch--Detects congestion by analyzing receive and send port resources as stated earlier. Source--Detects congestion reported by analyzing the FECNCount field in the frame transport header as stated earlier. Destination--Detects congestion reported by analyzing the FECNCount field in the frame transport header as stated earlier.
Reporting: Switch--Propagates the FECNCount field in the flit delimiters as stated earlier. Routers--When a flit has non-zero FECNCount field, sends a No-Op frame to the flit source with the FECNCount field equal to the highest FECNCount of the flits associated with the frame. Destination--Sets the ACK/NAK FECNCount field equal to the highest FECNCount of the flits associated with the frame.
Switch--Drops frames when NormalCongestion is encountered as stated earlier.
Source--Lowers injection rate based on FECNCount as described earlier.
Scenario 1--Singleton Host tree with Adapter Leaves.
Use implicit congestion detection by means of Frame-to-ACK timing and use slow-start and multiplicative decrease to respond to congestion. (FN--This is a derivative of TCP Vegas).
Just using link level back-pressure alone by reducing the number of credits available to the host is not very efficient, because the host cannot determine which flows are under end--end back pressure and which flows are not. Again, this will cause all switch A flows to operate at a sub-optimal point in the uncongested region.
If host A's scheduler provides weighted fair schedule queuing that compensates for only static link bandwidth differences, then host A will adjust the injection rate so as to not exceed the lowest link bandwidth rate. For example, the injection rate for host A to adapter B flow would be set to a maximum of the low bandwidth rate; and the injection rate for host A to adapter A flow would be set to a maximum of the high bandwidth rate. This approach would work fine, as long as the configuration is kept to singleton host tree with no peer--peer adapter transfers and no routers. However, scenario 2 and 3 will describe how static flow control is insufficient for a singleton host tree that contains routers or adapters performing peer--peer operations.
For a simple tree network, with no peer--peer and no routers into the internet, dynamic injection rate control using either of the two methods described above will keep the network operating near the optimal point of the uncongested region on average, with intermediate periods of normal congestion.
For a simple tree network, with no peer--peer and no routers into the internet, static injection rate control (i.e. host A's scheduler provides weighted fair schedule queuing that compensates for link bandwidth differences) is also effective at keeping network operation near the optimal point in the uncongested region. However, the next two scenarios will describe why static injection control alone is not effective at keeping network congestion near the optimal point, if this simple singleton host network includes peer--peer and routers into the internet.
Scenario 2--Singleton Host Tree with Peer--Peer Adapter Leaves
This scenario simply adds peer--peer adapter transfers to the configuration depicted in scenario 1.
Just using link level back-pressure alone by reducing the number of credits available to the host is not very efficient, because the host cannot determine which flows are under end--end back-pressure and which flows are not. Again, this will cause all switch A flows to operate at a sub-optimal point in the uncongested region.
Scenario 3--Singleton Host Tree with Adapter and Router Leaves.
Previous Patent US 7,016,970 | Next Patent US 7,016,972