R. Morris. Tcp behavior with many flows. In Proceedings of IEEE ICNP, pages 205--211, 1997.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... may fail if losses in the network are due to cases other than congestion, such as in the case of wireless links (see for instance [1, 2, 3] Moreover, the control does not work well if the congestion is caused by an excessive number of TCP connections allowed to compete for the same bottleneck [4]. Fortunately, routers of the next generation will be more intelligent than the ones used in traditional TCP implementations. They will be able to predict impending congestion because of better environment awareness; however, a major problem consists in correctly elaborating and conveying ....

....and Drop Tail is less than , while it was in the LAN experiment. 6.3 BEHAVIOR WITH MANY FLOWS One of the concerns in traditional TCP implementations is the degradation of performance when the number of connections competing for the same bottleneck becomes large. Two recent papers [4, 30] highlight the problem and give good explanation of this phenomenon. Essentially, TCP connections oscillate between timeout state and active state. Besides, if a large number of flows are simultaneously active, their windows are small. This implies that the load offered to the network increases ....

[Article contains additional citation context not shown here]

R. Morris. TCP Behavior with Many Flows. In IEEE ICNP'97, Atlanta, GE, USA, Oct. 28 -- 31, 1997.

....dynamics of congestion efficiency control. Second, imposing two objectives on a single control law (i.e. efficiency and a particular allocation) makes it hard to find a control law that excels in achieving either goal. For example, in the case of TCP, AIMD neither converges to optimal utilization [78, 51, 58] nor achieves high fairness [12, 37, 58] We propose a new approach for bandwidth regulation that decouples congestion control from the process that enforces the bandwidth allocation policy. This decoupling is done by recognizing that efficiency and the occurrence of congestion are determined ....

....Second, imposing two objectives on a single control law (i.e. efficiency and a particular allocation) makes it hard to find a control law that excels in achieving either goal. For example, in the case of TCP, AIMD neither converges to optimal utilization [78, 51, 58] nor achieves high fairness [12, 37, 58]. We propose a new approach for bandwidth regulation that decouples congestion control from the process that enforces the bandwidth allocation policy. This decoupling is done by recognizing that efficiency and the occurrence of congestion are determined by aggregate traffic on a link, and are ....

R. Morris. Tcp behavior with many flows. In in International Conference on Network Protocols, Oct. 1997.

....distances. Figure 3 shows the UDP and TCP rates allocated by BAT for different f i,min as a function of the delay introduced for various numbers of TCP sources. The allocated TCP bandwidth increases with the number of TCP sources. This is consistent with findings from other AQM algorithms [11] [21] and can be modeled using the throughput equation of TCP [22] Furthermore, the TCP bandwidth share decreases with increasing RTT, as it will take longer to recover from packet loss [22] D. A First Step to Improve Fairness A first measure to increase fairness between responsive and ....

R. Morris. TCP behavior with many flows. In Proceedings of IEEE International Conference on Network Protocols (ICNP), pages 205--211, October 1997.

....of this feature: this optimization significantly reduces interference, particularly when testing against several background flows. A similar optimization has been suggested even for regular flows to handle cases when the number of flows starts to approach the bottleneck router buffer size [35]. When a Nice flow signals congestion, it halves its current congestion window. In contrast Vegas reduces its window by one packet each round that encounters long round trip times and only halves its window if packets are lost (falling back on Reno like behavior. The combination of more ....

....suggests that as the number of demand flows approaches the maximum queue size the non interference property starts to break down. This breakdown is not surprising as each flow barely gets to maintain one packet in the queue and TCP Reno is known to behave anomalously under such circumstances [35]. In a well designed network, when B m, it can be seen that the dependence on the threshold t is weak, i.e. interference is small when t is, and careful tuning of the exact value of t in this region is unnecessary. The full analysis below shows that the above bound on I holds even for the case ....

R. Morris. Tcp behavior with many flows. In International Conference on Network Protocols, 1997.

....generated by the sources arrive at node s i . The aggregation nodes s i are connected to the bottleneck r1 by a link with a capacity enough to avoid losses. PO, PRIO, RIO and DT are implemented at node r1 and at node r2. The buffer size in these nodes is equal to the bandwidth latency product [9]. The TCP implementation used here is Reno since it is the most common version in the Internet. Initially, was calibrated taking into account the measured network load. When using a protocol that performs congestion control, such as TCP, the service rate is not given by the ratio 1=L=C, since ....

R. Morris, "TCP Behavior with Many Flows," in International Conference on Network Protocols, Oct. 1997.

....network. While this may not necessarily be true, the exponential back o does help in quickly adapting the timer to very large delay links. However, such a strategy can signi cantly a ect a connection s throughput, as shown in a study of a large number of TCP connections sharing a bottleneck link [132]. The study shows that heavy packet loss causes some connections to succeed in increasing their window aggressively through Slow Start, while others fall into multiple exponentially increasing retransmission timeouts. Thus, the lack of a middle ground between extended idle times and aggressive ....

Morris R., TCP Behavior with Many Flows, in IEEE Conference on Network Protocols, Atlanta, October 1997.

....can effectively rate limit the non responsive flows, the partitioning of buffer space causes the fairness between flows to deteriorate as well. The large amount of packet loss induces a large number of retransmission timeouts across a subset of flows which causes significant amounts of unfairness [21]. Thus, through the course of the experiment, a few TCP flows are able to grab a disproportionate amount of the bandwidth while many of the flows receive significantly less than a fair share of the bandwidth across the link. In addition to this, SFQ 17 Flow Number 0.00 0.05 0.10 0.15 0.20 ....

R. Morris. TCP Behavior with Many Flows. In Proc. IEEE International Conference on Network Protocols, October 1997. 26

....can effectively rate limit the non responsive flows, the partitioning of buffer space causes the fairness between flows to deteriorate as well. The large amount of packet loss induces a large number of retransmission timeouts across a subset of flows which causes significant amounts of unfairness [25]. Thus, through the course of the experiment, a few TCP flows are able to grab a disproportionate amount of the bandwidth while many of the flows receive significantly less than a fair share of the bandwidth across the link. In addition to this, SFQ with RED allows 46 of the 400 flows to be ....

R. Morris. TCP Behavior with Many Flows. In Proc. IEEE International Conference on Network Protocols, October 1997.

....SFQ with RED can effectively rate limit the non responsive flows, the partitioning of buffer space causes the fairness between flows to deteriorate as well. The large amount of packet loss can induce retransmission timeouts across a subset of flows which causes significant amounts of unfairness [12]. Thus, through the course of the experiment, a few TCP flows grab a disproportionate amount of the bandwidth while many of the flows receive significantly less than a fair share of the bandwidth across the link. In addition to this, SFQ with RED allows 46 th of the 400 flows to be mapped into ....

R. Morris. TCP Behavior with Many Flows. In Proc. IEEE International Conference on Network Protocols, October 1997.

....of this feature: this optimization significantly reduces interference, particularly when testing against several background flows. A similar optimization has been suggested even for regular flows to handle cases when the number of flows starts to approach the bottleneck router buffer size [35]. When a Nice flow signals congestion, it halves its current congestion window. In contrast Vegas reduces its window by one packet each round that encounters long round trip times and only halves its window if packets are lost (falling back on Reno like behavior. The combination of more ....

....suggests that as the number of demand flows approaches the maximum queue size the non interference property starts to break down. This breakdown is not surprising as each flow barely gets to maintain one packet in the queue and TCP Reno is known to behave anomalously under such circumstances [35]. In a well designed network, when B m, it can be seen that the dependence on the threshold t is weak, i.e. interference is small when t is, and careful tuning of the exact value of t in this region is unnecessary. Our full analysis shows that the above bound on I holds even for the case when m ....

R. Morris. Tcp behavior with many flows. In International Conference on Network Protocols, 1997.

....1 Dest 2 Dest n Bottleneck Link Router S Router D Large bandwidth links Figure 1. Simplified abstract network model. The bottleneck link router uses FIFO scheduling. Its buffer management is either Drop Tail or RED [16] The TCP segment size is set to 500 bytes, similar to what was used in [32, 2]. As [32] points out, it is very common to have hundreds of concurrent connections competing for the bottleneck resource in today s Internet, so we are particularly interested in the TCP behavior under such a large number of connections. Each sender has unlimited amount of data to send. When the ....

....Dest n Bottleneck Link Router S Router D Large bandwidth links Figure 1. Simplified abstract network model. The bottleneck link router uses FIFO scheduling. Its buffer management is either Drop Tail or RED [16] The TCP segment size is set to 500 bytes, similar to what was used in [32, 2] As [32] points out, it is very common to have hundreds of concurrent connections competing for the bottleneck resource in today s Internet, so we are particularly interested in the TCP behavior under such a large number of connections. Each sender has unlimited amount of data to send. When the ....

[Article contains additional citation context not shown here]

R. Morris. TCP Behavior with Many Flows. Proc. IEEE International Conference on Network Protocols'97, Atlanta, GA, USA, October 1997.

....ms (typical for geostationary satellite links) We also vary the buffer size and the number of connections in each scenario. The bottleneck link router uses FIFO scheduling and drop tail buffer management, which are most commonly used in the Internet. The TCP segment size is set to 500 bytes. As [9] points out, it is very common to have hundreds of concurrent TCP flows competing for the bottleneck resource in today s Internet, so we are particularly interested in investigating the TCP behavior for such a large number of flows. We use the following notations throughout our discussions: ffl ....

....ms or 50 ms delay. episode. So altogether there are Conn losses every episode. Meanwhile the frequency of loss episode is proportional to Conn. Therefore for small number of connections, the loss probability is proportional to Conn . Such quadratic growth in loss probability is also reported in [9] for routers with RED dropping policy. When the number of connections is large (larger than ) as shown in Figure 13, the growth of loss probability with respect to the number of connections matches impressively well with the following family of hyperbolic curves represented by y = bx x a . ....

[Article contains additional citation context not shown here]

R. Morris. TCP Behavior with Many Flows. In Proc. IEEE International Conference on Network Protocols '97, October 1997.

No context found.

R. Morris. Tcp behavior with many flows. In Proceedings of IEEE ICNP, pages 205--211, 1997.

No context found.

R. Morris. TCP behavior with many flows. In Proceedings of IEEE International Conference on Network Protocols (ICNP), pages 205--211, October 1997.

No context found.

R.T. Morris, "TCP Behavior with Many Flows," in IEEE International Conference on Network Protocols (ICNP'97), Atlanta, Georgia, October 1997.

No context found.

Robert Morris. TCP behavior with many flows. In Proceedings of IEEE International Conference on Network Protocols (ICNP), pages 205--211, October 1997.

No context found.

R. Morris. TCP behavior with many flows. In Proceedings of IEEE ICNP, Atlanta, GA, October 1997.

No context found.

R. Morris, "TCP behavior with many flows," Proc. 4th IEEE International Conference on Network Protocols, Oct. 1997.

No context found.

Robert Morris, "TCP behavior with many flows," in Proceedings of IEEE International Conference on Network Protocols, October 1997.

No context found.

Robert Morris, "TCP behavior with many flows," in Proceedings of IEEE International Conference on Network Protocols, October 1997.

No context found.

R. Morris. TCP behavior with many flows. In Proceedings of IEEE International Conference on Network Protocols (ICNP), pages 205--211, October 1997.

No context found.

R. T. Morris, TCP behavior with many flows, in: IEEE International Conference on Network Protocols, Atlanta, Georgia, 1997.

No context found.

R. Morris. TCP behavior with many flows. In Proceedings of IEEE International Conference on Network Protocols (ICNP), pages 205--211, October 1997.

No context found.

R. Morris. TCP behavior with many flows. In Proceedings of IEEE ICNP, Atlanta, GA, October 1997.

No context found.

Morris, R., "TCP Behavior with Many Flows", In Proceedings of IEEE International Conference on Network Protocols, October 1997, Atlanta, Georgia 15

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC