Daniel Zaragoza

The TCP-modified Engset Model Revisited

Keywords: TCP modeling, short connections, superposition, slow start, limited receiver window

We revisit the TCP-modified Engset model proposed by Heyman et al. in [1]. The model deals with the superposition of a limited number of TCP connections alternating between file transmission and silence in a web-like fashion. We consider homogeneous sources only. (a) We take into account the effects of slow start and limited receiver window as well as small average file sizes. (b) We propose an alternative way for calculating the average connection rate in the superposition. (c) From the model we propose a way for calculating the queuing behavior; i.e., the overflow probability. (d) From this last point, we propose a new link buffer sizing rule. Comparison with extensive simulations shows that the average rate and duration, as well as, link utilization are accurately predicted for exponentially distributed file sizes. For longer tail distributions, the model remains accurate provided the receiver window is adjusted appropriately. The accuracy increases with increasing load. As concerns the queuing behavior, the same observation applies. Finally, the revisited model cannot be used to predict losses larger than about 1%. The model overestimates loss rates above that threshold.

Introduction

In the present work, we revisit the TCP-modified Engset (TCP-Engset for short) model proposed by Heyman, Lakshman, and Neidhardt in [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF]. The model deals with the performance of a superposition of Transmission Control Protocol (TCP) connections alternating between file transmission and silence periods in a web-like or ON-OFF fashion. File sizes and OFF periods are random variables. Connections share a common multiplexing link. The number of connections simultaneously active is limited to a maximum. The main idea of the model is that competing TCP connections share the bottleneck capacity equally in times of congestion.

Connections are homogeneous meaning that all parameters are the same for all sender-receiver pairs: file size distribution, round trip time, ingress and egress links, packet size, etc. Throughout the report the OFF periods are exponentially distributed with an average of 1 second.

The contributions of the present work are: (i)

We take into account the effects of slow start and limited receiver window in the calculation of the single connection rate and ON time. We also take into account small average file sizes. (ii)

We propose an alternative way of calculating the average connection rate. Extensive simulations show that taking the average of the two ways give more accurate results than either one alone. (iii) We propose a simple way of determining the queuing behavior. (iv)

Related work

We discuss here related work on the modeling of short TCP connections.

The most directly related work is the paper by Heyman, Lakshman, and Neidhardt [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF], where the TCP-Engset model has been first proposed. Their equation ( 25) is at the heart of the model. In words, the model assumes perfect capacity sharing between active sources whenever their number is larger than the ratio of the output to input link capacities. The authors derive a buffer sizing rule for windowsynchronized TCPs in congestion avoidance under different drop policies so that the link is fully utilized; see their equation (22). For tail-drop policy, we call this rule the BDP-rule. They consider extensions of the model with multiple classes of users having the same access link capacity. They also discuss insensitivity properties.

Our starting point is the capacity sharing idea and the state probabilities calculation from [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF]. The differences of the present work with [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF] are as follows (See section 4.1 and Table 11 for details). We consider only homogeneous sources. First, we consider small or very small average file size and include the effects of slow start and limited receiver window. Second, we propose an alternative way of calculating the average connection rate. It turns out that taking the average of the two ways give more accurate results. Third, we propose a way to evaluate the queuing behavior which leads us to a buffer sizing rule that is different from the BDP-rule.

Less directly related works are summarized by Bonald in chapter 2 of [START_REF] Bonald | Evaluation de Performance des Réseaux de Données[END_REF]; see also the included references. The model could be called TCP-modified Erlang as connections arrive according to a Poisson process and congestion/blocking is replaced by capacity/resource sharing. We do not discuss here the relationship between the TCP-Engset and TCP-Erlang models.

To conclude this section, we note that the number of TCP variants in operation on the Internet has greatly increased between the measurements performed by Medina et al. [START_REF] Medina | Measuring the Evolution of Transport Protocols in the Internet[END_REF] in 2005 and those performed by Yang et al. [START_REF] Yang | TCP Congestion Avoidance Algorithm Identification[END_REF] in 2011 (their figure 1 presents a nice synthetic overview of TCP congestion controls). From Rewaskar et al. [START_REF] Rewaskar | A Performance Study of Loss Detection/Recovery in Real-world TCP Implementations[END_REF] we learn that implementations in the popular operating systems Linux and Windows have a of 200 ms instead of the 1 second specified in the standard (see next section). The 'vagaries' of real world transfers using TCP are analyzed by Qian et al. [START_REF] Qian | TCP Revisited: A Fresh Look at TCP in the Wild[END_REF]. Overall, the papers mentioned here tend to indicate that the job of modeling the performance of TCP will be a tough one.

Definitions

We provide here background on TCP, the file size distributions we use, the network settings, and the simulation setups.

TCP background

In this section we develop the aspects of TCP that are the most relevant to our purpose. (i) TCP is a window-based transport protocol. (ii) It provides flow-control. (iii) It provides congestion control via the slow start and congestion avoidance algorithms. (iv) Retransmission timeouts are important for its performance. Finally, (v) the sending of new data is triggered by the arrival of acks within the timeout limit.

The relevance to our purpose of modeling the performance of 'short' transfers is as follows. First, when no packets are dropped, a connection proceeds in slow start until either the transfer is complete or the receiver window is reached. In slow start without delayed acks, a TCP sends two packets for each ack received, which means that two packets are sent for one leaving the network. When the receiver window is reached the correspondence is one for one. When a capacity mismatch exists between input(s) and output(s) at a multiplexing node the slow start algorithm puts some 'stress' on the buffer of the node. This 'stress' also depends on the RTT of the connection, the smaller the RTT the greater the 'stress', see section 4.4. On the other hand, the smaller the RTT the faster a connection completes. Second, when packets can be dropped -here, only due to buffer overflow -, a connection is particularly 'fragile' at the beginning and at the end where a TO can occur. Finally, the arrival of data packets (at the receiver) and acks (at the sender) need not be regular for the proper operation of TCP; therefore, TCP traffic is said to be 'elastic'.

RFC4614, [START_REF] Rfc | A Roadmap for Transmission Control Protocol (TCP) Specification Documents[END_REF], provides a roadmap to TCP-related documents, as of 2006. Documents of interest here that update previous ones cited in RFC4614 are: RFC5681, [START_REF] Rfc5681 | TCP congestion Control[END_REF], -TCP congestion control -, RFC6582, [START_REF] Rfc6582 | The NewReno Modification to TCP's Fast Recovery Algorithm[END_REF] -TCP NewReno -, and RFC6298, [START_REF] Rfc6298 | Computing TCP's Retransmission Timer[END_REF] -TCP RTO calculation.

TCP is first specified in RFC793, [START_REF]Transmission Control Protocol[END_REF]; further details are clarified in RFC1122, [START_REF] Braden | Requirements for Internet Hosts --Communication Layers[END_REF].

TCP is a window-based protocol that provides a reliable, byte-oriented, data transfer between processes which, most commonly, run on different computers (hosts) themselves located on different networks. In the original specification, TCP can send and receive variable-length "segments". However, most implementations refrain from sending variable length segments unless some conditions are met, e.g., sending a segment empties the send buffer or the Nagle's algorithm is disabled [START_REF] Wright | TCP/IP Illustrated, The Implementation[END_REF].

TCP provides reliability "by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted." Further, "The sequence number of the first octet of data in a segment is transmitted with that segment and is called the segment sequence number. Segments also carry an acknowledgment number which is the sequence number of the next expected data octet of transmissions in the reverse direction." How the timeout is calculated is specified in RFC6298 and is discussed below. In the present work, we use a TCP that is packet-oriented; that is the basic unit of transmission is the packet rather that the octet.

