Characterizing the Effects of TCP’s Initial Window Runa Barik

Dinil Mon Divakaran†

Michael Welzl

Department of Informatics, University of Oslo, Oslo, Norway Email: [email protected]

Cyber Security and Intelligence, Institute for Infocomm Research, Singapore Email: [email protected]

Department of Informatics, University of Oslo, Oslo, Norway Email: [email protected]

Abstract—Given the mice-elephant phenomenon (where 80% of flows in number contribute to only 20% of traffic in volume) of TCP traffic, TCP’s slow-start algorithm plays an important role in today’s Internet. Designed to slowly probe the network for available bandwidth, the current standard mandates TCP flows to start with an initial window (IW) size of at most ten segments. Given the speed of the today’s networks, an IW of ten segments could be a good option; however, over years the IW value may need to be updated. This paper aids such future updates with a stochastic model that reveals the effects of IW on TCP traffic characteristics, queue length distribution, average packet loss probability, and response times of TCP flows. Our studies show that the optimal choice of IW for a flow depends on the bottleneck router’s buffer size, number of active TCP connections, bottleneck router’s link capacity, RTT, and flow size. We also observe that the IW value non-monotonously increases the number of RTTs required for flows to complete. Index Terms—TCP, initial window, mice, queueing model, response time

I. I NTRODUCTION Nearly 90% of the Internet traffic volume is carried by TCP, the transmission control protocol [9]. Moreover in the data center, TCP carries almost all the traffic [5]. Traffic measurement studies reveal that the flow size statistics in the Internet exhibit strong heavy-tail behavior — a small percentage of flows (large in size) contribute to a large percentage of the Internet’s traffic volume [23]. This is also referred to as the mice-elephant phenomenon, where 80% of the flows that contribute to 20% of the traffic are called mice flows and the remaining 20% are the elephant flows [15]. For mice (small) flows like web queries, HTTP requests, multimedia broadcasting and voice over IP, end users expect very short response times, while the response times for elephant (large) flows like large data transfer transactions, peer to peer file sharing, are expected to be larger by orders of magnitude. It can be argued that the current TCP/IP architecture is biased against small TCP flows, for the following reasons: •

The three-way handshake to initiate a connection and a four-way handshake to terminate a connection cause a significant overhead for a small flow.1

† Dinil Mon Divakaran was affiliated with the Indian Institute of Technology (IIT) Mandi while contributing to this work. 1 This has recently been addressed with TCP Fast Open, a method that uses a cookie to eliminate the three-way handshake [7], [18].

Small flows almost always complete in the slow-start phase and use little network bandwidth during slow-start. Thus they do not achieve optimal performance. • Small flows in the slow-start phase often do not have sufficient traffic to generate three duplicate ACKs, making timeouts the only loss detection mechanism available to a TCP sender, and timeouts significantly increase the completion time of small flows.2 • An increase in round-trip-time (RTT) due to large queueing delays hurts small flows more than large flows. For large flows, larger congestion window cwnd makes up for the increase in RTT, whereas this is not the case for small flows and the effect of a large RTT is quite perceivable. The bias against mice flows becomes more relevant today, with recent studies showing an increase in the mice-elephant phenomenon, with a stronger shift towards a 90-10 rule [9]. One of the main reasons for this bias is the small value of TCP’s cwnd. The congestion window size for a TCP flow at time t during the slow-start phase is given as cwnd = IW ×  t c b RT T 2 where IW is the initial window (IW) size of a TCP flow and RT T is the round-trip-time. As cwnd depends on IW, the IW can be considered as a factor that affects the response times of small TCP flows. Intuitively, the performance of small flows can be improved by increasing the IW size. In RFC2001 [21], it was proposed for TCP flows to start with an IW of one segment. To improve the response time of TCP flows, an earlier research work, in [17], proposed to increase the IW from one segment to three or four segments. The authors considered both long-lived (file transfer) and short-lived (web-browsing) TCP connections and simulated the effects using the ns-2 simulator. For performance evaluation, metrics like goodput, median delay, network power, link utilization, and packet drop rate were considered. More recently, Google has proposed to increase the value of the IW and in RFC 6928 [8], the upper bound for the IW is set to ‘min (10*MSS, max (2*MSS, 14600 bytes))’. Through large-scale Internet experiments, they quantified the response times using different values of the IW under different network conditions, varying network bandwidth, RTT, bandwidth-delay product (BDP), and the nature of the applications. The latency of flows improved significantly with a larger IW, even in a •

2 Work-arounds have recently been proposed to better cope with this effect (“tail loss”) [19].

low-bandwidth network. On the negative side, increasing the IW also results in an increased retransmission rate [11]. The setting of the IW is static and all flows have a single IW value. However, in the context of the mice-elephant phenomenon, our previous studies [1], [3], [4] showed that a large IW has a negligible effect on the response times of large flows, and a single constant IW value for all flows improves performance with respect to some metrics (including the completion time), but it does so by affecting other metrics such as the number of timeouts and the retransmission rate. Noting that a large IW for large flows is one of the causes for degradation, we concluded that a single IW value for all flows is not advisable. In this paper, we focus on how the response times of small TCP flows are affected by the IW. To study the effects of the IW on burstiness of TCP traffic, queue length distribution, network stability (in terms of average packet loss probability), and response times of TCP flows, we develop a stochastic model, the integrated packet-flow model, discussed in Section III. We quantify the effects of increasing the IW size on the batch size (cwnd) distribution of the TCP traffic. One way to characterize the burstiness of TCP traffic is to consider the batch-inter-arrival times and batch sizes. Here, we directly relate the burstiness of traffic produced by TCP to the expected batch size. To capture the burstiness at the router buffer, we consider an M X /M/1/B queue, with M X , the poisson arrival process of batches of variable size X, and B, the router buffer size. We derive the expected number of RTTs (response time) for a TCP flow in Section IV, using a model derived from the integrated packet-flow model. The number of RTTs that a flow needs depends on the average packet loss probability and flow size. The IW size for which a flow achieves the minimum number of RTTs is considered as optimal. Our studies reveal that the optimal choice of IW for a flow depends on network parameters such as bottleneck router’s buffer size, number of active TCP connections, bottleneck router’s link-capacity, RTT, and flow size. This motivates us to define IW as a function; furthermore, the IW for a new TCP connection can be a function of parameters at the endhost (flow size), obtained from the network, or obtained from both the network and end host. We produce all the results for analysis using a prototype of our model in Python. Our code emulates the behavior of TCP Reno, and computes the batch size distribution for a given flow size distribution. Then the code for the M X /M/1/B queueing model produces loss-event probability and average packet loss probability (describe later). We then iterate the process until we see a stable operating value for the average packet loss probability using fixed point approximation. Finally, we code for a path enumerating graph inherited from the TCP model to find the expected number of RTTs that a flow could take to finish its transfer. We do not consider the TCP connection setup and teardown procedures as well as the ACK behavior (usage of SACK or not, delayed ACKs etc.). The rest of the paper is organized as follows: Section II discusses related work. In Section III, we describe the integrated packet-flow model and compute different performance metrics

including the response times for flows (in Sec. IV). We finally summarize the paper in Section V. II. R ELATED W ORK To the best of our knowledge, the only existing model that focuses on the impact of the IW size on the completion time of short flows is presented in [4]. However, there are many experimental studies related to the IW. The authors of [20] also found that a fixed value of IW would be either too conservative or too aggressive depending on the congestion level and network characteristics such as buffer sizes, capacity of the bottleneck and deployment scenario. They propose a mechanism that sets the IW of each flow and using a pacing mechanism called “initial spreading”, which in turn uses the RTT estimated during the SYN/SYN-ACK exchange. Multipath TCP (MPTCP) is an extension to TCP that allows multiple paths to be used simultaneously to maximize resource usage and increase reliability [12]. The difficulties that arise with a static IW value also affect MPTCP during slow-start, e.g. when IW10 is used for all subflows. We investigated this problem in our previous work [2]. We developed a mechanism to set the IW size of each subflow based on the cwnd of already ongoing subflows, and we tested and evaluated the mechanism with both the CORE network emulator and the NorNet testbed.3 An algorithm was proposed in [22] for adjusting the IW of TCP connections over long timescales, based on the statistics of previous connections. This algorithm checks for IW losses only during the first slow-start phase of a connection. The IW is decreased (or increased) only when more (or less) than 95% of connections have IW losses. The number of previous connections considered for updating IW is quite large. An approach to set the IW for the Fast Startup TCP algorithm was proposed in [16], to improve the initial throughput of TCP flows, using the bottleneck link and access link bandwidth, and the bottleneck router’s buffer size. This proposal uses rate-based pacing in the first RTT of the slow-start phase. III. I NTEGRATED PACKET-F LOW M ODEL In this section, we describe the integrated packet-flow model and quantify the impact of increasing the IW on the network as well as on the end-host. First we formulate a TCP Reno model (in Sec. III-A), then we use a M X /M/1/B queueing model at the bottleneck router (in Sec. III-B), and finally, we measure the average packet loss probability at the bottleneck router for different values of the IW in the flows (in Sec. III-C). For simplicity, we do not consider timeouts in our model. A. TCP Model In our proposed stochastic TCP model (a modified version of the one proposed in [14]), the number of packets transferred by a flow is assumed to follow geometrical distribution, with a mean flow size S¯ = 1/q. The parameter q is the probability of a packet to be the last packet in a TCP flow. The model describing the TCP window dynamics is shown in Fig. 1. It is 3 http://www.nntb.no

