Loss Synchronization and Router Buffer Sizing with High ... - CiteSeerX

Loss Synchronization and Router Buffer Sizing with High-Speed Versions of TCP Sofiane Hassayoun

David Ros

Institut TELECOM / TELECOM Bretagne Rue de la Châtaigneraie, CS 17607 35576 Cesson Sévigné cedex, France Email: [email protected]

Institut TELECOM / TELECOM Bretagne Rue de la Châtaigneraie, CS 17607 35576 Cesson Sévigné cedex, France Email: [email protected]

Abstract—In this paper we are interested in looking at packet loss synchronization, and the related issue of buffer sizing, when the bulk of the traffic is composed of a moderate number of flows using high-speed versions of TCP. In particular, we wanted to explore whether increased levels of synchronization would be an outcome of using more aggressive versions of TCP over high-bandwidth paths. By means of ns-2 simulations, we have evaluated several TCP versions and a wide range of buffer sizes, as well as three different drop synchronization metrics. Our preliminary findings suggest that high-speed versions of TCP do yield higher levels of synchronization. However, in spite of a strong drop synchronization, such TCP versions can achieve both high goodput and link utilization, as long as enough buffering is provided.

I. I NTRODUCTION AND BACKGROUND Nowadays, it is well known that the classical congestion control algorithms used by TCP are not adapted to very highspeed links or, more generally, to networks having a large bandwidth-delay product (BDP). This is mainly due to the Additive-Increase, Multiplicative-Decrease (AIMD) behavior of TCP’s congestion control. First, a TCP sender reacts to packet loss by cutting the congestion window cwnd by half, so the instantaneous sending rate is roughly divided by two; that is, cwnd ← b × cwnd , with decrease factor b = 0.5. Second, the increase of cwnd in the congestion avoidance phase, given by: cwnd ← cwnd + a/cwnd , with increase parameter a = 1, results in a growth rate of approximately one segment1 per round-trip time (RTT). Indeed, if the BDP is large, cwnd may attain very large values before packets are lost; hence, after a loss takes place it may take the sender many RTT cycles before cwnd reaches again such large values. A complementary issue is that of adequately dimensioning router buffers for links running at Gb/s speeds. A rule-ofthumb, first stated by V. Jacobson in the End-to-End mailing list (1990) and discussed in [1], states that a router in a bottleneck should provide B = C × RTT of buffer space, where C is the rate of the egress bottleneck link and RTT corresponds to the average round-trip time experienced by connections that use this link. However, as first discussed by Appenzeller et al. [2], for links running at gigabit speeds and higher this rule typically yields huge values of B—buffers that may be impractical or even not feasible. 1 Or

less, if delayed acknowledgements are used.

978-1-4244-2219-7/08/$25.00 (c)2008 IEEE

A. Congestion Control Algorithms for High-Speed Links In response to TCP’s problems in Gb/s environments, several new congestion control algorithms have been proposed, such as: HighSpeed TCP (HSTCP) [3], Scalable TCP [4], FAST TCP [5], BIC [6] and CUBIC [7] TCP, H-TCP [8] and Compound TCP [9]. Just like standard TCP, most of these algorithms (i.e., with the exception of FAST and Compound TCP) are loss-based, in the sense that congestion is detected and reacted upon when packets are lost. What most of these new proposals have in common is that they modify TCP’s congestion control algorithms, in particular the AIMD behavior in Congestion Avoidance. When the congestion window gets “large”, senders using one of those protocols tend to seek for available bandwidth in a more aggressive way, and react to losses in a less conservative way, than a standard TCP sender. B. Router buffer sizing and high-bandwidth TCP versions In the last few years, many authors have questioned the validity of the classical C × RTT rule-of-thumb for determining an adequate buffer size B. Newer sizing rules, yielding much lower values of B, are often based on the hypothesis that flows are not synchronized in a real network with a large number of TCP connections. Such rules trade off lower values of B for lower link utilization; the ideal goal is to reduce B as much as possible, while maintaining an utilization as high as possible. Appenzeller √ et al. [2] proposed to use the sizing rule B = C × RTT / N , where N is the number of long-lived flows sharing the bottleneck link. Based on similar hypothesis, Wischik and √ McKeown [10] propose taking: B = 0.63 × C × RTT / N , whereas other authors suggest that values as low as a few tens of packets [11], [12] may be feasible. Even if some recent work tries to unify and explain conflicting results (see e.g. [13]), it seems there is no consensus yet on what is a “good” dimensioning rule, nor on whether it is possible at all to always achieve high utilization with simple sizing rules as those above [14]. In any event, most buffer sizing rules found in the literature assume “standard” TCP flows. If we consider for instance the C × RTT rule-of-thumb, this buffer value comes from the characteristics of TCP congestion control, namely the decrease parameter b = 0.5 in the congestion avoidance phase [2]. However, new congestion control algorithms are often

characterized by higher values of b, i.e., by a less aggressive reduction of cwnd after a congestion event. Finding a sizing rule adapted to specific high-speed variants of TCP is outside the scope of this paper. However, it seems natural to review the classical rule-of-thumb under this light. Following a reasoning similar to that in [2], it is easy to show that the minimum buffer size needed to avoid the buffer from getting empty (assuming perfectly-synchronized windows) can be written as: B=

1−b × C × RTT ; b

(1)

which gives B = C × RTT in the case b = 0.5. When b = 0.5, we will call the value of B given by (1) the “adapted rule-of-thumb”. Remark that B decreases with increasing b. Thus, in the case of BIC, which uses b = 0.8, rule (1) gives buffer sizes four times smaller than those given by the C ×RTT rule-of-thumb. For H-TCP and HSTCP, the decrease parameter is not fixed but can be regarded as taking any value in (0.5, 0.8) and (0.5, 1), respectively; for the purposes of our study, for these two protocols we used an intermediate value b = 0.65 for computing B as per (1). This value results, for H-TCP and HSTCP, in buffer sizes about half those given by the rule-of-thumb. C. Drop synchronization Drop synchronization between TCP flows happens whenever two or more flows experience packet loss in a short time interval. Such phenomenon has been known for many years [15], and has been the object of several studies and proposals [16]–[18] because of its potential performance implications. Indeed, traffic phase effects due to e.g. similar RTTs among flows might (in theory) yield perfectly-synchronized losses, which in turn would result in TCP senders reducing their window in unison—hence, in poor throughput and low link utilization. In practice, however, such highly-correlated loss patterns are rarely observed [19], [20]; factors like fluctuations in RTTs and processing times [16], as well as high levels of statistical multiplexing [2], tend to break the synchronization among flows. Note also that the use of large enough buffers, such as those given by (1), tends to compensate the impact of synchronized window reductions on link utilization and throughput [2]. Nonetheless, since previous studies on synchronization and phase effects have focused mostly on “low-speed” TCP, one may wonder whether drop synchronization may be impacted by the use of high-speed variants of TCP. Indeed, both Floyd and Kohler [20] and Jay et al. [19] conjecture that a higher synchronization might be a side effect of the increased aggressiveness of the congestion control algorithms in those variants. D. Goal and structure of the paper This paper presents a preliminary study of the relationship between drop synchronization and buffer sizing, when highspeed TCPs are used. By means of ns-2 simulations, the dependence of synchronization on the TCP version is explored.

978-1-4244-2219-7/08/$25.00 (c)2008 IEEE