TCP is a window-based protocol which provides flow control to avoid a sender overwhelming a receiver. For that purpose, "The receiving TCP reports a "window" to the sending TCP. This window specifies the number of octets, starting with the acknowledgment number, that the receiving TCP is currently prepared to receive." At the sender and at any time, the amount of data outstanding and not yet acknowledgeda.k.a. the "flight size" -is , where , is the sequence number of the next unit to send and is the sequence number of the still unacknowledged unit. Under no circumstances and at no time , where is the receiver window, a.k.a. . is not necessarily fixed and varies according to the speed at which the application "reads" the received data during the course of a connection. Note that changes only with advancing acks, while increases when sending new data and temporarily decreases back to when retransmitting missing data.

A form of indirect/implicit flow control may also exist at the sender. RFC793 states: "When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted. In practice, implementations [START_REF] Wright | TCP/IP Illustrated, The Implementation[END_REF], maintain a "send buffer" (a.k.a. the socket buffer) which contains the unacknowledged data and which is fed with data from the user buffer; see also Figure 2 below. The size of this buffer may have impact on the TCP performance. In the present work we do not deal with this matter and assume ideal operation at the sender.

TCP also provides congestion control (RFC5681) by way of the slow-start and congestion avoidance algorithms. For that purpose two new variables are used: the congestion window, and the slow-start threshold, ssthresh, noted here. A TCP switches between slow-start and congestion avoidance according to the relative values of and . More precisely, "The slow start algorithm is used when cwnd < ssthresh, while the congestion avoidance algorithm is used when cwnd > ssthresh. When cwnd and ssthresh are equal, the sender may use either slow start or congestion avoidance." Further, "The initial value of ssthresh SHOULD be set arbitrarily high (e.g., to the size of the largest possible advertised window), but ssthresh MUST be reduced in response to congestion." Here, we use congestion avoidance when meaning that . Rephrasing RFC5681, during slow-start is increased by one for each increasing ack received; during congestion avoidance is increased by one for each of increasing acks received. To improve performance when the receiver acknowledges every other segment and to discourage misbehaving receivers, a TCP may use Appropriate Byte Counting as per RFC3465, [START_REF] Allman | TCP Congestion Control with Appropriate Byte Counting (ABC)[END_REF]. In our TCP, the receiver acknowledges every segment received and the sender counts the increasing arriving acks before increasing the congestion window in congestion avoidance; this is to avoid numerical rounding errors.

The sending of data (new or retransmission) by TCP is governed by the following equations.

min ,

), , and .

(

) 1
Where is the amount outstanding ("FlightSize") when the sending TCP function (e.g., tcp_output()) is called, is the amount to send, starting from . When a group of packets are to be sent, i.e., when , these are sent within a software loop at 'code speed' [START_REF] Wright | TCP/IP Illustrated, The Implementation[END_REF] with no network-dependant spacing between packets. Although proposals such as TCP-pacing have been made, these studies remain theoretical with no active specification or commercial implementation to our knowledge. This mode of operation has implications on the burstiness of the traffic produced by a TCP. These implications are well-known and recommendations in RFC6582 are made to limit the possible bursts of packets sent at once, for example, using an additional variable . In the present report, , and are in unit of packets (segments). Further, as never changes, we set ( * ). No attempt is made to limit the data bursts.

TCP uses two methods to detect missing data: retransmission timeout and duplicate acks.

When the retransmission timer fires, a timeout occurs and , , thus and the missing packet is retransmitted. If this is the first retransmission of the packet, m in / , . is left unchanged in case of multiple retransmissions of the same packet. The connection proceeds in slowstart mode. As a consequence, duplicate packets can be sent after a timeout; duplicates can also be lost, though.

The second method is via duplicate acks, typically three, which means that four consecutive acks request the same sequence number. From RFC6582, "After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire." This is called fast retransmit. We abbreviate this event as TD, for Triple Duplicate acks. "After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives." We abbreviate fast recovery as FR. When a TD occurs, min / , (same as for timeouts), and the missing packet is retransmitted. The previous value of is restored to allow the sending of new data with further arriving DAs and . Note that no new data is sent here even if it were possible (specifically, when ). For each subsequent duplicate ack received, and new data may be sent. Finally, "When the next ACK arrives that acknowledges previously unacknowledged data, a TCP MUST set cwnd to ssthresh (the value set in step 2). This is termed "deflating" the window." At this point, depending on the TCP version used, FR occurs or not, more details are given below. Assume FR occurs; thus, . "Normal" operation resumes, that is, is increased either to / if or to if and new data is sent depending on being positive. In both cases, the connection proceeds in congestion avoidance mode.

If any one of the retransmissions is also lost then FR does not occur, instead, a timeout follows. We do not address this matter here.

For TCP Reno, FR occurs on receipt of the first ack requesting unacknowledged data. The loss of only one packet in the previous window of data has no further consequence. If there were drops, then another TD or a timeout follows. Under the assumption , let be the window at which drops occur, let be the distance, in packets, between the first two drops, if then a timeout follows; otherwise, a TD follows if, in turn, enough acks return from the new packets sent during the TD-FR period.

For TCP NewReno (RFC6582), FR occurs when all data outstanding at the time TD occurred is acknowledged. Note that the loss of the new data sent between TD and FR lead to a new congestion event. Because NewReno is used in the present report, we give an example of operation in Figure 1. Without loss of generality for the present purpose, we renumber the first loss as '1' and resynchronize time. When TD occurs (on the arrival of the ack from '5'), the missing packet is retransmitted, , and both and are adjusted. is large enough and does not change so that . The flag . On receipt of the subsequent ack (from '6'), new data is sent. When the first loss is recovered, FR is not yet over for NewReno. Following RFC6582, the missing packet is retransmitted and a new data packet is sent. Further new data is sent on receipt of the ack from '7', which was new also. FR is over on the receipt of the acknowledgement ; , ; normal operation resumes and new data is sent. In the same RTT, the receipt of the ack from '8' will lead to / as it must in congestion avoidance. For the purpose of collecting further statistical data on TOs and TDs, we record the highest sequence number sent during the TD-FR period in the variable _ ; if one or more of these new packets is lost a TD or a timeout will follow FR.

For the 'patient' version, the retransmit timer is set only on TD; thus, up to drops can be recovered. In the present work, we use the 'impatient' version which sets the retransmission timer on each retransmission in fast recovery. More details are given is section 5.4.

As concerns timeouts, RFC6582 states the following: "After a retransmit timeout, record the highest sequence number transmitted in the variable recover, and exit the fast recovery procedure if applicable." Subsequent TD events are ignored if they do not cover more than . This is to avoid spurious TDs. Our TCP follows RFC6582 only for the first retransmission after a timeout. For subsequent retransmissions of the same packet , thus all TD events are enabled. Further, a flag is used for the purpose of collecting timeout statistics.

The final point of this section is the calculation of the retransmission timeout, which depends on the RTT of the connection, as defined in RFC6298. There are four points to consider: (i) Setting of the initial RTO (ii) Computing a proper RTO. (iii) RTT measurement. (iv) Setting the RTO for multiple retransmissions of the same packet.

(i). The initial RTO, when no RTT measurement has been made yet, is set to 1 second (it was previously 3 seconds). The "backing off" discussed below applies.

(ii). When RTT measurements, , say, are available, the RTO is computed in the following two steps; assuming precise timing (zero clock granularity).

(a) First measurement: , / , max s, ). (b) Subsequent measurements:

/ / | |, / / , max s, ).
With constant, the first measurement gives max s, ). On the tenth measurement, max s, .

), and on the twentieth, max s, .

), etc. Therefore, for a large connection, if s e c o n d . A number of popular implementations use a of 200 ms instead of 1 second for the setting of the RTO value.

(iii). RTT measurements are performed, at least, once per RTT outside of any loss event, and using new data. This means that retransmissions are not timed and measurements are not performed during TDFR periods. On FR, normal operation resumes and the first segment sent is timed. Generally speaking, RTT measurements are taken once per "flight" at the beginning of the flight. An implication is that spurious timeouts can occur with too large (in relative terms) and router buffers over slow links. An example is given in section 4.2.

