Source: https://patents.google.com/patent/US20010032269A1/en
Timestamp: 2018-04-23 21:58:35
Document Index: 494864067

Matched Legal Cases: ['art 200', 'art 200', 'art 204', 'art 216', 'art 210', 'art 210']

US20010032269A1 - Congestion control for internet protocol storage - Google Patents
Congestion control for internet protocol storage Download PDF
US20010032269A1
US20010032269A1 US09726676 US72667600A US2001032269A1 US 20010032269 A1 US20010032269 A1 US 20010032269A1 US 09726676 US09726676 US 09726676 US 72667600 A US72667600 A US 72667600A US 2001032269 A1 US2001032269 A1 US 2001032269A1
US09726676
US7058723B2 (en )
A network system for actively controlling congestion to optimize throughput is provided. The network system includes a sending host which is configured to send packet traffic at a set rate. The network system also includes a sending switch for receiving the packet traffic. The sending switch includes an input buffer for receiving the packet traffic at the set rate where the input buffer is actively monitored to ascertain a capacity level. The sending switch also includes code for setting a probability factor that is correlated to the capacity level where the probability factor increases as the capacity level increases and decreases as the capacity level decreases. The sending switch also has code for randomly generating a value where the value is indicative of whether packets being sent by the sending switch are to be marked with a congestion indicator. The sending switch also includes transmit code that forwards the packet traffic out of the sending switch where the packet traffic includes one of marked packets and unmarked packets. The network system also has a receiving end which is the recipient of the packet traffic and also generates acknowledgment packets back to the sending host where the acknowledgment packets are marked with the congestion indicator when receiving marked packets and are not marked with the congestion indicator when receiving unmarked packets. In another example, the sending host is configured to monitor the acknowledgment packets and to adjust the set rate based on whether the acknowledgment packets are marked with the congestion indicator. In a further example, the set rate is decreased every time one of the marked packets is detected and increased when no marked packets are detected per round trip time (PRTT).
Through use of the TCP, data that is sent over a network is broken up into little pieces for transmission and reassembled once the data reaches its destination. Data may be sent in the form such as, for example, data packets, etc. Depending on the interface used, the TCP may break down data into a variety of data packet sizes such as 128 byte packets. The TCP includes its own information which allows the data to be reattached in the correct order as well as resending any data that happens to get “dropped” (data that is lost due to various reasons such as congestion over the network). IP routes the data packaged by the TCP to a destination such as a device within a network.
TCP combines slow start and SSTHRESH by reducing CWND to 1 MTU, entering slow start when congestion is detected, and setting the SSTHRESH to 50% of the total number of packets in transport at the time the congestion is detected. Consequently, when congestion is detected, packet injection increases rapidly to 50% of the rate prior to congestion detection. The data transfer rate is reduced by a multiplicative fashion for fairness reasons so sending hosts taking up more of the throughput capacity is penalized more than sending hosts taking up less of the throughput capacity. For further details regarding the fairness concept in TCP data transfer, reference may be made to an article published in 1989 entitled, “Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Complex Networks” written by Dah-Ming Chiu and Raj Jain. This article is hereby incorporated by reference. Because slow start is utilized and CWND is reset to 1 MTU, the data transfer rate drops severely after congestion is detected even if congestion is not severe. Accordingly, this method does not allow the use of the full capacity of a transmission media or network while at the same time keeping congestion at a minimum.
One common way of detecting congestion over a network is by the use of a random early detection (RED) algorithm which finds potential congestion in the network and attempts to signal the congestion back to sending hosts. The algorithm signals congestion to the sending hosts before the input buffers of a switch are actually filled to slow down data transmission and leaves enough room in the buffers to accommodate a burst of packets without loss. Once congestion is detected by the sending host, it generally reduces its send window (the amount of packets sent during a certain period of time) by a half. Typically, the method used to signal congestion under this method is to “drop” data packets. This means that certain random data packets received by a switch are not sent. When data packets are dropped, the host sender does not receive ACKs (positive acknowledgement packets) indicating that the data packets were received. The dropping of packets forces a host sender to resend the packets that were dropped. The RED algorithm also calculates a running average of queue depth and signals congestion with increasing frequency as the average queue depth increases above a threshold. Therefore, possible congestion is detected before congestion can actually occur. As is obvious, this is a rather severe form of congestion reduction because data packets may be dropped even though congestion has not yet occurred.
[0015]FIG. 1B shows a graph illustrating a prior art method of packet marking congestion reduction. The graph depicts the relationships between packets sent per round trip time versus time. In this graph, the packets per round trip time is increased as long as there is no data congestion. In one example, data congestion occurs at peak 114 which is 16 packets per RTT. In this example, the packets per RTT of 16 is the maximum data transmission available. At that point, the sending host-1 102 decreases the packets per RTT by half to 8 as indicated by valley 116. As data transmission occurs and there is no congestion, the packets per RTT increases until peak 118 when congestion is detected by the sending host-1 102 where the packets per RTT is 12. When congestion is detected, the sending host-1 102 again decreases the packets per RTT by half to 6 as indicated by valley 120. When congestion is not detected, the packets per RTT is increased to 12 as shown by peak 122 where once again congestion is detected and the send window of packets per RTT is decreased by a half. As can be seen, with the severe peaks and valleys of data transmission rate, the effective transmission rate is not very high compared to the maximum transmission rate of 16 packets per RTT. In effect, the space above the curve depicted in FIG. 1B shows the unused transmission capacity by the present TCP. This “sawtooth” type curve shows the inefficiencies of the present forms of data congestion control. The present methods of congestion control therefore do a poor job of taking full advantage of the transmission capability of the transmission media used. Regrettably, the peak and average data transfer rate in these prior art systems are substantially less than the capabilities allowed within a network or most any data transfer system.
Broadly speaking, the present invention fills these needs by providing computer implemented methods for reducing of congestion in internet protocol storage.
[0024]FIG. 1A illustrates a simplified multiple TCP host data transfer system combining the RED algorithm and the data marking system.
[0025]FIG. 1B shows a graph illustrating a method of packet marking congestion reduction.
[0026]FIG. 2 shows a flowchart defining a process where congestion in internet protocol storage is reduced and data throughput is optimized in accordance with one embodiment of the present invention.
[0027]FIG. 3 shows a flowchart which illustrates the monitoring of the capacity of the input buffer within a sending switch and marking data packets according to how close the input buffer is to capacity in accordance with one embodiment of the present invention.
[0028]FIG. 4 shows a flowchart defining the method for adjusting a transfer rate of data packets in accordance with one embodiment of the present invention.
[0029]FIG. 5 shows a flowchart defining the generating of an ACK for the transferred data packet in accordance with one embodiment of the present invention.
[0030]FIG. 6 illustrates a graph showing a packet transfer optimizing scheme in accordance with one embodiment of the present invention.
[0031]FIG. 7 shows a graph of transport protocol performance of two different types of protocols in wire utilization for varying traffic loads in accordance with one embodiment of the present invention.
[0032]FIG. 8 shows a graph illustrating an average latency comparison of two different transport protocols in accordance with one embodiment of the present invention.
[0033]FIG. 9 shows a graph depicting maximum network latency experienced with TCP during the simulations in accordance with one embodiment of the present invention.
An invention is described for computer implemented methods for reducing congestion in data transfer systems and internet protocol storage. In addition, the described methods may be used to reduce congestion in any form of data transfer protocol. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
[0036]FIG. 2 shows a flowchart 200 defining a process where congestion in internet protocol storage is reduced and data throughput is optimized in accordance with one embodiment of the present invention. It should be understood that the processes depicted in the flowchart 200 may be in a program instruction form written on any type of computer readable media. For instance, the program instructions can be in the form of software code developed using any suitable type of programming language. The data transfer congestion reduction protocol may also be embodied in hardware form. For completeness, the process flow of FIG. 2 will illustrate an exemplary process whereby congestion in a data transfer system is reduced while optimizing data throughput.
Then the method moves to operation 210 where an ACK with information regarding the data packet is generated. The ACK (positive acknowledgement) is typically data that is sent from the receiving TCP host to the sending TCP host to notify the sending TCP host that certain data packets have been received. Generally, an ACK is sent for every data packet or every series of data packets to indicate that data was successfully received by the receiving host. If the sending host does not receive an ACK for a particular data packet in a set period of time, a “time out” occurs and the data packet not ACKed is resent. It should be appreciated that the ACK may be marked in any way which would show specific information regarding marked data packets. In one embodiment, if the data packet is marked, the receiving TCP host generates an ACK marked with the data congestion information within the ACK header. In another embodiment, a congestion control bit may be set in the ACK header to show that a particular data packet was marked. If the data packet is not marked, an unmarked ACK is generated. It should be appreciated that although the functionality of the congestion marking method is shown by marking and sending back an ACK for the received data packet, any other type of data congestion notification may be used such as, for example, utilizing a NAK (negative acknowledgement) in an STP to notify a host that certain data packets have not been received. When TCP is utilized, only ACKs are used while in STP both ACKs and NAKs may be employed to show dropped packets and data congestion.
[0049]FIG. 3 shows a flowchart 204 which illustrates the monitoring of the capacity of the input buffer within a sending switch and marking data packets according to how close the input buffer is to capacity in accordance with one embodiment of the present invention.
It should be understood that any way of utilizing probabilities may be used to determine if a certain packet with a particular probability will be marked. In one embodiment, if there is a 70% probability that the data packet will be marked (meaning the input buffer is 70% full), a random number generator may be utilized to establish whether the 70% probability to mark the data packet has been met. In such an embodiment, code within the switch may be utilized to create a random number (a value generated by, for example, a random number generator) within a range of 1-100. In this exemplary embodiment, if the random number generated is within a range of 1-70 (because there is a 70% chance that a random number between 1 and 100 will be between 1 and 70), the sending switch will mark the data packet. On the other hand, if the random number generated is within the range of 71-100, the data packet is not marked by the sending switch. In another exemplary embodiment, if the data packet has a 20% probability of being marked (meaning the input buffer is 20% filled), the code within the sending switch will determine that a random number generated within the range of 1-20 (20% probability) results in the sending switch marking the data packet. If the random number generated is within the range of 21-80, the sending switch does not mark the data packet. If operation 306 determines that the data packet is to be marked, the method moves to operation 308 where a data packet is marked with data indicating congestion. It should be appreciated that the data packet may be marked in any way to show data transfer congestion. In one embodiment, if the data packet is to be marked, operation 308 sets data in the IP header of the data packet (congestion indicator) showing that data congestion exists (e.g., that data is backing up in the input buffer because of data congestion). Therefore, later in the process, this marking enables a sending TCP host to determine data transfer congestion and therefore decrease the send window appropriately if congestion exists.
[0057]FIG. 4 shows a flowchart 216 defining the method for adjusting a transfer rate of data packets in accordance with one embodiment of the present invention. It should be understood that any type of protocol may be used with the present invention to powerfully adjust the data transfer rate such as, for example, STP which utilizes both ACKs and NAKs to determine the transfer rate.
In one embodiment, operation 410 decreases the data transfer rate (or send window) by one packet for each data packet shown to be marked by an ACK (or by the NAKs). It should be appreciated that any way of decreasing the data transfer rate may be employed as long as fairness principles are followed and data throughput is optimized. In this exemplary embodiment, the send window may be decreased by use of the equation SWt+1=(1−MR)*SWt where SWt is a send window at RTT interval “t”, and MR is a mark rate (fraction of packets marked while passing through a network). By use of this equation, the level of send window reduction directly correlates with the amount of data packet marking which shows data transfer congestion. Therefore, when congestion is detected, the send window shown in the equation by SWt is decreased by the product of SWt multiplied by the mark rate (MR). Accordingly, this means that the send window after congestion is detected (SWt+1) is the original send window (SWt) decreased by exactly the amount of marked packets (SWt*MR). This equation shows that fairness rules are being followed where data transfer is decreased at a multiplicative rate while data transfer increase is at an additive rate. Therefore, the method reduces data transmission in direct response to the actual amount of data congestion existing within a network or other data transfer device or system. It should be appreciated that other ways of determining send window reduction during congestion may be implemented so long as the data throughput capacity of the transmission media is optimized. As can be seen, by use of the congestion reduction protocol, the send window may be optimized to take advantage of the throughput capabilities of the transmission media without compromising data packet dropping reduction.
[0064]FIG. 5 shows a flowchart 210 defining the generating of an ACK for the transferred data packet in accordance with one embodiment of the present invention. Flowchart 210 begins with operation 502 which examines a data packet for marks in the IP header indicating data congestion in a sending switch. In one embodiment, the IP header of the data packet is examined to determine if data transmission congestion exists. It should be understood that data congestion information may be located in any part of the data packet, including, for example, in any non-header portion of the data packet.
[0068]FIG. 6 illustrates a graph showing a packet transfer optimizing scheme in accordance with one embodiment of the present invention. As data packets are sent from multiple sending TCP hosts to a sending switch, the number of packets sent are increased as long as no ACK's are marked per round trip time (PRTT) as discussed above in reference to FIGS. 2 and 4. In one embodiment, if a data packet is not marked during a round trip time then the rate of data packet transfer rate is increased by one data packet PRTT. Therefore, as shown in FIG. 6, the packets PRTT increases for every round trip time where no data packets are marked until peak 602 is reached. At peak 602, in one embodiment, data congestion takes place and the input buffer starts nearing capacity (high capacity level) with the acceptance of a data packet. At that point, the data packet is marked by a sending switch because of the high probability (i.e., probability factor) that the data packet will be marked. It should be understood that the data transfer system that experiences congestion may include one or more sending hosts, one or more switches, and one or more receiving hosts. Congestion may occur in the switch when too many senders send data to a receiving host. Congestion may also occur at the receiving host if it is not able to keep up with full wire speed delivery. In one embodiment, as discussed in reference to FIG. 2 above, when the congestion marking protocol is utilized in both the sending and receiving hosts, a target switch receives the data packet from the sending switch and transfers the data packet to the receiving TCP host. When the receiving TCP host analyzes the data packet and determines that the IP header of the data packet is marked indicating congestion, the receiving TCP host generates an ACK with a marked ACK header indicating congestion in a network or transmission line. The marked ACK is then sent back to the sending TCP host. After an ACK indicates that a marked data packet was received by the sending TCP host, the sending TCP host decreases the send window (rate of packets sent to a destination switch) by one data packet for the data packet indicated as being marked. In one embodiment, this happens every time a data packet is shown as being marked. This decrease in data transfer rate is shown by the downward slope of the graph after peak 602. This type of cycle repeats again at peak 606 and 610.
[0070]FIGS. 7, 8, and 9 illustrate embodiments of the present invention in the form of simulations quantifying the performance benefits of TCP with congestion marking of the present invention versus simple TCP. FIGS. 7, 8, and 9 show various comparisons between standard TCP with fast retransmit (plain TCP) and an enhanced TCP with the more intelligent data transfer congestion reduction protocol of the present invention (CMARK TCP). The fast retransmit algorithm uses the arrival of 3 duplicate ACKs as an indication that data has been lost. Therefore, when 3 duplicate ACKs are received, TCP resends the data it believes has been lost without waiting for the retransmission timer to time out.
The system used in the simulations consists of six to sixteen “Just a Bunch of Drives” (JDOB) bridges, each connected through Gigabit Ethernet to a switch, which is then connected to a single Host. The switch may have input queues which can hold 170 full size packets (i.e. 256 KB), and the host may have 170 NIC buffers. A random, 4 KB read workload is simulated with eight sessions per bridge, each carrying the traffic expected of about 4 high performance drives (in effect simulating 32 drives per bridge box).
[0073]FIGS. 7, 8, and 9 show simulations involving two variations of TCP, one with standard prior art TCP (plain TCP or standard TCP) and the other with TCP using the congestion reduction methods of the present invention (CMARK TCP). Both the plain TCP and CMARK TCP use the standard congestion windowing algorithm, but based on packets rather than bytes. That is, average and standard deviation of Round Trip Time (RTT) was measured using the Internet Engineering Task Force (IETF) recommended algorithm, as implemented in a Free Berkeley Software Distribution (BSD) operating system. In the simulations, a timeout (when an acknowledgment for a data packet is not received by a certain period of time) set the SSTHRESH variable to half of the outstanding packets, and the congestion window (CWIND) to 1 packet. SSTHRESH is a slow start threshold which determines whether the sending state is slow start or congestion avoidance. A CWND is a congestion window that limits the amount of data that can be transmitted into a transmission media before receiving an ACK. The congestion window may also determine a set rate of data packet sending (in packets per round trip time (PRTT)) of a sending host. The congestion window was then incremented according to the slow start and congestion control procedures defined by the IETF in Request for Comments (RFC) 2581. The RFC 2581 is hereby incorporated by reference. The base TCP also includes fast retransmit, which set the SSTHRESH and CWIND to half the outstanding packets when a fast retransmit was indicated. This means that the send window is reduced by half during congestive periods. The second version, TCP with Congestion Marking in accordance with one embodiment of the present invention, reduced CWIND by 1 packet with each marked packet. In one embodiment, three data transfer windows are operating at once: a configuration maximum which can be up to 64 kilobytes; a send window which operates with TCP and higher level flow control; and CWND, the congestion window. TCP stops sending data if any of the three windows are exceeded.
[0077]FIG. 7 shows a graph 700 of transport protocol performance of two different types of protocols in wire utilization for varying traffic loads in accordance with one embodiment of the present invention. The graph 700 shows achieved bandwidths of each protocol as a percentage of maximum potential bandwidth of the wire. The potential bandwidth is calculated as the number of packets sent by the JBOD boxes (not counting any retries) divided by the total number of packets that could be delivered in the time period simulated (100 seconds). With 48 sessions (6 boxes) and 56 sessions (7 boxes), the network is not saturated and the bandwidth is limited by the “seek time” of the drives. From 64 sessions onward the network is being offered more traffic than it can handle, so the various congestion schemes are limiting traffic.
[0079]FIG. 8 shows a graph 800 illustrating an average latency comparison of two different transport protocols in accordance with one embodiment of the present invention. The graph 800 shows the average network latency achieved by the protocols. Latency is the amount of time from the first instance a particular packet is transmitted until the final acknowledgement of its correct reception.
monitoring a level of data transfer congestion within the data transfer system, the monitoring including marking data during data transfer congestion and detecting marked data; and
adjusting a data transfer rate corresponding to the level of data transfer congestion;
wherein the adjusting includes reducing the data transfer rate in direct correlation to the level of data transfer congestion as indicated by each marked data and increasing the data transfer rate in direct correlation to a lack of data transfer congestion as indicated by unmarked data during a round trip time (RTT).
2. A method for optimizing data transmission in a data transfer system as recited in
, wherein the marked data is a data packet that is marked with data congestion information.
3. A method for optimizing data transmission in a data transfer system as recited in
, wherein the unmarked data is a data packet without data congestion information.
4. A method for optimizing data transmission in a data transfer system as recited in
, wherein the marking data during data transfer congestion includes:
determining a fraction of the input buffer of the routing mechanism that is filled;
randomly marking the data packet according to a probability identical to the fraction of the input buffer that is filled, the random marking indicating data transfer congestion; and
generating an acknowledgement data by a recipient of the data packet, the acknowledgment data being marked if the data packet is marked.
5. A method for optimizing data transmission in a data transfer system as recited in
, wherein the detecting marked data includes:
6. A method for optimizing data transmission in a data transfer system as recited in
, wherein the reducing further includes decreasing the data transmission rate by one data packet per round trip time (PRTT) for every marked packet detected.
7. A method for optimizing data transmission in a data transfer system as recited in
, wherein the increasing further includes transmitting one additional data packet per round trip time (PRTT) where only the unmarked data packets are detected during a previous round trip time.
8. A method for optimizing data transmission in a data transfer system as recited in
, wherein the marking the data packet includes setting data congestion information in an internet protocol header of the data packet.
9. A method for optimizing data transmission in a data transfer system as recited in
, wherein the generating acknowledgment data includes setting data congestion information in an acknowledgment header if the data packet is marked.
10. A method for optimizing data transmission in a data transfer system as recited in
, wherein the acknowledgement data is a positive acknowledgement (ACK).
11. A method for optimizing data transmission in a data transfer system as recited in
, wherein the data transfer system includes at least a sending host, a sending switch, and a data recipient.
12. A method for optimizing data transmission in a data transfer system as recited in
, wherein the data recipient includes at least one of a receiving host and a receiving switch connected to the receiving host.
a input buffer for receiving the packet traffic at the set rate, the input buffer being actively monitored to ascertain a capacity level;
code for setting a probability factor that is correlated to the capacity level, the probability factor increasing as the capacity level increases and decreasing as the capacity level decreases;
code for randomly generating a value, the value being indicative of whether packets being sent by the sending switch are to be marked with a congestion indicator; and
transmit code forwarding the packet traffic out of the sending switch, the packet traffic including one of marked packets and unmarked packets; and
14. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the sending host is configured to monitor the acknowledgment packets and to adjust the set rate based on whether the acknowledgment packets are marked with the congestion indicator.
15. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is a number of packets sent per round trip time (RTT) as determined by a congestion window in the sending host.
16. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the congestion window operates to limit the amount of data that can be transmitted by the sending host before the acknowledgement packet is received.
17. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the sending host decreases the set rate every time one of the marked packets is detected.
18. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is decreased by one packet per round trip time (PRTT) for each of the marked packets that is detected by the sending host.
19. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the sending host increases the set rate when no marked packets are detected per round trip time (PRTT).
20. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is increased by one packet per round trip time (PRTT).
21. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the actively monitored is an examining of the input buffer and a determining of an amount of the packets in the input buffer.
22. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the capacity level is a fraction of the input buffer that is filled with the packets.
23. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the probability factor is a percentage probability that one of the packets sent from the sending switch to the receiving end will be marked.
24. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the value is a randomly generated number between 1 and 100.
25. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the congestion indicator is data in the IP header of the packets showing that data transfer congestion exists.
26. A method for actively controlling congestion to optimize throughput comprising:
monitoring the input buffer to ascertain a capacity level of the input buffer;
setting a probability factor that is correlated to the capacity level of the input buffer, the probability factor increasing as the capacity level increases and decreasing as the capacity level decreases;
randomly generating a value, the value being indicative of whether the data packet sent by the sending switch is to be marked with a congestion indicator;
forwarding the data packet out of the sending switch to a recipient, the data packet being one of a marked data packet and an unmarked data packet; and
27. A method for actively controlling congestion to optimize throughput as recited in
28. A method for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is a number of data packets sent per round trip time (PRTT) as determined by a congestion window in the sending host.
29. A method for actively controlling congestion to optimize throughput as recited in
, wherein the congestion window operates to limit the amount of the data packets that can be transmitted by the sending host before the acknowledgement packet is received.
30. A method for actively controlling congestion to optimize throughput as recited in
, wherein the sending host decreases the set rate every time one of the marked data packets is detected.
31. A method for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is decreased by one data packet per round trip time (PRTT) for each of the marked data packet that is detected by the sending host.
32. A method for actively controlling congestion to optimize throughput as recited in
, wherein the sending host increases the set rate when no marked data packets are detected per round trip time (PRTT)
33. A method for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is increased by one data packet per round trip time (PRTT).
34. A method for actively controlling congestion to optimize throughput as recited in
35. A method for actively controlling congestion to optimize throughput as recited in
, wherein the capacity level is a fraction of the input buffer that is filled with a plurality of the data packet.
36. A method for actively controlling congestion to optimize throughput as recited in
, wherein the probability factor is a percentage probability that the data packet sent from the sending switch to the receiving end will be marked.
37. A network system for actively controlling congestion to optimize throughput as recited in
38. A network system for actively controlling congestion to optimize throughput as recited in
, wherein the congestion indicator is data in the IP header of the data packet showing that data congestion exists.
39. A method for actively controlling congestion to optimize throughput comprising:
forwarding the data packet out of the sending switch to a recipient, the data packet being one of a marked data packet and an unmarked data packet;
40. A method for actively controlling congestion to optimize throughput as recited in
, wherein the set rate is a number of packets sent per round trip time (PRTT) as determined by a congestion window in the sending host.
US09726676 2000-03-14 2000-11-29 Congestion control for internet protocol storage Active 2023-04-08 US7058723B2 (en)
US18963900 true 2000-03-14 2000-03-14
US09726676 US7058723B2 (en) 2000-03-14 2000-11-29 Congestion control for internet protocol storage
US20010032269A1 true true US20010032269A1 (en) 2001-10-18
US7058723B2 US7058723B2 (en) 2006-06-06
ID=26885363
US09726676 Active 2023-04-08 US7058723B2 (en) 2000-03-14 2000-11-29 Congestion control for internet protocol storage
US (1) US7058723B2 (en)
US20020042837A1 (en) * 2000-08-28 2002-04-11 Nec Corporation Streaming data transfer system and repeater therefor
US20030088690A1 (en) * 2001-08-09 2003-05-08 Moshe Zuckerman Active queue management process
US20030120796A1 (en) * 2001-12-26 2003-06-26 Lg Electronics Inc. Method for controlling congestion in connection section between ATM network and NON-ATM network
EP1441474A2 (en) 2003-01-24 2004-07-28 Microsoft Corporation Pacing network packet transmission using at least partially uncorrelated network events
US20050157752A1 (en) * 2004-01-16 2005-07-21 Hitachi., Ltd. Storage switch with bandwidth control function
US20060023634A1 (en) * 2004-07-30 2006-02-02 Cisco Technology, Inc. Transmission control protocol (TCP)
US20060045011A1 (en) * 2002-11-26 2006-03-02 Aghvami Abdol H Methods and apparatus for use in packet-switched data communication networks
EP1638276A2 (en) * 2004-08-18 2006-03-22 Wecomm Limited Data packet transmission
US20060253622A1 (en) * 2003-01-28 2006-11-09 Henning Wiemann Method and device for congestion notification in packet networks indicating several different congestion causes
US20070177502A1 (en) * 2006-02-01 2007-08-02 Nec Corporation Communication system, communication apparatus, congestion control method used therefor, and program for the method
US20090097483A1 (en) * 2007-10-15 2009-04-16 Canon Kabushiki Kaisha Method and device for transmitting data
US7768909B1 (en) * 2003-10-28 2010-08-03 At&T Intellectual Property Ii, L.P. Congestion control in an IP network
US20110228697A1 (en) * 2010-03-19 2011-09-22 Hitachi, Ltd. Mobile Communication System and Communication Method
US20120063493A1 (en) * 2009-03-06 2012-03-15 Yohei Hasegawa Transmission rate control method, transmission unit, and communication system
US20130117553A1 (en) * 2007-12-31 2013-05-09 Rockstar Consortium Us Lp Method and Apparatus for Increasing the Output of a Cryptographic System
US20130155850A1 (en) * 2011-12-19 2013-06-20 International Business Machines Corporation Buffer occupancy based random sampling for congestion management
US9007902B1 (en) * 2004-09-29 2015-04-14 Marvell Israel (M.I.S.L.) Ltd. Method and apparatus for preventing head of line blocking in an Ethernet system
US20160182337A1 (en) * 2014-04-25 2016-06-23 International Business Machines Corporation Maximizing Storage Controller Bandwidth Utilization In Heterogeneous Storage Area Networks
US20170250914A1 (en) * 2015-06-26 2017-08-31 Microsoft Technology Licensing, Llc In-line network accelerator
US9936500B2 (en) 2016-11-30 2018-04-03 Ipr Licensing, Inc. Transmitting acknowledgement messages using a staggered uplink time slot
DE60108387T2 (en) * 2001-09-12 2005-12-29 Alcatel Method and apparatus for differentiating service in a data network
US7225267B2 (en) * 2003-01-27 2007-05-29 Microsoft Corporation Reactive bandwidth control for streaming data
US7952998B2 (en) * 2007-01-10 2011-05-31 International Business Machines Corporation InfiniBand credit-less flow control for long distance links
US20090187683A1 (en) * 2008-01-22 2009-07-23 International Business Machines Corporation Adaptive link width control
WO2010017205A3 (en) * 2008-08-04 2010-04-22 David Gibbons Systems and methods for video bookmarking
KR101781159B1 (en) * 2010-12-20 2017-09-22 한국전자통신연구원 Apparatus and Method for Providing Light Weight Multicast of Data Distribution Service
US8694701B2 (en) * 2011-12-15 2014-04-08 Mellanox Technologies Ltd. Recovering dropped instructions in a network interface controller
US7054961B2 (en) * 2000-08-28 2006-05-30 Nec Corporation Streaming data transfer system and repeater therefor
US20060106961A1 (en) * 2000-08-28 2006-05-18 Nec Corporation Streaming data transfer system and repeater therefor
US7461185B2 (en) 2000-08-28 2008-12-02 Nec Corporation Streaming data transfer system and repeater therefor
US7272111B2 (en) * 2001-08-09 2007-09-18 The University Of Melbourne Active queue management process
US7782777B2 (en) 2001-11-23 2010-08-24 Nokia Corporation Method and system for handling network congestion
US7428595B2 (en) 2002-09-30 2008-09-23 Sharp Laboratories Of America, Inc. System and method for streaming TCP messages in an enterprise network
US7389336B2 (en) 2003-01-24 2008-06-17 Microsoft Corporation Pacing network packet transmission using at least partially uncorrelated network events
KR101006274B1 (en) * 2003-01-24 2011-01-06 마이크로소프트 코포레이션 Pacing network packet transmission using at least partially uncorrelated network events
US20040148387A1 (en) * 2003-01-24 2004-07-29 Sethi Bhupinder S. Pacing network packet transmission using at least partially uncorrelated network events
EP1441474A3 (en) * 2003-01-24 2006-06-21 Microsoft Corporation Pacing network packet transmission using at least partially uncorrelated network events
WO2005006626A3 (en) * 2003-07-15 2005-05-26 Nokia Corp Method and apparatus for accelerating throughput in a wireless or other telecommunication system
WO2005006626A2 (en) * 2003-07-15 2005-01-20 Nokia Corporation Method and apparatus for accelerating throughput in a wireless or other telecommunication system
EP1652087A2 (en) * 2003-07-29 2006-05-03 Orbital Data Corporation Flow control architecture
EP1652087A4 (en) * 2003-07-29 2010-09-29 Orbital Data Corp Flow control architecture
US7133363B2 (en) 2004-01-16 2006-11-07 Hitachi, Ltd. Storage switch with bandwidth control function
EP1638276A3 (en) * 2004-08-18 2006-05-03 Wecomm Limited Data packet transmission
US8671147B2 (en) 2007-06-09 2014-03-11 Open Text S.A. Supplying applications to mobile devices
US8462778B2 (en) * 2007-10-15 2013-06-11 Canon Kabushiki Kaisha Method and device for transmitting data
US9331853B2 (en) * 2007-12-31 2016-05-03 Rpx Clearinghouse Llc Method and apparatus for increasing the output of a cryptographic system
US8483063B2 (en) * 2010-03-19 2013-07-09 Hitachi, Ltd. Mobile communication system and communication method
US7058723B2 (en) 2006-06-06 grant
US20040042464A1 (en) 2004-03-04 System and method for TCP/IP offload independent of bandwidth delay product
US7236459B1 (en) 2007-06-26 Method and apparatus for controlling data transmission volume using explicit rate control and queuing without data rate supervision
US20050157723A1 (en) 2005-07-21 Controlling traffic congestion
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WILSON, ANDREW W.;REEL/FRAME:011326/0936