In particular, we wanted to know whether synchronization increases with more aggressive congestion control, for a given buffer size. We have focused on scenarios with moderate levels of statistical multiplexing. This is not only for practical reasons (i.e., to reduce the computational cost of simulations), but also to allow the flows of interest to really operate in a high-speed regime; further, we may expect that phase effects will arise more easily when the impact of individual connections on the flow aggregate is higher (see e.g. [13]). We have chosen to evaluate the following loss-based, highspeed protocols: HSTCP, BIC and H-TCP. We also have considered SACK TCP [21], which is used as a reference. We did not include Scalable TCP because it has been reported to be prone to stability problems [22]. Studying delay-based protocols like Compound TCP is left for future work. The remainder of the paper is organized as follows. In Section II we present some related work. Section III discusses three synchronization metrics that are relevant for our study. The simulation scenarios used in this paper are detailed in Section IV. Simulation results are presented and discussed in Section V. Finally, Section VI concludes the paper. II. R ELATED W ORK In [23], Leith and Shorten propose a metric to evaluate synchronization between flows. They are interested on the impact of loss synchronization on fairness between competing flows. They found that fairness is sensitive to loss synchronization. Jay et al. [19] performed an experimental study of synchronization over actual paths in the Internet, using SACK TCP. For each path, a set of TCP connections were established between a pair of end-hosts, so the flows shared a common end-to-end path. They found that drop synchronization exists indeed, but that highly-synchronized loss patterns seem to be rare (e.g., with 32 parallel flows, less than 14 flows experienced correlated packet drops in 90% of the loss events). Their results also suggest that synchronization is sensitive to factors such as round-trip times and the number of hops. In [24], Chen and Bensaou have studied the problem of unfairness for high-speed TCP variants. They considered simulated scenarios with a low level of statistical multiplexing, multiple bottlenecks and router buffers using either drop-tail or active queue management (AQM) policies. They found that, with drop-tail queues, unfairness among flows is high, even when flows have similar RTTs; this seems to be due to the prevalence of synchronized loss patterns. They advocate the use of AQM as a way of mitigating the lack of fairness between high-speed flows. Rania et al. [25] proposed two control-theoretical models, one for the case of a small buffer using a drop-tail mechanism, and the other for a large buffer with AQM. They found that desynchronization, or stability of the dynamics of these systems, depends on the buffer size. In the small buffer regime, buffers larger than 50 packets may cause instability and then some synchronization for small window sizes. In the large buffer regime, large buffers are required when window sizes are large.

flow i

III. L OSS SYNCHRONIZATION METRICS Loss synchronization, as described in Section I-C, can be explicitly quantified by means of several metrics. Below we will give precise definitions of three possible metrics.

x

x

x

x

x

x

x time

flow j

x

Fig. 1.

x x

x

x

Synchronization: an example.

A. Loss synchronization of given flows Consider a “long” measuring interval τ during which losses in a bottleneck are registered. Let M denote the set of flows sharing the bottleneck that lose at least one packet during τ . A loss event takes place every time one or more flows lose one or more packets in a “short” interval ∆. Denote by T > 0 the total number of loss events that happen in the bottleneck during the measuring interval τ , and M = |M|. Let dk, be an indicator variable such that dk, = 1 if flow k loses one or more packets at the -th loss event, ∈ {1, . . . , T }, and dk, = 0 otherwise. The number of loss events in which flow T k loses one or more packets is: =1 dk, = Nk ∈ {1, . . . , T }. Let Si∧j be the fraction of loss events of flow i in which flow j = i also suffers packet loss, that is: T

Si∧j = Nij /Ni

(2)

where Nij = =1 di, dj, denotes the number of “common” loss events between i and j, i.e., loss events in which both flows experience packet loss2 . Note that 0 ≤ Nij ≤ min(Ni , Nj ), so: 0 ≤ Si∧j ≤ 1. Conversely, Sj∧i = Nij /Nj is the fraction of loss events of flow j in which flow i also experiences packet loss. Then, the overall synchronization ratio Sij of flows i and j is defined3 as [20]: Sij = max (Si∧j , Sj∧i )

B. Global loss synchronization The above metrics concern either a single TCP flow or a pair of flows. However, it could be more useful to measure the “global” synchronization on a bottlenecked path, i.e., taking into account all flows that suffer packet loss in a short time interval. For instance, one might expect that a higher global synchronization should correspond to more flows lowering their rate “at the same time”, which could possibly yield network instability and a lower link utilization. One possibility is to consider a global synchronization rate R ∈ [1/M, 1], similar to that in [26], measuring the proportion of flows in M losing packets during loss event : R =

(3)

This is illustrated by the example in Fig. 1, showing the timeline of loss events for two flows i and j. Each loss event is indicated by a cross; common loss events are highlighted by the dashed rectangles. In this case, we see that Ni = 5, Nj = 7 and Nij = 3, so: Si∧j = 3/5, Sj∧i = 3/7 and Sij = max (3/5, 3/7) = 3/5. A value Sij = 1 means that (at least) one of the two flows always suffers losses “simultaneously” (i.e., within ∆) with the other flow. Note finally that Sij = Sji ∀i, j. The synchronization rate λi of a flow i is defined [23] as the proportion of the total loss events at which i sees a packet loss, that is: T 1 Ni = di, (4) λi = T T =1

A value λi = 1 means that flow i is suffering packet loss every time there is a loss event. In the example of Fig. 1, assuming that there are no loss events other than those shown, we have: T = 9, λi = 5/9 and λj = 7/9. 2 More precisely, a loss event is said to be common to both flows if their respective losses take place in an interval of duration ≤ ∆, with ∆ on the order of the longest RTT, say. 3 Strictly speaking, the definition in [20] concerns only pairs of flows sharing a whole end-to-end path. However, if we assume that most losses take place in a single bottleneck, then such definition may be applied also to a more general case in which flows share only the bottleneck; this is indeed the case we will consider here.

978-1-4244-2219-7/08/$25.00 (c)2008 IEEE

The choice of one metric among the two is not a clear-cut one. Indeed, each metric reflects a different phenomenon. Note however that Sij and λi , λj are related through the following expression: Nij /T Nij /T Nij /T , = (5) Sij = max Ni /T Nj /T min(λi , λj )

M 1 dk, . M

(6)

k=1

Intuitively, R seems to be a “better” metric for capturing network oscillations than per-flow (λi ) or pairwise (Sij ) synchronization metrics, since it directly measures how many flows lower their windows in unison. Note however that the ¯ (i.e., averaging over all average global synchronization R ¯ = 1 M λk of the loss events) is equal to the average λ k=1 M individual (i.e., per-flow) synchronization rates λi : T M M T 1 1 1 ¯ ¯= 1 R dk, = dk, = λ T M M T =1

k=1

k=1

(7)

=1

IV. S IMULATION S CENARIOS To study the relationship between loss synchronization, buffer size and TCP version, simulations were run using the ns-2 network simulator compiled with the ns2linux patch [27]. Contrary to some other studies, we do not assume nor “force” a given level of synchronization—the simulation scenarios below were designed so as to try to avoid synchronization as much as possible (hence our choice of bidirectional traffic with staggered start-up times, randomly-generated background traffic, different propagation delays, etc.) We considered a dumbbell topology, with a single 5 Gb/s bottleneck link with 100 ms one-way delay connecting two routers. End-nodes are connected to one of the two routers with a link of bandwidth 200 Mb/s and one-way delay chosen at random between 5 ms and 75 ms. Node buffers

V. R ESULTS Figure 2 shows the CDF of the global synchronization rate R, for the four TCP variants considered and four buffer sizes. First note that, for large buffer sizes, all high-speed protocols yield a very high synchronization; this is especially so for BIC and H-TCP. For instance, with H-TCP and a buffer of size B = C × RTT , all flows suffered packet loss in more than 85% of the congestion epochs, resulting in all flows lowering their windows in a short time interval. Contrary to BIC, the CDF for both H-TCP and HSTCP shows a “step” for low values of R (R < 0.1); in other words, with both HSTCP and H-TCP there is a non-negligible (but small) number of loss events in which just a few flows—or even just a single flow—lose packets.

978-1-4244-2219-7/08/$25.00 (c)2008 IEEE

1

CDF

0.8 0.6

Rule of Thumb CxRTT/sqrt(N) 2000 Packets 50 Packets