Congestion Avoidance

L2

L3

LK/2

LK

LK+1

LW

loss E

reached ssthresh (W) without loss

Slow Start

8

7 6

6

5

DUPACK

5

7 6 5

DUPACK

6

5

DUPACK

4

4

4

4

3

3

3

2

2

1

Fig. 1: TCP model

a finite state machine (FSM) where each state corresponds to a state in TCP protocol, connected with probabilistic transitions that depend on the loss-event probability. The inputs to this model are the flow size distribution and the initial value of the loss-event probability, and the model derives the distribution of number of packets transmitted every RTT. The loss of packets in a flow is assumed to be due to triple duplicate ACKs (and not due to timeouts). In Fig. 1, the entry point to the TCP model is given by state E. The solid arrows represent either a transition from the slow-start (SS) phase to the congestion-avoidance (CA) phase in TCP protocol or transitions within the CA phase. The FSM has a special state, the so-called exit state, representing the completion of a flow transfer. The exit state can be reached from any state in the diagram and the transition is indicated by the dotted arrows. State E transfers a sequence of batches within the SS phase before transitioning to either the exit state or a state in the CA phase. State Li with i ∈ [2, ..., W ], W =maximum window size, represents a state with batch size i (linear growth) where the flow has at least i remaining packets. The parameters considered in the TCP model are: • q, the probability of a packet to be the last packet in a TCP flow, • p, the loss-event probability (probability of first loss in a window) Using the memoryless property of the Geometric flow size distribution, we can say: • the probability that more than i packets remain to be sent, Mq (i) = (1 − q)i , and, • the probability that exactly i packets remain to be sent, Rq (i) = q(1 − q)i−1 . 1) Transition Probabilities and Batch Size Distribution: Here we describe transition probabilities necessary to solve the TCP model, and explain how to compute the batch size sent in each state. a) Slow-Start without loss before flow completion: Let the IW of a TCP flow be y. The maximum number of packets sent in state E is given by      log W +1 2 y − 1 + W. h(W, y) = y 2 If more than h(W, y) packets remain to be sent, a transition occurs from E to LW +1 with transition probability (1 − p)h(W,y) Mq (h(W, y)), generating a sequence of batches

8 7

8

8 7

cwnd=2

ACK

ACK

Drop

3

2

2

1

1

1

cwnd=3

cwnd=4

cwnd=4

Fig. 2: Window size evolution for 3

rd

packet loss in state E

{y, 2y, 22 y, ..., W }, else the connection makes a transition to the exit state with transition probability (1 − p)j Rq (j) for j ∈ [1, h(W, y)]. b) Slow-Start with loss before flow completion: If a loss occurs to the j th packet sent in state E, then before detecting loss, the window, cwnd, grows to size, y + j − 1 (see Fig. 2 for an example where y = 2 and j = 3). The maximum number of packets that can be transfered into the network is d = j − 1 + cwnd. The TCP connection makes a transition to state Lx where x = max(2, b(cwnd/2)c) in the CA phase with probability (1 − p)j−1 pMq (d) if more than d packets remain to be sent. Otherwise, it exits SS with probability (1 − p)j−1 pRq (j − 1 + k) where k < d − j + 1. c) Congestion-Avoidance without loss before flow completion: A connection in state Li generates at most i packets. If the remaining packets are more than i when the connection is in state Li , then a transition occurs to state Li+1 with probability (1 − p)i Mq (i), or else the connection jumps to the exit state with probability (1 − p)j Rq (j), where j ∈ [1, i]. d) Congestion-Avoidance with loss before flow completion: Let a loss occur to the j th packet sent in state Li . If x ≤ i packets remain to be sent, the connection jumps to the exit state with probability (1−p)j−1 pRq (x). If x ≤ (i+j −1) packets remain to be sent, then the connection jumps to the exit state with probability (1 − p)j−1 pRq (i + k) where k is the number of ACKs received in the next RTT. If x > i + j − 1 packets remain to be sent, then the connection makes a transition to state Lt , where t = max(2, bi/2c) with probability (1 − p)j−1 pMq (i + j − 1)). All the transition probabilities and conditions are shown in table I. Let Λe = {Λesi } be a row vector where the only non-null entry is ΛeE = χ (the rate at which new connections start). Λe represents the external arrival rates to the states of the finite state machine. Λt = {Λtsi } is a row vector that represents the total arrival rates to the states and P = {P (si , sj )} is the transition probability matrix. The flow balance equation of this model is Λt = Λe + Λt P , from which Λt = Λe (I − P )−1 . Let B(si , sj ) be the set of batch sizes produced by a connection moving from state si to state sj . The rate, λb (X), at which batches of size P X are sent to thet network can be represented as, λb (X) = i , sj ). The total sending si ,sj :X∈B(si ,sj ) Λsi P (s P rate of batches is denoted by λt = X λb (X). Let the batch . size distribution be denoted by g(X) = λbλ(X) t Figures 3(a) and 3(b) represent the batch size distributions

TABLE I: Transitions of the TCP finite state machine

si Li Li Li Li Li E E E E

sj Li+1 − − − Lt LW − Li −

P (si , sj ) (1 − p)i Mq (i) (1 − p)j Rq (j) (1 − p)j−1 pRq (k) (1 − p)j−1 pRq (i + k) (1 − p)j−1 pMq (i + j − 1) (1 − p)h(W,y) Mq (h(W, y)) (1 − p)j Rq (j) (1 − p)j−1 pMq (d) (1 − p)j Rq (j − 1 + k)

batches i j k i, k i, j − 1 h(W, y)∗ j∗ d∗ j − 1 + k∗

condition 2≤i
* represents a series of batches.

for a given flow size distribution based on different IW sizes. Here the mean flow size S¯ is set to 20 packets, with unit flow arrival rate. The initial value for the loss-event probability, p = 0.01 [14]. The ssthresh is 100 packets and IW values are 3, 8, 10, 16, 32 and 64 packets for the TCP model. We use these values for rest of the plots. B. Queueing Model To study the burstiness of TCP traffic, an M X /M/1/B model can be used as a queueing model at a router with finite buffer capacity B [6], [10]. The arrival process follows a Poisson process with batch arrival rate as λ and the service process follows an exponential distribution with mean service time 1/µ. The batch size follows the distribution g(X) as described above. The traffic intensity can be expressed as ρ = E[X] µλ . Fig. 4 shows the M X /M/1/B model. The steady state equations can be written as. B   X P0 λ = µP1 , Pk = 1, k=0 min(B−n,W )

 Pn µ +

X

 λg(j) = µPn+1

j=1 min(n,W )

+

X

 λg(j)Pn−j , ∀1 ≤ n < B.

j=1

1) Arrival Rate as a Function of the Number of TCP Flows: We consider the case of homogeneous TCP sources. Let N be the number of TCP connections under consideration. We assume that a TCP source sends a window of packets in each round. We also consider that the connection never faces timeouts. The batch-arrival rate corresponding to a TCP connection is RT1 T . Thus, the total batch-arrival rate from N TCP N connections is given by, λ = RT T . From the above, we can write ρ ∝ E[X] for a fixed number of active TCP connections. Fig. 7(a) shows the average batch size for different IW sizes with N set to 10. It shows that the burstiness of TCP traffic increases with large IW values. Also the traffic intensity at the bottleneck router increases with large IW values. C. Fixed Point Approximation Fixed point approximation can be applied to jointly solve the TCP model, queueing model, and to find a stable operating

value for the average packet loss probability at a bottleneck router [13]. Given an initial loss-event probability, the batch size distribution of packets is obtained from the TCP model. Batch sizes are then fed into the queue to compute both the loss-event probability and the average packet loss probability. The loss-event probability is circulated between the TCP model and the queueing model until a stable operating value for the average packet loss probability is reached. The TCP window dynamics mainly depend on the loss-event probability rather than the average packet loss probability. The average packet loss probability among all the transmitted packets, p¯, can be computed as E[X]λ(1 − p¯) = µ(1 − P0 ), (1 − P0 ) , p¯ = 1 − ρ

(1)

where the left-hand side of the equations represents the net arrival rate (with loss) and the right-hand side of the equations represents the net departure rate (with a non-empty queue). Next, what we need is the probability that a batch of size i X can traverse the queue loss-free using the M /M/1/B model, PB−i and this probability is given by PB (i) = j=0 Pj . The lossevent probability p can be obtained by equating the average probability that a batch of batch size i is generated by the TCP model, and that this batch can pass the queue loss-free [14]:   i X   W W X P X =i 1−p = P X = i PB (i). (2) i=1

i=1

Figures 3(c) and 3(d) show the queue length distributions for the batch size distributions in Fig. 3(a) for different values of IW. The queue length distribution decays slowly with an IW of 3. However, the distribution shifts towards the right with a large IW, which is due to the traffic intensity being larger than unity (arrival rate > service rate). With an IW of 8, the traffic intensity gets close to unity (ρ = 1.09), i.e. the queue length is mostly indifferent to the traffic intensity. To assess the influence of buffer size on the choice of IW value, in Fig. 5(a), we illustrate the average probability that a batch of certain size can traverse the queue without being dropped, for varying buffer sizes of the queue. The figure shows that batches generated for a flow with smaller IW size have higher chance of traversing the queue without a loss for

1

0.5 0.4 0.3 0.2 0.1

0.6 0.5 0.4 0.3 0.2 0.1

0

0.01 0.001 0.0001 1e-05

0 0

20

40

60

80

100

1 IW=3 IW=8 IW=16

0.1

1e-06 0

20

batch size (in packets)

40

60

80

100

IW=3 IW=10 IW=32

0.1 0.01 0.001 0.0001 1e-05 1e-06

0

20

40

60

80

100

120

0

20

queue length (in packets)

batch size (in packets)

(a) Batch size distribution

Probability density function

0.6

IW=3 IW=10 IW=32

0.7

Probability density function

IW=3 IW=8 IW=16

0.7

Probability density function

Probability density function

0.8

(b) Batch size distribution

40

60

80

100

120

queue length (in packets)

(c) Queue length distribution

(d) Queue length distribution

average packet loss probability

Fig. 3: Batch size and Queue length distributions for IW of 3, 8, 10, 16, 32 and 64 packets, with N = 10, BDP = 110, buffer size=125

Probability of success

1

λg(W) λ g(2) λ g(W) λ g(1) 0

λg(1) 1

µ

λg(1) 2

W

λg(1) W+1

B−1

B

0.9 0.8 0.7

BDP=34 packets, N=1

0.6 0.5 IW size=3 IW size=8 IW size=10 IW size=16 IW size=32

0.4 0.3 0.2 0

µ

µ

10

20

30

40

50

60

buffer size (in packets)

µ

70

80

1

N=1 N=10

0.1

BDP=buffer size=66 packets 0.01 3

8

10

16

32

64

IW size (in packets)

(a) Average success probability of batch,(b) Comparing packet loss by varying N traversing the queue and IW size

Fig. 4: M X /M/1/B Queueing model

Fig. 5: In (a), BDP is 34 and N = 1; in (b), BDP and buffer size are set to 66. [[C[0,3](0),C[0,3](1)], . . .]

0

1

2

[[2,1]]

3

[[3,1]]

n [[n,1]]

Fig. 6: Path enumerating graph

smaller buffer sizes. In Fig. 5(b), we present the average packet loss probability for N set to 1 and 10 connections, for different values of IW size. Congestion windows of flows generated from smaller values of IW size cause fewer drops. With higher values of N , the average packet loss probability increases. Fig. 7(b) shows the average packet loss probability with different IW values, with N set to 10. It shows that the average packet loss probability increases when the IW is large. A large IW increases the burstiness of the TCP traffic which causes a large number of packets to be dropped at the bottleneck router. The average packet loss probability will further increase with the number of TCP flows. IV. P ERFORMANCE OF FLOWS In this section, we evaluate the performance of flows by computing the average number of RTTs required for a flow to complete. Fig. 6 represents the available FSM paths that a flow could take to finish its transfer, and we use them to find the expected number of RTTs. The figure is derived from the TCP window dynamics model (in section III-A) where each node in the graph corresponds to a state in the TCP model. Node 0 corresponds to state E, node 1 represents L2 , node 2 represents L3 , etc. Edge eij corresponds to the transition

between states i and j. C[i, j] represents an array of 2-tuples, where each tuple contains the number of packets transferred from state i to state j and the number of RTTs. Let d0j be the cost of a path from node 0 to node j. Formally, we can write d0k = d0j + C[j, k], ∀j > 0, where k is the destination node. For simplicity, we assume each path is equally probable, P i Ri , and find the expected number of rounds (RTTs), Lr = len(R) using the recursive function ‘ComputeRound’ in Algorithm 1. Let Er be the number of rounds that a flow may have during its lifetime. Let Nr be the number of rounds without packet loss, assuming the flow may finish within its slow-start phase and is given by Nr = dlog2 ( ys + 1)e, where y is the IW and s is the flow size. Then we can write Er = p¯×Lr +(1− p¯)×Nr . Fig. 7(c) plots the number of RTTs against the size of the IW for different flow sizes. For a flow size of 30 packets, the minimum number of RTTs is achieved with an IW (and hence, the optimal IW) of 10 (packets); however, for a flow size of 70 packets, the number of RTTs increases with increasing IW. Here, any flow with flow size less than or equal to 30 packets, is considered to be a “small flow”, and with a size greater than 30 packets is considered to be a “large flow”. Fig. 7(d) plots response times for both small and large flows (in terms of RTTs) against the IW. Small flows show better response times with an IW of 10 or 16 packets while large flows had better response times with 8 or 10 packets. An IW of 10 packets yields the minimum number of RTTs for both small and large flows. V. C ONCLUSIONS We developed an integrated packet-flow model to study the effects of the IW on the burstiness of TCP traffic, the queue length distribution and the average packet loss probability. Our

20 15 10 5 3

8

10

16

32

IW size (in packets)

(a) Average batch size

64

12 10

0.6

0.4

12

flow size=30 packets flow size=50 packets flow size=70 packets

Number of RTTs

25

1

0.8 Number of RTTs

Average packet loss probability

Average batch size (in packets)

30

8 6 4

0.2

2

0 3

8

10

16

32

64

IW size (in packets)

(b) Average packet loss probability

small flows large flows

10 8 6 4 2

3

8

10 16 IW size (in packets)

32

64

3

8

10

16

32

64

IW size (in packets)

(c) For different flow sizes

(d) For both small and large flows

Fig. 7: For IW sizes of 3, 8, 10, 16, 32 and 64 packets; N = 10, BDP = 110, buffer size=125 packets.

Algorithm 1 ComputeRound(C, x, r, i) Input: • x is the remaining amount of data of a flow that still needs to be transferred, • r is the number of rounds completed for the already transferred portion of the flow, and is initially set to 0, • i is the initial state, Output:R is the array that contains all possible numbers of rounds, one for each path. 1: if x = 0 then 2: append r to R 3: else if x < number of packets sent in last round then 4: append r + 1 to R 5: else 6: for each adjacent node j do 7: if C[i, j](0) 6= 0 and x − C[i, j](0) >= 0 then 8: ComputeRound(C, x−C[i, j](0)), r+C[i, j](1), j) 9: end if 10: end for 11: end if

model confirms that the burstiness of TCP generally increases with increasing IW. It also shows that the overall impact of the IW (and with it, the impact on the response time of TCP flows) additionally depends on the bottleneck router’s buffer size, the number of active TCP connections, the bandwidthdelay product and the flow size. This motivates us to suggest using the IW as a function; furthermore, the IW for a new TCP connection can be a function of parameters at the endhost (flow size), obtained from the network, or obtained from both the network and the end-host. In our performance evaluation using this model, we derived the average packet loss probability (and with it, the response time TCP flows) for a finite number of homogeneous TCP sources. We observed a non-monotonous behavior of the number of RTTs (response time) for both small and large flows, indicating that the relationship between the TCP response time and the IW is non-trivial, underlining the need for our model. A limitation is that we do not consider timeouts. Future work includes extending it such that it also covers cases of heavy packet loss and “tail losses” [19].

R EFERENCES [1] R. Barik and D. M. Divakaran, “Development and Experimentation of TCP Initial Window Function,” in 2014 NOF, Dec 2014, pp. 1–5. [2] R. Barik, M. Welzl, S. Ferlin, and O. Alay, “LISA: A linked slow-start algorithm for MPTCP,” in IEEE ICC, May 2016, pp. 1–7. [3] R. Barik and D. M. Divakaran, “TCP Initial Window: A Study,” in Proc. WWIC, 2012, pp. 290–297. [4] ——, “Evolution of TCP’s Initial Window Size,” in 38th Annual IEEE LCN 2013, Sydney, Australia, Oct. 2013. [5] T. Benson, A. Akella, and D. A. Maltz, “Network traffic characteristics of data centers in the wild,” in Proc. of IMC, 2010, pp. 267–280. [6] K. Chandrayana, B. Sikdar, and S. Kalyanaraman, “Scalable configuration of RED queue parameters,” in High Performance Switching and Routing, 2001 IEEE Workshop on, 2001, pp. 185 –189. [7] Y. Cheng, J. Chu, S. Radhakrishnan, and A. Jain, “TCP Fast Open,” RFC 7413 (Experimental), Internet Engineering Task Force, Dec. 2014. [8] J. Chu, N. Dukkipati, Y. Cheng, and M. Mathis, “Increasing TCP’s Initial Window,” RFC 6928 (Experimental), IETF, Apr. 2013. [9] D. Collange and J.-L. Costeux, “Passive estimation of quality of experience,” J. UCS, vol. 14, no. 5, pp. 625–641, 2008. [10] P. Dirnopoulos, P. Zeephongsekul, and Z. Tari, “Modeling the burstiness of TCP,” in MASCOTS 2004, oct. 2004, pp. 175 – 183. [11] N. Dukkipati, T. Refice, Y. Cheng, J. Chu, T. Herbert, A. Agarwal, A. Jain, and N. Sutin, “An argument for increasing TCP’s initial congestion window,” SIGCOMM CCR, vol. 40, pp. 26–33, Jun. 2010. [12] A. Ford, C. Raiciu, M. Handley, and O. Bonaventure, “TCP Extensions for Multipath Operation with Multiple Addresses,” RFC 6824 (Experimental), IETF, Jan. 2013. [13] M. Garetto, M. Marsan, M. Meo, and R. Cigno, “On the use of fixed point approximations to study reliable protocols over congested links,” in GLOBECOM ’03. IEEE, vol. 6, dec. 2003, pp. 3133 – 3137. [14] M. Garetto and D. Towsley, “An efficient technique to analyze the impact of bursty TCP traffic in wide-area networks,” Perform. Eval., vol. 65, no. 2, pp. 181–202, Feb. 2008. [15] J. R. Iyengar, O. L. Caro, and P. D. Amer, “Dealing with Short TCP Flows: A Survey of Mice in Elephant Shoes,” Uni. of Delaware, 2003. [16] S. Kodama, M. Shimamura, and K. Iida, “Initial CWND determination method for fast startup TCP algorithms.” in IEEE IWQoS, 2011. [17] K. Poduri, T. Implementers, K. Nichols, and D. tcpimpl-poduri . Txt, “Simulation Studies of Increased Initial TCP Window Size,” 1998. [18] S. Radhakrishnan, Y. Cheng, J. Chu, A. Jain, and B. Raghavan, “TCP Fast Open,” in Proceedings of the 7th ACM CoNEXT ’11, 2011. [19] M. Rajiullah, P. Hurtig, A. Brunstrom, A. Petlund, and M. Welzl, “An Evaluation of Tail Loss Recovery Mechanisms for TCP,” SIGCOMM Comput. Commun. Rev., vol. 45, no. 1, pp. 5–11, Jan. 2015. [20] R. Sallantin, C. Baudoin, E. Chaput, F. Arnal, E. Dubois, and A. L. Beylot, “Reducing web latency through TCP IW: Be smart,” in 2016 IEEE ICC, May 2016, pp. 1–6. [21] W. Stevens, “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms,” RFC 2001 (Proposed Standard), Internet Engineering Task Force, Jan. 1997, obsoleted by RFC 2581. [22] J. Touch, “Automating the Initial Window in TCP,” Internet Draft (Standards Track), Jul. 2012. [23] C. Williamson, “Internet traffic measurement,” IEEE Internet Computing, vol. 5, no. 6, pp. 70–74, Nov. 2001.