It is important not to confuse timed segments for the purpose of measuring the RTT and setting the retransmission timer on segments. Under normal operation, on retransmission after a timeout, and on FR, the timer must be set on each packet sent (timed or not) -in practice, when a burst of packets is sent, the timer is set on the first of the group. During a TDFR period, the timer can be set either on the first retransmission only (patient version) or for each retransmission (impatient version).

(iv). Backing off the RTO. When a packet is retransmitted the RTO is multiplied by two. When the same packet is retransmitted multiple times the RTO is multiplied again by two, up to four times ( or up to the maximum RTO of 60 seconds. According to Windows implementation public documents, the retransmission of the same packet is limited to five times, at which point the connection is aborted. Our TCP does not limit the number of retransmissions but maxRTO is 64 seconds.

Our TCP follows the above cited RFCs with the following specifics. The receiver acknowledges every packet received. The send buffer is "infinite". The initial window is 2 packets. The RTO value and RTT measurements are set with precise timing; that is, the of RFC6298 is zero. The retransmit timer is set for each retransmission during fast recovery. Our TCP does not send new data on the first two duplicate acks before TD occurs (no "limited transmit"). We use .

Further, connection setup and termination are not simulated. Unlike a real TCP, both sender and receiver know how many packets are to be sent and received when the connection starts. For each connection, the initial sequence number is '1'; there is no possibility of arrival of packets from previous connections. At the sender, a connection is over when the last packet is acknowledged. At the receiver, a connection terminates when all packets are received in sequence. The other aspects of the protocol such as a changing receiver window, restart after idle, etc. are not simulated.

In order to be complete, we conclude this section with a simplified but typical software and buffer architecture inspired from [START_REF] Wright | TCP/IP Illustrated, The Implementation[END_REF] shown in Figure 2. The purpose is to insist on the fact that buffer settings and software efficiency are of importance for TCP/IP performance.

File size distributions

For the selection of file sizes we use the following distributions: exponential (E), exponential-body-Pareto-tail (EP), and exponential-body-exponential-tail (EE). Files have a minimum size also.

For a continuous random variable we note .

For an exponentially distributed variable with a minimum, , we have, , / , .

The average value is .

For a Pareto distribution we have The average value is . The average is finite when . The variance is finite when . Note that the minimum is . If and the minimum are given, then the average is fixed. This does not allow for much flexibility.

In order to have more flexibility, we use a distribution with an exponential body and a Pareto tail.

, / , , , with / .
gives the proportion of file sizes that follow the Pareto distribution. We set %, meaning that 10% of the files can be large to very large. Note that this distribution is continuous but not derivable.

The average is .

We fix the minimum file size , typically , . , and %.

For a given , . Once is calculated, l n .

In order to further check that the simulation results we obtain are not due solely to the Pareto distribution, we use a distribution with an exponential body and an exponential tail. We also set %, meaning that 10% of the files can be large (as defined below by the parameter ) but not extremely large because of the exponential decay. The average is .

With the condition , we have that . We fix via , thus, .

With now given (as well as , , and ), and .

For packets we use . , while for , that gives for .

The following Table 1 gives the measured proportion of file sizes per intervals. The intervals are chosen to correspond to 'flights' when the receiver window is 44 packets. The second column gives the sender window span during slow start in the interval. The values are the proportions for the E and EP distributions; the average size per interval is also given in parenthesis. The calculated values are very close to the measurements. The average file size above can be calculated by , where is calculated from / To conclude this section, Figure 3 illustrates for packets for the different distributions we use here. The EP distribution is fairly smooth while the EE one is fairly abrupt. Note also that the average size above is 33, 52 and 89 packets for the E, EP, and EE [START_REF] Rfc | A Roadmap for Transmission Control Protocol (TCP) Specification Documents[END_REF] distributions respectively. Above 400 packets, the EP distribution is above the EE [START_REF] Rfc | A Roadmap for Transmission Control Protocol (TCP) Specification Documents[END_REF] one, yet the average above is larger for EE [START_REF] Rfc | A Roadmap for Transmission Control Protocol (TCP) Specification Documents[END_REF].

Network settings

The network setting used in this report is illustrated in Figure 4. There are TCP senders to TCP receivers. Each receiver has its own receiving (egress) link of capacity , each of these links has a buffer such that no packets are ever dropped due to buffer overflow. Each sender has its own sending (ingress) link of capacity Mbps. The router multiplexing these inputs has a buffer of size packets. Depending on , packets may be dropped due to buffer overflow. The link between the ingress and egress routers has a capacity . Note that is not necessarily the number of hosts; however, the maximum number of simultaneously active TCP connections is limited to . With reference to Figure 4, we note ∆ ⁄ , ∆ / , ∆ ⁄ the transmission times of data packets on each link. The round-trip time for a single packet -not counting queuing -is , where is the -constant -round-trip propagation delay. is the time required to send a packet and receive its acknowledgement on an empty path. By linearity, the RTT is the same from any point of view; sender output, node input, etc.

We let / ∆ . gives the number of packets that can 'fit' in a generic link of capacity . is similar to the well-known / .

Let us introduce now a sufficiently long TCP connection with receiver window limited to .

We let . means that, in the long term, the link (path) is not saturated; means that the link (path) is saturated.

When the link is saturated, the long-term queue contents is . The '1' accounts for the packet in transmission. The number of packets outstanding is , are 'in the link', thus the difference is in the waiting queue and one in transmission. When queuing occurs, we have ∆.

With reference to Figure 4, either links or can be saturated. Gbps means that there is no limitation whatsoever to reach the receiver after .

Simulation setup

The approaches and models developed here are compared with packet-level simulations. With reference to Figure 4, at the entry of node N 1 we place the 'Birth and Death' (BD) measurement module in order to compare simulation and theoretical results, as well as obtain statistical data. Node N 1 also includes a 'Queue Monitor' module to obtain statistical data about the queue process. The data collected include the distribution of the queue contents measured as a time average, the queue contents on packet arrival, as well as other statistical data.

Node N 2 behaves like a switch with a buffer for each outgoing link; setting this buffer to guarantees that no packets are ever dropped on the output links.

There are senders pair wise linked to receivers. Both senders and receivers know the size of the file to be transferred. The sender waits for an exponentially distributed OFF time with an average of 1 second (5 seconds in the special setting) between connections. Sources and sinks are homogeneous meaning that distributions, packet size, RTT, and receiver windows are the same for a given simulation.

The simulation runs until connections have been completed. depends on the average file size, , with , , , , , and packets. is chosen such that there are about 10 millions packets ( to send. For and F , , for , for , for , for connections. Links L 1 have always the same capacity Mbps. For a given simulation, links L 3 have also the same capacity. We verified that, given the large number of connection, results differ very little from simulation to simulation with the same settings; we therefore present the results for one simulation only.

For each of the indicated above we run simulations for the triplets (2M, 1G, R50-R100-R300), (10M, 2M, R50-R100-R300) and (10M, 1G, R50-R100-R300). The first element indicates the capacity of link L 2 , the second that of links L 3 , and the third the RTT in ms; other simulations follow the same notation. We also run simulations for the special case (1.5M, 128k, D300); that is, . Mbps, bps, and ms. This setting corresponds to the one used in [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF] with the difference that it is now the receivers instead of the senders that have a 128kbps link. The second difference is that the window is limited to .

Finally, to collect further drop statistics, TCP packets headers are augmented with information such as whether the packet was sent in slow start ( ) or congestion avoidance ( , whether the packet is a retransmission after TO, a retransmission in fast recovery (a TO will then follow), etc. Adding such information is clearly possible in a simulation but not in a real implementation.

TCP-Engset revisited

In this section, we develop our approach to the TCP-Engset model. We first provide an overview. We then turn to details. Finally, we evaluate the queuing statistics for a single connection.

Overview

The method we use to model the performance of ON-OFF file transfers with TCP follows the following steps. In the following, we let be the capacity of the multiplexing link.

For a given network scenario and average file size , we first calculate: 1-The average ON time for a connection alone on the path, ∆ , with ∆ max ∆ .

(

) 2
The calculation is detailed in section 4.2. We then calculate the connection peak rate .

This gives

. ( 4
)
With the knowledge of the average time, we can compute the -open loop -traffic load/demand on the link of capacity with sources; that is,

/ / . ( 5
)
The average number of active sources is ∑ , with . We allow .

2-With the additional knowledge of the number of sources , we calculate the , which make up the core of the TCP-Engset model. The calculation is detailed in section 4.3.

3-From the

, we calculate the per connection rate and ON time in two different ways.

Let ∑ , ∑ , and ∑ .

From equation ( 27) and (28) of [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF] we have, Throughput and / . (6) / .

An alternative way to calculate is, ,

We also have , , and finally

/ , (9)
the -closed loop -traffic load/demand.

A detailed in section 5. The second part, which is about the queue contents, is made of the following three steps. It is important to note that because of the assumption of instantaneous capacity sharing the standard technique used for open-loop ON-OFF sources cannot be applied because there are no overload states. Therefore, new approaches are needed. Our very simple model is one of them. The idea is that the ON time gets extended due to queuing. Whenever a link on the path can be saturated, we renormalize to ; that is, we recalculate the and of eq. ( 2) so that min .

4-We calculate

∆ ; but we also have ∆, which gives us

∆ , (11)
the average queue contents. Note that ∆ refers to the multiplexing link.

5-Assuming an exponential decay of the queue contents, we have , which gives

/ . ( 12
)
6-Finally, we start from = proportion of time . We let = proportion of arrivals that see ; simulations show that this is a good approximation. For a finite buffer of size , we approximate the loss ratio -the proportion of arrivals that see a full buffer-as . This gives

L n / . ( 13
)
A detailed analysis of the effects of packet drops is given is section 5.4.

Figure 5 illustrates the first two steps of the approach. First, a conversion to a 'classical' open-loop ON-OFF source is performed. Second, assuming instantaneous and perfect capacity sharing when connections are active, each connection adapts its sending rate to the situation. Clearly, the approach is rate-based and does not take into account the burstiness of the window-based TCP sending patterns both in slow start and congestion avoidance. In the first part, it assumes that no packets are dropped. In the second part, when losses occur, retransmissions are not accounted for.

Calculation of ON 0 and h 0

There is no simple and handy formula for calculating the ON time when a single connection of size uses a given path; we calculate it case by case. The receiver acknowledges every packet and has a limited window of packets. We let ∆ max ∆ and min . The following Figure 6 illustrates the case for packets. We use the word 'flight' to mean a group of contiguous packets. When the link is not saturated flights are separated. When the link is saturated at some window, the flight persists until the end of the transfer. In both the analysis and the simulator, when simultaneous arrival and departure occur, priority is given to departure.

The ON time is taken as the time elapsed between the sending of the first packet and the reception of the ack for the last packet, which means that the connection is now over. If we used the time of the sending of the last packet instead -noted -the OFF time would not be independent of the ON time due to the fact that this last packet may be delayed or even dropped (a timeout would then follow). We have also experimented with measurements of ; to avoid with only one packet to send we have set the minimum file size to three packets. We keep this minimum value even if we do not consider further the use of in the present work.

NOTE:

The BD process measurement module measures a ON time that is / shorter than the one defined above for the calculation. This is because the process is updated only on the arrival of the first packet of the connection.

The following Table 3 gives the values , for the average file size used, as well as conditions on and . The table also gives the sequences of flight sizes. Perfect capacity sharing: h j = C / j d j = j Δ NOTE: When the link is saturated, we first calculate the , as above but we renormalize these values to the known so that the new . This renormalization is used for the calculation of the queue contents; it is not necessary for the calculation of and ON time.

Queue statistics with a single ONOFF connection

We consider here a single connection transferring a file of fixed size packets. The receiver window is . We also consider a capacity mismatch with a link having a packet transmission time ∆ and a BDP . In case of simultaneous arrival and departure, priority is given to departure. Finally, the upstream capacity is assumed large so that groups of two packets sent in slow start arrive together. The purpose of this section is to evaluate the 'stress' put on a buffer by TCP slow start. Although the use of slow start may lead to drops (see section 5.4.3), it is less 'damaging' than sending up to the full receiver window of data at once. When the link is saturated, that is, , we already know that the long term queue contents and , the long term number of packets waiting for transmission.

Let us consider the operation of TCP in 'rounds'. Round '1' starts with the sending of the first two packets of the connection. The queue contents jumps to . After the transmission of the first packet it decreases to . Finally, . In round '2' the receipt of the two acks from the packets sent in round '1' make the sender window increase to , the number of increases is , corresponding to the two acks received. The connection proceeds in slow start until the connection is completed or the receiver window is reached.

In Figure 7, we illustrate the 'stress' put on the buffer for and a limited . We now turn to the calculation of the average queue contents using the time average method. The total time is with calculated as per section 4.2 above. We decompose the calculation of in contributions per round; that is,

∑ #
, where is the contribution of round . 19

For a generic round we have.

with the number of window increases in the round.

The contribution of the generic round is split in 3 cases.

1 -Receiver window not reached and link not saturated in the round.

∆ .

Coming from ∑ ∆.

The equation applies also when the file transfer ends in the round with even. If is odd, there is a single last packet and the contribution is ∆.

-Receiver window reached and link not saturated in the round.

∆, where is the number of acks received from the previous round.

NOTE: If is already reached then and . We have ∆ and , the packet in transmission.

3 -Link saturated. The round extends from the first packet sent in the round until the end of the file transfer. We approximate as ∆, where (last in slow start) is the sequence number of the second packet when is reached for the first time. Without delayed acks . is the sequence number of the last packet of the file (our TCP is packet-based and file sizes are in packets). The first term corresponds to the ramps up and down to/from and the second to the holding time at when is already reached and a leaving packet is replaced by a new one. EXAMPLE: For the settings (100M1.5M128k-D300ms-P576B-F347) and , link L 3 is saturated on the 4 th round. Let . and . The first three unsaturated rounds contribute ∆. For the saturated fourth round we have increases, .

Validation and limitations of the TCP-Engset model

In this section, we verify the validity of the above theoretical considerations as well as their limitations using simulations. We first evaluate the model results -connection rate and utilization -with no packet drops first with exponential file sizes. Second, still with no packet drops, we analyze the effects of file size distribution and receiver window. We then compare theory and simulations with respect to the state probabilities. Finally, we evaluate the model when packet drops occur due to a finite buffer. We also propose a buffer setting rule based on the model.

Throughout this section, the average connection rate is measured in the following three ways.

∑ _ _ ∑ _ ∑ _ /
, where _ is the total of number of packets to send per connection, _ is the total of connections duration; both for source . is the number or sources. The first two expressions above give almost the same results with very minor differences owing to the large number of connections completed. The third term is calculated from the results of the BD process and is used as a cross-check.

Exponentially distributed file sizes

The overall settings used in simulations are as follows. Packet size is 1500B.

packets. The network settings are (100M2M1G-R50&R100) with F = (5, 12, 22) packets. For these average sizes no link is saturated and no spurious TO occur. The other settings are (100M10M2M-R50&R100) and (100M10M1G-R50&R100) with F=5, 12, 22, 36, 80, 120 packets. For the first setting the egress link is saturated when but no spurious TO occur.

The number of sources is varied to obtain an open-loop traffic demand starting at about 40% up to about 140% by steps of 20%. This corresponds to 6 values of for each setting.

In Figure 8, we plot the percent error on the calculated connection rate, , , and the average, versus .

tends to be larger than measured while tends to be smaller. Although for some cases is closer to measurements than and inversely, as mentioned, we use the average to obtain an overall more accurate result, which is also confirmed by the trend line. Note also that as the load increases, both tend to be accurate as well as equal. The same observation applies to the utilization . Overall, for exponential file sizes, the model is accurate for predicting the connection rate, ON time and link utilization for low to high load with .

Effect of file size distribution and receiver window

In this section we analyze the interplay between and file size distribution. The simulation settings are (100M10M1G-R50). The open-loop utilization is 80%, 100%, and 120%.

is set so that the calculation of is not changed with . For example, flight sizes are [START_REF] Bonald | Evaluation de Performance des Réseaux de Données[END_REF][START_REF] Yang | TCP Congestion Avoidance Algorithm Identification[END_REF][START_REF] Rfc5681 | TCP congestion Control[END_REF][START_REF] Rfc5681 | TCP congestion Control[END_REF] for and are unchanged whether or 12. The reference is exponentially distributed file sizes with . In Figure 9 we plot the ratio (in percent) of measured connection rates. Figure 9 left shows that when sizes are exponentially distributed reducing has little influence whatever and the load. On the contrary, the middle and right plots show that when the size distribution has a longer tail than exponential, has an important effect: reducing increases the average connection rate. The penalty incurred when decreases with increasing . Using the same simulation data, in Figure 10 we plot the ratio of average connection rate with . The reference is the exponential distribution. Again, the penalty decreases with increasing . Another perspective is obtained by analyzing the simulation results by size intervals. In Table 4 we give the ratio of ON times for and and ratio of average queue seen per packet for and %. The effect of long tail distributions and larger is to greatly increase the connection duration for small connections, which are also the most numerous (more than 90% of the total). For files larger than 62 packets, as expected, connections take longer to complete with as indicated by the negative ratio. We have verified that similar results hold also for the (100M10M2M-R50) setting where packets are paced by the egress link, and the (2M10M100M-R50) setting where packets are "naturally" paced by the ingress link. It is thus a generally applicable observation.

We interpret these results by the effect of slow start which results in the increase of the buffer contents and thus increased delay. Recall that in slow start two packets are sent for one leaving the network. With the last packet sent in slow start has sequence number while with it is . For the effects of larger file sizes are minimal as one packet is sent for one leaving. On Expo sizes %h(W44) / h(Wx) -

F12-W12 F22-W12 F36-W16 F80-W32 r0=80 r0=100 r0=120 EE(7) sizes %h(W44) / h(Wx) 14 -12 -10 -8 -6 -4 -2 0
F12-W12 F22-W12 F36-W16 F80-W32 r0=80 r0=100 r0=120 EP sizes %h(W44) / h(Wx) -14 -12 -10 -8 -6 -4 -2 0
F12-EE/E F12-EP/E F22-EE/E F22-EP/E F36-EE/E F36-EP/E F80-EE/E F80-EP/E F120-EE/E F120-EP/E r0=80 r0=100 r0=120 %h(EE or EP) / h(expo) -W44 -16 -14 -12 -10 -8 -6 -4 -2 0
the contrary, for the size distribution is of importance as files larger than tend to occupy the buffer and lengthen connections with smaller sizes. As concerns the TCP-Engset model, its results are accurate provided is adjusted adequately with respect to . The reason is that it does not take into account the relationship between size distribution and slow start. For example, with and the EE distribution the errors of the model for the three loads of the (100M10M1G-R50) setting are (+11.6%, +19.4%, +7.8%) with but only (+0.2%, +4.5%, +2.5%) with . The '+' sign means that the model gives a larger value than measured. The clear advantage of reduced is that most connections complete more quickly thanks to smaller queuing delay.

Sensitivity of P j to file size distribution and receiver window

We measure the state probabilities, , as a time average; that is, as proportion of total time in a given state .

The following Figure 11 shows the comparison between calculations and simulations for the settings indicated in the figure (s is for C/h, b is for BDP). On the left side, the figure shows the state probabilities ; note the logarithmic scale. On the right side we plot the capacity sharing between ON sources; that is, / , where and are the measured values with more than 10 samples. For each case, the number of sources corresponds to an open-loop load of about 100%, which is not a very high load in the present work. As expected, the 's are not insensitive to the size distribution and for . For exponentially distributed sizes, model and simulations agree quite well over the whole range of . The reason is that the sizes of files do not go well beyond the average; see the data in Table 1. With longer tail distributions, somewhat larger-than-average sizes appear more frequently, associating this fact with large (relative to the average size) lead to much more queuing occurring (as is measured) and longer connection completion time thus longer holding times in a state . Reducing helps lowering the tail of the distribution; however, the interplay between file distribution and remains complex.

Surprisingly, when the average size gets larger ( or , not shown here) the insensitivity seems weaker for . The reason is neither queuing nor the lack of samples. We cannot explain this difference. The plots on the right side of Figure 11 show that while capacity sharing occurs, it is not as steeply marked as the model predicts.

As seen in the previous section, the model holds good for exponential size distribution. For longer tail distributions, it works well when is adjusted with respect to .

Performance with limited buffer

In this section, we first propose and evaluate a buffer setting rule based on the TCP-Engset model. We then turn to the analysis of the effects of packet drops. Finally, we analyze the effects of varying the buffer size.

Buffer setting rule

Consider a single multiplexing link of capacity with a round trip time . One rationale for choosing the buffer size for the link is to avoid spurious TCP timeouts. With an RTO of 1000 ms, allowing a maximum queuing delay of 600 ms leaves 400 ms for the . We call this setting the 600ms-rule. A second rationale is to set the buffer to the BDP. This setting considers long connections in congestion avoidance with synchronized windows. The delay is usually set to 300 ms; we call this setting the BDPrule. This rule is analyzed in [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF] as well as in a number of other publications.

We propose a buffer setting rule based on the TCP-Engset model developed above. Set % and . For such that %, and and ms, compute L n , with and given by the model. For each the calculation gives a different . We round up the results obtained for = 5, 12, 22, 36, 80, 120, 500, and 1000 packets. There is no clear cut tendency, it is therefore recommended to vary the parameters for the calculation. For a 10 Mbps link the model gives for . For a 50 Mbps it gives also for .

In Table 5 we give the buffer size in packets and the maximum queuing delay for different link capacities and rules. The TCP-Engset-rule gives smaller values than the other rules especially for the 50 Mbps link.

Queue behavior

In Figure 12 we plot the theoretical and measured for the settings indicated in the figure; both are for %. For the theoretical (T) results we give the pair ( , , and the calculated and . The measured values indicated are , (noted r), and .

First, the queue contents greatly depend on size distribution and receiver window. As in the previous sections, we interpret this observation by the effects of slow start (two packets sent for one leaving) on the buffer and the relationship between and . Second, the approach proposed here for works fairly well for exponentially distributed sizes and for the EP distribution with . Note also that for the E distribution the measurements are well below the model in the tail. Third, as concerns the loss rate, the model provides an upper bound for the E distribution with and the EE and EP distributions with . Finally, small loss rates do not affect the accuracy of the predictions of and . The next question is: "what happens when the number of sources increases with the same buffer setting?"

In Table 6 we give the comparison between theory and measurements for the setting indicated. The first observation is that connection rates tend to equalize with increasing load. Further, they tend to the theoretical value. We have reproduced the settings of [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF] with the same outcomes. The second observation is that the model greatly overestimates the loss rates above 1%. To conclude this topic on the buffer contents, in Figure 13 we plot the queuing behavior for . % (moderate load) and . % (high load) for packets. For the moderate load, the model fairly follows measurements for the exponential distribution. It greatly underestimates the buffer contents for the EE distribution, even with . For the high load, even though the difference between model and measurements are reduced, the 'bulge' above the theoretical curve is not taken into account. The same plots for the (2M10M100M-R50) setting, that is, when packets are paced by the ingress link, are almost indiscernible from those of Figure 13. The observations are thus of general applicability.

Analysis of losses

We now turn to the analysis of losses. Here, packets are only dropped due to buffer overflow; there are no random drops. In Figure 14 we plot the proportion of drops per sequence number (recall that each connection starts with packet '1') for a high load and high losses setting indicated in the figure. When the connection is in slow start the second packet sent gets more dropped than the first by a large factor. This is due to the capacity mismatch between the 100 Mbps ingress link and the 10 Mbps multiplexing link. The observation does not hold when packets are 'naturally' paced by an ingress link of 2 Mbps; although other measurements results are similar (in particular, loss rate and connection rate). The effect of lower is to reduce the loss rate from 6.3% to 4.6%. Note also that packets are more uniformly dropped after the last packet sent in slow start (packet '86' for and '22' for . We do not use this observation here. Packet drops have two consequences on TCP. Drops are recovered either by TO or FR (a TD followed by a successful fast recovery). With one drop only, a TO is unavoidable if packets '1' or '2' are dropped, we call this event TO beginning (TObeg). At the end of the connection, if either one of the three last packets are dropped a TO follows; the event is called 'TOend'. If any of the retransmissions after TO, or during the fast recovery, is dropped a timeout follows. A TO after a TO is called TOTO and it occurs at . A TO during fast recovery is called TDTO. With the 'impatient' version of TCP NewReno this event only occurs if either one of the retransmissions is dropped. In Table 7 we give the drop analysis for the high load/loss setting of Figure 14 left. We start with TDFR events. From the results of Table 7 we see that FR occurs most commonly; only 3% of TDs are followed by a TO. Packets (including retransmissions) continue to be sent at a rate similar to the overall send rate. Thus, connections are not stalled by TDFR events; as it should. In Figure 15 we plot the distributions of the number of retransmissions (left) and the number of packets sent on FR (right) for and . Our TCP resets the timer on each retransmission; this is to avoid spurious TOs during fast recovery. Our TCP does not limit the burst of packets to send; Figure 15 right shows that most significant bursts are of 2 (82.8%) or 3 (6.1%) packets for and up to 7 (11.5%) for . Limiting the bursts to 2 packets, as in slow start, does not improve performance in a significant way. We now turn to TO events. The occurrence of timeouts has more consequences on TCP performance as a connection experiencing a TO gets stalled for about 1 second and possibly more. We focus on TOs in slow start as they constitute the vast majority of these events. In our TCP, a connection is in slow start when . In Figure 16 we plot the proportion of TOs versus the window at which they occur for the high loss setting for the EE (left) and E (right) size distributions; both for . A TO at indicates a TOTO. A TO at means that packet '1' is dropped. A TO at means that packet '1' is not dropped but packet '2' is; whatever happens to packets '3' or '4'. A TO at means that packet '3' is dropped and, at least, one more drop occurs on packets '4', '5', or '6'. A TO at requires three drops starting with packet '4', etc. The proportion of TOs depends on the size distribution; for example, #sent on FR more than 90% of files are between 3 and 6 packets for the EE(7) distribution. Clearly, the performance penalty is high for small connections that should complete in a few RTTs and experience one or more TOs. We turn to the loss analysis per file size. In Table 8 we show the measured statistics per file size interval for the EE(7) distribution. The vast majority (90.3%) of sizes are between 3 and 6 packets. Larger sizes are more evenly spread. The average queue seen per packet is also fairly constant and about one packet less than the overall time average. The 6 th column gives the proportion of TOs per packet dropped. For the 3-6 packets connections a single drop leads almost inevitably to a TO as a TDFR sequence cannot occur. That proportion decreases with increasing file size. The 7 th column gives the proportion of drops recovered by a TDFR (number of retransmissions over number of drops). The dependence on file size is the inverse of that of TOs per drops.

Effect of varying the buffer size

We now turn to the effects of varying the buffer size. The difference between small and large buffers can be seen in Table 9. For each file size interval we give the connection rate (see below) and, in parenthesis, the proportion of the ON time spent/stalled in TO (time_TO -time_previousSent) for different buffer sizes. The measured values are obtained as follows ( is the number of connections). As concerns the connection rate, the results show that small buffers favor small connections and disfavor large ones while large buffers disfavor small connections and favor large ones. However, for a small buffer, the proportion of time where connections are stalled waiting for a TO is large, whatever the file size. Note also that the definition of the average connection rate gives a larger value than the definition . The actual values differ depending on the file size distribution. We conclude this section with a surprising observation. In Table 10, for a high load setting, we show the connection duration (ON time), connection rate ( ), and loss rate ( ) for different buffer sizes and EE [START_REF] Rfc | A Roadmap for Transmission Control Protocol (TCP) Specification Documents[END_REF] and E size distributions. The surprising observation is that, as concerns the averages, there seems to be compensation between delay and losses to give the same result. For large buffers, connections take a long time to complete because of the delay. For small buffers, the recovery of packet drops lengthens connections. The theoretical values also given show that the model predicts fairly well both the connection rate and duration independently of buffer size and distribution. However, repeating the simulations with ( . % show that it is only due to the very high load. As a final note in this section, a simulation with takes about 30 minutes to complete while with it takes about 1h30mn. It is therefore interesting to have a model to quickly compute quantities of interest even though a simulation can supply results that cannot be calculated.

Figure 1 .

 1 Figure 1. Example of TD-FR with TCP NewReno from the sender perspective.

Figure 2 .

 2 Figure 2. Simplified buffer and software implementation inspired from [13].

Figure 3 .

 3 Figure 3. File size distributions for F = 12 packets.

Figure 4 .

 4 Figure 4. Network setting.

Figure 5 .

 5 Figure 5. Illustration of the TCP-Engset approach.

Figure 6 .

 6 Figure 6. Illustration of the calculation of ON 0 for F = 5 packets.

Figure 7 .

 7 Figure 7. Illustration of the queue contents with four increases up to the receiver window, link not saturated.

Figure 8 .

 8 Figure 8. Percent error of calculated connection rate versus open-loop load.

Figure 9 .

 9 Figure 9. Percent ratio of measured connection rates per size distribution.

Figure 10 .

 10 Figure 10. Percent ratio of connection rate compared to exponential size with W R =44.

Figure 11 .

 11 Figure 11. Comparison between calculations and simulations for different settings. Left, P j . Right, capacity sharing.

Figure 12 .

 12 Figure 12. Theoretical vs. measured P(Q>x) for limited buffer.

Figure 13 .

 13 Figure 13. Queuing behavior for a moderate load and a high load.

  -(91.9, 25.1)-L0.03%-h547.8 2-EE-W44-L0.29%-r90.9-h489.8 3-EE-W12-L0.001%-r992.3-h527.1 4-EP-W44-L0.06%-r91.1-h515.6 5-EP-W12-L0%-r92.1-h547.7 6-E-W44-L0-r93.9-h563.-(95.6, 53.6)-L0.04%-h746.[START_REF] Rewaskar | A Performance Study of Loss Detection/Recovery in Real-world TCP Implementations[END_REF] 2-EE-W44-L0.13%-r96.0-h720.6 3-EE-W12-L0.003%-r96.2-h740.3 4-EP-W44-L0.012%-r93.8-h727.1 5-EP-W12-L0-r95.9-h743.2 6-E-W44-L0-r96.8-h750.-T-(99.35, 66.5)-L4.91% 2-N98-E-W44-L∼0 3-N98-EE-W44-L1.04% 4-N66-T-(76.6, 9.7)-L0 5-N66-E-W44-L0(114) 6-N66-EE-W44-L0.06% 7-N66-EE-W12-L0(193)

Figure 14 .

 14 Figure 14. Proportion of dropped packets per sequence number.

Figure 15 .

 15 Figure 15. Left, number of retransmissions in TDFR. Right, number sent on FR.

Figure 16 .

 16 Figure 16. Proportion of TO in slow start vs. window. Left, EE(7) distribution. Right, E distribution.

Table 1 . Measured proportion of file sizes per size intervals.

 1

			F=5, 800kC	F=12, 800kC	F=22, 450kC	F=36, 250kC	F=80, 120kC	F=120, 80kC
	[f1-	W	Expo	EP	Expo	EP	Expo	EP	Expo	EP	Expo	EP	Expo	EP
	f2]			k=5.4		k=17.2		k=34.1		k=57.8		k=132.3		k=200
	3-	3-	82.7	92.8	32.2	43.6	16.8	22.9	10.0	13.7	4.4	6.1	3	4
	6	4	(4.2)	(3.7)	(4.6)	(4.6)	(4.7)	(4.6)	(4.7)	(4.7)
	7-	5-	17.0	5.05	39.9	41.2	28.5	34.5	19.4	24.7	9.5	12.5	6.2	8.8
	14	8	(8.4)	(9.2)	(9.9)	(9.7)	(10.2)	(10.1)	(10.3)	(10.3)
	15-	9-	0.3	1.45	23.2	11.1	19.1	29.6	27.1	30.2	16.2	20.2	11.7	14.8
	30	16	(16.4)	(20.1)	(20.3)	(19.1)	(42.2)	(21.0)	(21.9)	(21.6)
	31-	17-		0.46	4.6	2.7	4.2	9.0	26.9	22.6	23.6	26.5	18.9	22.5
	62	32		(41.6)	(38.8)	(41.9)	(79.3)	(40.6)	(43.9)	(42.5)
	63-	33-		0.05	0.13	0.93	0.14	2.7	14.3	5.8	26.5	24.0	26.1	26.8
	128	44		(175)	(71.0)	(86.3)	(147)	(85.9)	(85.2)	(85.9)	(91)	(89)	(92.5)	(91)
	129-	44		0.017		0.32		0.88	2.2	1.91	16.2	7.1	23.0	16.2
	256			(355)		(174)		(176)	(159)	(175)	(176)	(173)	(180)	(172)
	257-	44				0.11		0.31	0.05	0.71	3.6	2.4	9.9	4.4
	512					(352)		(352)	(292)	(346)	(325)	(348)	(341)	(348)
	513-	44				0.04		0.11		0.25	0.14	0.85	1.3	1.6
	1024										(590)	(697)	(620)	(693)
	1025-	44				0.01		0.04		0.08		0.3	0.03	0.58
	2048
	2049-	44						0.015		0.03		0.1		0.19
	4096
	>	44								0.02		0.05		0.11
	4096

Table 2

 2

	gives saturation data for different simulation scenarios (with ∆	/	μs fixed).
	stands for or .

Table 2 . Saturation data for different simulation scenarios.

 2

	C (Mbps)	Δ (ms) RTT (ms)	β (pkts)	W R (pkts)	r	(%) W R / β	Link Condition
				8	1.00 100	Not saturated (but at onset)
		50	8.3	12 20	0.67 150 0.40 250	Saturated, Q=5 Saturated, Q=13
	2	6		44 8	0.18 550 2.00 50	Saturated, Q=37 Not saturated
		100	16.7	12 20	1.33 75 0.80 125	Not saturated Saturated, Q=5
				44	0.36 275	Saturated, Q=29
				8	5.13 19.5	Not saturated
		50	41.7	12 20	3.42 29.3 2.05 48.8	Not saturated Not saturated
	10	1.2		44 8	0.93 107 10.38 10	Saturated, Q=4 Not saturated
		100	83.3	12 20	6.92 14.5 4.15 24	Not saturated Not saturated
				44	1.89 53	Not saturated

  It turns out that is the link utilization whether packets are dropped or not.

	1,	is a little too high and		a little too low; therefore, we use
	,	, and	.		(10)
	NOTES: (a) Equation 8 makes sense only for	. (b) In high overload,	and both approaches
	give the same connection rate. (c) We have	; when	we have	/ , which gives
	. (d)

Table 3 . Data for the calculation of ON 0 .

 3

		'flight'=2	'flight'=3
								(a) Link NOT saturated
		1	2	3	4	5		1	2
		W=2		W=3 W=4			Connection done	W=2
			RTT	Δ*			RTT	OFF	Next connection
			ON 0 = 2 RTT 0 + 2 Δ*
				'flight'=5			(b) Link saturated
		1	2	3		4	5	1
			Q=3		Q=3	Q=2	Q=1	Q=0
		W=2	W=3		W=4			Connection done	W=2
			RTT	Δ			RTT	OFF	Next connection
			ON 0 = 1 RTT 0 + 4 Δ*. Renormalized to 3 RTT 0 + Δ*
	F	(m, n), for ON 0 = mRTT 0 + nΔ*	'flight' sizes	Comments
	5 12 22	(2, 2) for β*>2 and W R (3, 5) for β*>4 and W R (4,7) for β*>8 and W R			(2, 3) (2, 4, 6) (2, 4, 8, 8)

Table 4 . Measured ratios for W R =44 and W R =12.

 4

			F12-10M1G-R50-N80 (	.
		EE (7.4% < 0)			EP (4.2% < 0)
	f1-f2	%files	%ON	%Qseen	%files	%ON	%Qseen
			W44/W12	W44/W12		W44/W12	W44/W12
	3-6	90.19	31.1	66.0	43.67	18.9	47.6
	7-14	0.89	29.6	59.9	41.2	18.6	45.3
	15-30	1.55	19.1	52.0	10.99	14.2	39.6
	31-62	2.34	-1.6	51.1	2.72	-3.5	40.4
	63-128	2.73	-27.9	64.9	0.93	-29.9	60.1
	129-256	1.79	-42.0	89.4	0.32	-46.3	82.7
	257-512	0.48	-48.2	103.7	0.11	-48.5	121.2
	513-1024	0.027	-46.6	151.7	0.041	-49.5	141.2
	1025-2048				0.015	-49.5	158.7
	2049-4096				0.005	-48.5	167.2
	>4096				0.0026	-62.2	167.9

Table 5 . Buffer size in packets for RTT=300 ms and P=1500B.

 5

	C (Mbps)	600ms-rule	BDP-rule	TCP-Engset-rule
	2	100 (600 ms)	50 (300 ms)
	10	500 (600 ms)	250 (300 ms)	200 (240 ms)
	50	2500 (600 ms)	1250 (300 ms)	420 (100 ms)

Table 6 . Comparison of results for different loads.

 6

			100M10M2M-R50-W R 44-B200
		N82	N98	N115	N134
		. %	. %	. %	. %
	Theory-h (kbps)	547.8	344.6	219.5	154.9
	Theory-L (%)	0.03	4.91	22.0	38.3
	EE(7)-h (kbps)	489.8	328.2	219.2	155.9
	EE(7)-L (%)	0.29	1.04	2.66	4.80
	E-h (kbps)	563.1	347.1	219.5	154.7
	E-L (%)	0 (Q max 175)	0.004 (399/9.6M)	0.41	2.55

Table 7 . Drop analysis for a high load/loss setting.

 7

	F12-10M2M-R50-EE(7)-W44-B150-L6.3%
	%packet drops	6.3
	%TO per dropped packet	26.5
	%TOTO per TO	9.9
	%TDTO per TO	2.4
	%TObeg per TO	23.0
	% TOend per TO	61.4
	% TOother per TO	3.4
	Avg time TO per TO (ms)	1200.5
	Avg time TO per connection (ms)	259.0
	%TD per dropped packet	20.8
	%FR per TD	97.0
	Avg nb pkts sent TDFR per FR	11.1
	Avg nb pkts sent on FR per FR	2.3
	Avg time TDFR per FR (ms)	614.3
	Avg time TDFR per connection (ms)	100.8
	Avg rate TDFR (kbps) per FR	216.8
	Avg send rate (kbps)	197.0
	Avg connection rate, h (kbps)	154.5 (154.9 theory)
	Avg connection ON time (ms)	927.1 (929.6 theory)
	Avg file size (pkts)	11.94 (12 theory)
	Avg RTT measured by TCP (ms)	196.4 (122 pkts in queue)

Table 8 . Statistics per size interval for a high losses setting.

 8

	N134-10M2M-R50-EE(7)-W44-B150. Measured: F=11.88 pkts, h=155.5 kbps, avgQ=126.7 pkts
	f1-f2	%prop.	<f>	h (kbps)	<Q seen > per pkt %TO per drop %rtx FR per drop
	3-6	90.27	3.4	93.4	125.3	83.9	0.0
	7-14	0.87	10.5	161.6	124.3	43.4	28.9
	15-30	1.55	22.3	222.8	125.8	21.4	61.7
	31-62	2.31	45.5	292.3	127.4	11.3	78.2
	63-128	2.73	91.1	349.5	128.4	7.5	82.3
	129-256	1.77	176.3	398.3	128.7	6.2	84.2
	257-512	0.48	326.0	418.1	128.6	5.6	86.4
	513-1024 0.023	590.4	396.2	128.5	4.4	89.7

Table 9 . Connection rate h 2 (kbps) and proportion of TO in ON time per size interval for different buffer sizes.

 9

		F12-N134-10M2M-R50-W R 44. h 2 in kbps (%TO time / ON time)
			EE(7)			EP
	f1-f2 (pkts)	B50	B150	B750	B50	B150	B750
		L=9.5%	L=6.3%	L=0.001% L=8.8%	L=4.75%	L=0 (Q m 587)
	3-6	160.9 (77.2) 92.8 (38.0)	62.0	205.3 (74.1)	120.5 (32.5) 93.3
	7-14	223.1 (73.7) 157.9 (37.8) 121.8	253.8 (66.9)	160.5 (28.1) 131.2
	15-30	290.1 (60.9) 221.3 (28.2) 191.8	328.0 (56.7)	220.8 (21.1) 192.7
	31-62	348.6 (52.6) 287.5 (20.3) 304.1	425.6 (45.6)	317.7 (14.5) 323.0
	63-128	386.4 (46.1) 342.3 (15.5) 471.5	478.7 (38.4)	401.8 (10.8) 521.6
	129-256	400.5 (42.0) 386.5 (12.1) 672.8	525.4 (32.3)	464.9 (7.3)	757.9
	257-512	406.9 (38.1) 406.5 (9.3)	835.1	549.8 (27.5)	516.1 (5.1)	975.9
	513-1024	390.4 (36.5) 432.4 (6.3)	959.9	560.5 (23.5)	510.9 (4.8)	1128.1
	1025-2048				556.6 (22.3)	522.8 (3.2)	1216.4
	2049-4096				540.2 (22.3)	518.1 (1.7)	1270.7
	> 4096				532.6 (22.5)	642.9 (1.8)	1308.9

Table 10 . Measured averages for different buffer sizes.

 10

		F12-N134-10M2M-R50-W44. Theory: h=154.9 kbps, ON=929.6 ms,	. %
			B50	B75	B100	B150	B200	B300	B500	B750
		h (kbps) 154.6 154.9	155.1	155.5	155.9	155.9	156.7	156.0
	EE(7)	ON (ms) 924.3 921.1	922.6	917.3	914.5	917.5	910.6	916.3
		L %	9.5	8.6	7.8	6.3	4.8	2.3	0.16	0.001
		h (kbps) 153.0 153.6	153.7	154.2	154.7	155.4	155.1	154.8
	E	ON (ms) 939.4 937.6 L % 9.3 8.1	937.2 7.0	933.8 4.7	929.7 2.55	926.0 0.18	927.6 0	930.7 0
		(theory)	(78.7)	(69.8)	(61.9)	(48.7)	(38.3)	(23.7)	(9.1)	(2.7)

* daniel.zaragoza@laposte.net

* It is not advisable to do so when W R can change during the course of a connection.

For the 'special' settings (100M-1.5M-128k-D300ms-P576B) and packets, we have .

, . packets, . packets, ∆ ∆ . ms, and ∆ ∆ ms. For , link L 3 is saturated on the 4 th round starting with packet '15'. We first calculate the flight sizes [START_REF] Bonald | Evaluation de Performance des Réseaux de Données[END_REF][START_REF] Yang | TCP Congestion Avoidance Algorithm Identification[END_REF][START_REF] Rfc5681 | TCP congestion Control[END_REF]333) and , , . We have . kbps, . . ∆ . We renormalize to , , , which gives . . The difference is less than one packet transmission time on L 3 . For , link L 3 is not saturated the sequence of flight sizes is (2, 4, 8 [x42], 5) and , , , . kbps and . .

Note also that with , and for file sizes between 54 and 106 packets, a spurious timeout occurs due the way a standard TCP measures the RTT (once per fight at the beginning of the flight). For , a timeout occurs for packet '54', for it occurs for packet '90'. More specifically, a queue of 19 packets (on link L 3 ) creates a delay of 684 ms and a RTT of 1025 ms. With , there are up to 35 packets waiting; that is, up to 1260 seconds of wait time. For a standard TCP in slow start the sequence of timed segments is '1' (W=2), '3' (W=3-4), '7' (W=5-8), '15' (W=9-16), '31' (W=17-32), '63' (W=33-44), '107' (W=44), etc. Between packets '1' and '15' the timed segments see no queue and the RTO remains at 1 second. Packet '31' sees a queue of 23 packets but RTO will be updated only with packet '63'; therefore, a spurious timeout occurs in between. As a consequence, for this setting we compare simulations and calculations for (L 3 not saturated) and (L 3 slightly saturated with 3 packets waiting).

Once the time for a single source is determined, we use a simple fluid approximation to calculate . Specifically, / .

Calculation of the TCP-Engset P j (s)

We rephrase here the equations of [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF].

Let the number of sources, the number of sources active (ON) at time . We are interested in for ∞. The standard theory of BD processes gives The transition rate is given by

For a single source, the transition rate OFF to ON is / . When sources are ON, are OFF. Thus, the total transition rate / .

For the TCP-Engset model, the transition rate is given by

We first consider the case . For a single source, the transition rate ON to OFF is / . When independent sources are ON the total transition rate is / .

Summary and Conclusion

In the present work, we have revisited the TCP-Engset model proposed in [START_REF] Heyman | A new method for analyzing feedback-based protocols with applications to engineering Web traffic over the Internet[END_REF]. The model deals with the performance obtained with a limited number of short connections sharing a multiplexing link. Here, we have considered homogeneous sources only.

We have taken into account the effects of slow start and limited receiver window. We have proposed an alternative way of calculating the average connection rate. Extensive simulations show that taking the average of the two theoretical results give more accurate results than each individual ways. We have proposed an approach for the determination of the queuing behavior. This approach has led us to propose a buffer setting rule. We have validated and determined the limits of the revisited model with extensive simulations.

The approach developed in the present report is summarized and commented in Table 11.

Our conclusions are as follows.

-All of connection rate, ON time, link utilization, queue contents, state probabilities, and loss rate are sensitive to file size distribution and receiver window. -However, this sensitivity tends to vanish with increasing load; whether packets are dropped (here, only due to buffer overflow) or not. -Under a wide range of loads, the revisited model predicts fairly accurately the average connection rate, duration, and link utilization for exponentially distributed file sizes. For longer tail distributions, the model remains accurate provided the receiver window is adjusted with respect to the average file size. These distributions lead to reduced results with respect to exponential size and the model; the penalty is up to 15-20%. Further, the most numerous small connections are penalized by the presence of long connections with large receiver window. -We have interpreted these observations by the relationship between , the average file size, and , the last packet sent in slow start when the receiver window is reached for the first time.

-As concerns the queuing behavior, the model is fairly accurate under the same conditions (distribution and receiver window) as in the previous point. -As concerns the loss rate, the model cannot be used to predict loss rates larger than about 1%.

The model greatly overestimates the loss rate above that threshold. Further, it does not take into account retransmissions. -The buffer sizing rule we have proposed appears to work well under the condition mentioned in the previous point, that is, when loss rates are below 1%.

Clearly, new ideas and more work are required to take into account the influence of file size distribution and receiver window. The same applies for the accurate prediction of the loss rate for TCP. Finally, the case of heterogeneous sources has not been dealt with and is left for future modeling work. When a link on the path can be saturated, renormalize to .

and ∆ refer to the multiplexing link.

Rule: Set such that %. Set , calculate for different up to =1000 and ms and 300 ms. Round up the largest obtained. For a 10 Mbps link, . For a 50 Mbps link, packets.

The queue contents, , is sensitive to size distribution and receiver window.

The equation for cannot be used to predict loss rates larger than about 1%.