0.4 0.2 0 0

0.2

0.4

0.6

0.8

1

0.8

1

0.8

1

Global Synchronization Rate (R)

(a) BIC. 1

CDF

0.8 0.6


0.4 0.2 0 0

0.2

0.4 0.6 Global Synchronization Rate (R)

(b) H-TCP. 1

CDF

0.8


0.6 0.4 0.2 0 0

0.2


(c) HSTCP. 1 0.8 CDF

corresponding to access links are generously sized to avoid congestion in those links. Buffers on the bottleneck link were sized as described below. All buffers are of the Drop-Tail type. For every scenario, 10 independent simulation runs were performed, each one corresponding to a simulated time of 2000 s. Measurements were done after a warm-up period of 200 s, so τ = 1800 s. We simulated two types of traffic simultaneously sharing the bottleneck: 2K long file transfers (K in each direction), all using the same TCP version (HSTCP, BIC, H-TCP or SACK), and web-like traffic using TCP Newreno. The latter consisted in 150 “small” flows in each direction, used as background traffic. These background flows are modeled as on-off processes, with exponentially-distributed “off” (thinking time) periods of mean 4 s alternating with “on” (activity) periods; the amount of data transferred during “on” periods follows a Pareto distribution with shape parameter 1.2 and mean 10 kB, 20 kB or 100 kB. The start time of each background flow (in seconds) was chosen randomly on the interval [0, 200], according to a uniform distribution. Long-lived connections were started successively (one in the “forward” direction, the next in the “backwards” direction, and so on) with an interstart time interval uniformly distributed in [1.6, 2.6] s. We considered two sets of scenarios, the first with K = 40 and the second with K = 25. In each set, we tested six different bottleneck buffer sizes B: 150000 packets (C × RTT ); 65000 packets (for H-TCP and HSTCP) or √ 38000 packets (for BIC), as per (1); 24000 √ packets (C ×RTT / K); 15000 packets (0.63 × C × RTT / K); 2000 packets as an intermediate value; and 50 packets (as in [11]). We do not claim that all these rules are suitable to the levels of statistical multiplexing or the protocols we have considered; rather, they were taken as reference points covering a wide range of buffer sizes. For space reasons, we will only show results for K = 40, but those for K = 25 are qualitatively similar. In the K = 40 case, every long-lived flow suffered at least one loss during τ in every simulation run, so M = K. Note that background flows’ losses are not considered for computing the synchronization metrics; in particular, loss events in which only background flows lose packets are not taken into account.

0.6 0.4


0.2 0 0

0.2


0.8

1

(d) SACK. Fig. 2.

CDF of the global synchronization rate R of long-lived flows.

For the three high-speed variants, it can also be observed that: (a) the 2000-packet, “medium-sized” buffer tends to decrease the level of synchronization; (b) a very small buffer results in a fairly low synchronization. Both effects are most salient with HSTCP. SACK shows a much lower synchronization than high-speed variants, except for the small-buffer case; also, in the case of SACK synchronization seems to increase with decreasing B (as long as the buffer is not too small); this effect can also be seen in the CDF of λ (not shown here due to lack of space; see [28] for details). With SACK, the proportion of loss events concerning a single flow (i.e., the value of the CDF for R = 1/M = 0.025) goes from ≈ 40% for a 150000-packet buffer to ≈ 25% for a 2,000-packet buffer. Average loss rates are shown in Fig. 3 for the four TCP variants and for the six buffer sizes we tested. Error bars indicate, for a given scenario, the minimum and maximum of the mean loss rate values observed across all simulations. Except for the small-buffer case, H-TCP experiences a much higher loss rate (up to 3-4 times higher) than all the other

−3

1.2

x 10

Loss Rate

1 0.8 0.6

BIC TCP HSTCP HTCP TCP SACK

0.4 0.2 0

50

2000

15000

24000

38000/65000 150000

Buffer Size (Packets)

Fig. 3.

Loss rate of long-lived flows.

Goodput (Mbps)

120 110 100 BIC TCP

90

HTCP

80

HSTCP

70 TCP SACK

60

50

2000

15000

24000

38000/65000 150000

Buffer Size (Packets)

Fig. 4.

Goodput of long-lived flows.

protocols. On the other hand, the goodput achieved by H-TCP is similar to that of BIC and HSTCP (see Fig. 4). Given that we do not control directly the loss rate, and that all protocols are subject to equivalent conditions (background traffic, etc.), it would seem that H-TCP is achieving a performance similar to that of BIC and HSTCP at the expense of many more “wasted” (i.e., lost) packets; also, recall from Fig. 2 that H-TCP is the protocol showing the highest synchronization, which could explain the higher loss rate. Figs. 3 and 4 illustrate nicely the difference in the response function [3] of SACK with respect to that of high-speed protocols: even though loss rates seen by SACK flows are much lower, the goodput of SACK is still lower than that of the other protocols. All these results are consistent with experimental measures of the response functions performed in [29]. Figure 4 presents the average goodput, as measured at the TCP receiving end. Error bars indicate, for a given scenario, the minimum and maximum of the mean goodput values observed across all simulations. We see that when B is set to the BDP, all high-speed protocols achieve almost the same goodput. Goodput decreases slowly with decreasing B, down to a value of B which is ≈ 10% of the BDP. For smaller buffers, goodput (for all TCP versions) drops quite sharply; the relative decrease is highest with SACK. Link utilization graphs (not shown for space reasons) are similar in shape to those of goodput, with utilization above 90% for all high-speed protocols when buffer size B is ≥ 10% of the BDP. This is consistent with what e.g. Barman et al. [30] found for HSTCP; interestingly, dependence of utilization on buffer size follows the same trend for the other two high-speed TCP variants. Remark that, in the case of high-speed protocols, high goodput and utilization are achieved (somewhat counterintuitively) in spite of having very high levels of synchronization, even for moderate-size buffers. In other words, it seems that high synchronization does not necessarily mean harmful oscilla-

978-1-4244-2219-7/08/$25.00 (c)2008 IEEE

tions or instability. This may be explained by the increased aggressiveness of high-speed flows: even if they lower cwnd in unison, since they decrease it by less than standard TCP and increase it quicker that standard TCP, they “compensate” for the increased synchronization and loss rate. Therefore, an important observation that may be made from the results on goodput and synchronization, is that loss synchronization metrics might not be useful performance indicators per se, at least when high-speed variants of TCP are concerned. This issue has to be further investigated. Figure 5 presents the CDF of the overall (pairwise) synchronization ratio S, for the four TCP variants and four buffer sizes as in Fig. 2; the CDF is computed from the values of Sij for all possible pairs of flows (i, j), i = j. It can be seen that, for both large and medium buffer sizes, S is always > 0.9 with H-TCP. In the case of BIC and with large buffers, pairwise synchronization is slightly lower than with H-TCP and slightly higher than that of HSTCP. We do not have yet a satisfactory explanation of the “step” seen in Fig. 5a, for the 24000-packet buffer. For the 2000-packet buffer, S decreases in a significant way for HSTCP where only 20% of values are > 0.8. Furthermore, with large buffers, SACK shows high pairwise synchronization levels which become smaller when buffer sizes decrease. Note finally that, globally, all these results are consistent with the trends shown in Fig. 2. VI. D ISCUSSION AND F UTURE W ORK In this paper we have presented some preliminary results on the relationship between drop synchronization, buffer sizes and high-speed TCP variants. One of our main goals was to study whether a more aggressive congestion control may yield (under similar conditions) a higher correlation between packet losses of different flows; our results suggest that this may well be the case. We are aware of the potential limitations of a simulationbased work like this one, especially when studying phenomena (like synchronization) sensitive to packet-level effects that may not always occur in the real world. Hence, we would like to perform similar tests using actual implementations of highspeed transport protocols in a network testbed. The observations made from the different metrics underline the relation that exists between buffer sizing and loss synchronization. We have seen that, with high-speed TCP variants, the latter decreases when the size of the bottleneck buffer decreases. We also verified that, with high-speed TCPs, router buffers can be made much smaller than C × RTT , even in the case of very high levels of loss synchronization, provided that a slight decrease in goodput is acceptable. Qualitatively, the three metrics R, S and λ seem to convey “almost the same information”, in the sense that similar trends can be observed in their respective CDFs. In realworld measurements, the choice of a particular metric may be motivated by practical considerations. For instance, in many cases it may not be possible to measure loss events of all flows at a bottleneck, so taking end-to-end measurements with a small set of test flows (as in [19]) would be the sole

1

CDF

0.8 0.6


0.4 0.2 0 0

0.2

0.4 0.6 0.8 Overall Synchronization Rate (S)

1

(a) BIC. 1

CDF

0.8 0.6


0.4 0.2 0 0

0.2


1

(b) H-TCP. 1

CDF

0.8 0.6


0.4 0.2 0 0

0.2


1

(c) HSTCP. 1

CDF

0.8 0.6


0.4 0.2 0 0

0.2


1

(d) SACK. Fig. 5.

CDF of the overall synchronization ratio S of long-lived flows.

alternative—in such a case, it would not be possible to directly assess neither R nor λ, only S. Thus, the relationship between the three metrics and performance parameters like goodput and link utilization deserves further study. Other issues worth exploring are the impact of: having much smaller RTT variations between high-speed flows; a lower degree of statistical multiplexing; higher levels of background traffic; the use of AQM in bottleneck routers. Also, the relation between drop synchronization and loss rates needs to be studied in more detail. Besides, it may be interesting to consider more complex topologies with multiple bottlenecks, in order to assess (as suggested by [19]) the possible correlation between synchronization, number of hops and RTTs. R EFERENCES [1] C. Villamizar and C. Song, “High performance TCP in ANSNET,” ACM SIGCOMM CCR, vol. 24, no. 5, pp. 45–60, Oct. 1994. [2] G. Appenzeller, I. Keslassy, and N. McKeown, “Sizing router buffers,” in Proc. of ACM SIGCOMM, Portland (OR), USA, Sep. 2004. [3] S. Floyd, “HighSpeed TCP for Large Congestion Windows,” Experimental RFC 3649, IETF, Dec. 2003.

978-1-4244-2219-7/08/$25.00 (c)2008 IEEE

[4] T. Kelly, “Scalable TCP: Improving performance in highspeed wide area networks,” ACM SIGCOMM CCR, vol. 33, no. 2, pp. 83–91, Apr. 2003. [5] C. Jin, D. Wei, and S. Low, “FAST TCP: Motivation, architecture, algorithms, performance,” in Proc. of IEEE INFOCOM 2004, Hong Kong, Mar. 2004. [6] L. Xu, K. Harfoush, and I. Rhee, “Binary Increase Congestion control for fast long-distance networks,” in Proc. of PFLDnet 2004, Argonne (IL), USA, Feb. 2004. [7] I. Rhee and L. Xu, “CUBIC: a new TCP-friendly high-speed TCP variant,” in Proc. of PFLDnet 2005, Lyon, Feb. 2005. [8] D. Leith and R. Shorten, “H-TCP: TCP for high-speed and long-distance networks,” in Proc. of PFLDnet 2004, Argonne (IL), USA, Feb. 2004. [9] K. Tan, J. Song, Q. Zhang, and M. Sridharan, “Compound TCP: A scalable and TCP-friendly congestion control for high-speed networks,” in Proc. of PFLDnet 2006, Nara, Japan, Feb. 2006. [10] D. Wischik and N. McKeown, “Part I: Buffer sizes for core routers,” ACM SIGCOMM CCR, vol. 35, no. 2, pp. 75–78, Jul. 2005. [11] G. Raina and D. Wischik, “Buffer sizes for large multiplexers: TCP queueing theory and instability analysis,” in Proc. of NGI 2005. Rome: IEEE, Apr. 2005, pp. 173–180. [12] M. Enachescu, Y. Ganjali, A. Goel, N. McKeown, and T. Roughgarden, “Part III: Routers with very small buffers,” ACM SIGCOMM CCR, vol. 35, no. 2, pp. 83–89, Jul. 2005. [13] M. Wang and Y. Ganjali, “The effects of fairness in buffer sizing,” in Proc. of NETWORKING 2007, Atlanta, May 2007. [14] G. Vu-Brugier, R. Stanojević, D. Leith, and R. Shorten, “A critique of recently proposed buffer-sizing strategies,” ACM SIGCOMM CCR, vol. 37, no. 1, pp. 43–48, Jan. 2007. [15] S. Shenker, L. Zhang, and D. Clark, “Some observations on the dynamics of a congestion control algorithm,” ACM SIGCOMM CCR, vol. 20, no. 5, pp. 30–39, 1990. [16] L. Qiu, Y. Zhang, and S. Keshav, “Understanding the performance of many TCP flows,” Computer Networks, vol. 37, pp. 277–306, 2001. [17] S. Floyd and V. Jacobson, “Random early detection gateways for congestion avoidance,” IEEE/ACM Trans. on Networking, vol. 1, no. 4, pp. 397–413, Aug. 1993. [18] K. Chandrayana, S. Ramakrishnan, B. Sikdar, and S. Kalyanaraman, “On randomizing the sending times in TCP and other window based algorithms,” Computer Networks, vol. 50, no. 3, pp. 422–447, Feb. 2006. [19] P. Jay, Q. Fu, and G. Armitage, “A preliminary analysis of loss synchronisation between concurrent TCP flows,” in Australian Telecommunication Networks and Application Conference (ATNAC), Melbourne, Dec. 2006. [20] S. Floyd and E. Kohler (eds.), “Tools for the evaluation of simulation and testbed scenarios,” Internet Draft draft-irtf-tmrg-tools, work in progress, Feb. 2008. [21] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “TCP Selective Acknowledgment Options,” Internet Standards Track RFC 2018, IETF, Oct. 1996. [22] S. Gorinsky, “Feedback modeling in Internet congestion control,” in Proc. of NEW2AN 2004, St. Petersburg (Russia), Feb. 2004. [23] R. Shorten and D. Leith, “Impact of drop synchronisation on TCP fairness in high bandwidth-delay product networks,” in Proc. of PFLDnet 2006, Nara (Japan), Feb. 2006. [24] S. Chen and B. Bensaou, “Can high-speed networks survive with DropTail queues management?” Computer Networks, vol. 51, no. 7, pp. 1763–1776, May 2007. [25] G. Raina, D. Towsley, and D. Wischik, “Part II: Control theory for buffer sizing,” ACM SIGCOMM CCR, vol. 35, no. 2, pp. 79–82, Jul. 2005. [26] F. Baccelli and D. Hong, “AIMD, fairness and fractal scaling of TCP traffic,” in Proc. of IEEE INFOCOM 2002, New York, Jun. 2002. [27] D. X. Wei and P. Cao, “NS-2 TCP-Linux: an NS-2 TCP implementation with congestion control algorithms from Linux,” in Proc. of WNS2. Pisa, Italy: ACM Press, Oct. 2006. [28] S. Hassayoun and D. Ros, “Loss synchronization, router buffer sizing and high-speed versions of TCP,” TELECOM Bretagne, Research report RR-2008001-RSM, Feb. 2008. [29] Y. Li, D. Leith, and R. Shorten, “Experimental evaluation of TCP protocols for high-speed networks,” IEEE/ACM Trans. on Networking, vol. 15, no. 5, pp. 1109–1122, Oct. 2007. [30] D. Barman, G. Smaragdakis, and I. Matta, “The effect of router buffer size on HighSpeed TCP performance,” in Proc. of IEEE GLOBECOM’04, 2004, pp. 1617–1621.