On the Interaction Between Internet Applications and TCP

Abstract

We focus in this paper on passive traffic measurement techniques that collect traces of TCP packets and analyze them to derive,
for example, round-trip times or aggregate metrics such as average throughput. The seminal work of Zhang [1] has shown that
for more than 50% of the TCP connections observed, it is not the network bandwidth that limits the throughput but rather the
application or mechanisms such as TCP slow start or too small a receiver window. Certain types of analysis of the network
characteristics are meaningful only when performed on TCP traffic that experiences minimal interference by the application.
To eliminate such interference, we propose a generic method that partitions the packets of a TCP connection in bulk data transfer
and in application limited periods: The packets of a bulk data transfer period (BTP) experience minimal interference from
the application, while the packets of an application limited period (ALP) experience interference from the application that
prevents TCP from fully utilizing the network resources because the application does not produce data fast enough. As a proof
of concept, we apply our algorithm to public Internet traffic traces and show that unless the effects of the application are
filtered out, studying the end-to-end path and traffic characteristics from a network point of view can produce biased results.

Full text

Page 1

On the Interaction Between Internet Applications and TCP
M. Siekkinen
Institut Eurecom
2229 Route des Crˆ etes
Sophia Antipolis, France
siekkine@eurecom.fr
E. W. Biersack
Institut Eurecom
2229 Route des Crˆ etes
Sophia Antipolis, France
erbi@eurecom.fr
G. Urvoy-Keller
Institut Eurecom
2229 Route des Crˆ etes
Sophia Antipolis, France
urvoy@eurecom.fr
ABSTRACT
Wefocus inthis paper on passive trafficmeasurement techniques
that collect traces of TCP packets and analyze them to derive, for
example, round-trip times or aggregate metrics such as average
throughput. The seminal work of Zhang [16] has shown that in
more than 50% of the TCP connections observed it is not the net-
work that limits the throughput but rather the application or mech-
anisms such as TCP slow start or a too small a receiver window.
Certaintypes of analysisof the network characteristicsaremean-
ingful only when performed on TCP traffic that experiences mini-
mal interference by the application. For this purpose, we propose
a generic method that partitions the packets of a TCP trace in bulk
data transfer and in application limited periods: The packets of a
bulk data transfer period (BTP) experience minimal interference
from the application, while the packets of an application limited
period (ALP) experience interference from the application that pre-
vents TCP from fully utilizing the network resources because the
application does not produce data fast enough. We apply our al-
gorithm to public Internet traffic traces and show that unless the
effects of the application are filtered out, studying the end-to-end
path and traffic characteristics from a network point of view can
produce biased results. We show also that studying the properties
of the different periods and, specifically, the impact of ALPs on ap-
plication specific traffic can help us characterize the behavior of the
application.
Categories and Subject Descriptors
C.2 [Computer-Communication Networks]: Network Proto-
cols, Local and Wide-Area Networks, Internetworking
Keywords
TCP, throughput, Internet application
1. INTRODUCTION
The set of applications contributing most to the traffic in the In-
ternet has changed over the last couple of years from HTTP and
FTP to peer to peer (P2P) applications. In addition, new Internet
applications such asRSS feedsor PodCast are emerging constantly.
However, TCP still transports the majority of bytes, typically over
90%. Traffic volumes have also dramatically increased with the
emergence of P2P. These facts highlight the versatility of TCP but
also raise the question of how TCP and these new applications per-
form in these new environments. As a consequence, the analysis of
TCP as a protocol and of TCP traffic is even more vital than before.
The various applications running on top of TCP behave quite
differently. They differ in the number of connections they establish
(one or many simultaneously) and in the way they provide data to
the TCP socket of each connection for transmission (continuously
or sporadically). Consider, for instance, a P2P application such as
BitTorrent that may establish 20-30 connections of which only a
subset is actively used at any time for transmitting data. On the
other hand, FTP establishes one control and one data connection.
FTP transfers ”all the data at once”, whereas BitTorrent connec-
tions alternate between transfer (unchoked) and idle (choked) peri-
ods.
Much research have been done to detect anomalies and to char-
acterize TCP traffic in the Internet. This work usually focuses on
the TCP and IP layers, but often ignores the effects of the applica-
tion on top. When seeking to explain certain characteristics, e.g.
burstiness of TCP traffic [5] [10], it is crucial to account for the
effects of the application.
1.1Contribution
We present in this paper an algorithm that allows to isolate bulk
data transfer periods (BTP) and application limited periods (ALP)
within a connection for any type of application using TCP as trans-
port protocol. We show through examples that unless the effects
of the application are filtered out, studying the end-to-end path and
traffic characteristics (burstiness, loss rate, round-trip times etc.)
from a network point of view can produce biased results. We de-
fine a BTP as a period where the TCP sender never needs to wait
for the application on top to provide data to transfer. Other time pe-
riods are defined as ALPs. Our algorithm to identify BTPs within
a TCP connection is generic in the sense that it works regardless of
the type of application on top of TCP. Furthermore, this algorithm
enables a quantitative evaluation of the impact of the application
on the throughput achieved for a given BTP. The algorithm pro-
cesses bidirectional TCP/IP headers passively collected at a single
measurement point. It may not always be possible to capture the
traffic in both directions, e.g. in the backbone where connections
may have asymmetric upstream and downstream paths [8]. Never-
theless, we argue that unidirectional traces are often not sufficient
for in-depth analysis, as is the case for round-trip time (RTT) esti-
mation.
We apply the algorithm to a variety of traces each of which con-
tains traffic generated by a single application. Most of these traces
are extracted from the same public set of traffic traces of an ADSL
access network [1]. We show that different applications have a very
different impact on the underlying flow of TCP packets. Through a
sequence of case studies/examples, we show the usefulness of sep-
arating BTPs and ALPs in order to study key metrics of a TCP/IP
path such as throughput or round trip times.
1.2Related Work
Pioneering research work on TCP root cause analysis was done
by Zhang et al. in [16] where they identify application limitation

Page 2

as one of the possible causes for achieving a given throughput. Our
work differs from theirs by providing a method to isolate the bulk
data transfers for further analysis and to evaluate the effect of the
application in a quantitative way.
Allman[2] recommends tocarefullychoosetheapplicationwhen
evaluating TCPperformance. Weontheother hand propose tomin-
imize the effect of the application in the case when it is impossible
to make such a choice.
In a previous work [14] we have presented an algorithm based
on time series that was specifically designed to analyze TCP traffic
generated by BitTorrent. It uses thresholds that need to be cali-
brated for each type of traffic separately. In this paper we present a
more general solution designed to work without calibration for any
type of application.
2.INTERNET APPLICATIONS AND TCP
Figure 1 describes the way data flows from sender to receiver
application using a single TCP connection. The interaction hap-
pens through buffers: at the sender side the application stores data
to be transmitted by TCP in buffer b1, while at the receiver side
TCP stores correctly received and ordered data in buffer b2 that
is consequently read by the receiving application. We focus only
on the behavior of the sending application since it projects directly
the application protocol behavior while the receiving application
should always read the buffer b2 whenever it contains data1. When
the application sends data constantly, buffer b1 in Figure 1 always
contains data waiting to be transferred. We refer to such a period
as Bulk Transfer Period (BTP). In other cases, when the applica-
tion limits the throughput achieved, TCP is unable to fully utilize
the network resources due to lack of data to send. We call such a
period Application Limited Period (ALP). The interaction between
the sending application and TCP manifests itself in the traffic in
diverse ways depending on the type of application. To illustrate
our point, we will present time vs. sequence number plots of TCP
traces that carry different types of application traffic. The plots are
created using xplot (www.xplot.org). The bottom line tracks the
received acknowledgments and vertical arrows indicate sent data
packets. A diamond on top of a vertical arrow means that the data
in this packet was “pushed”, i.e. sent with a Push flag. “Pushing”
is a way for the application to notify TCP that this piece of data
should be sent right away even if it is not a full size (MSS) packet,
because the application does not have more data to provide at the
moment.
Application
TCP
Application
TCP Network
buffers
b1
Receiver Sender
b2
Figure 1: Data flow from the sender to the receiver application
through a single TCP connection.
SkypeisanIPtelephony applicationthat produces smallamounts
of data at a relatively constant rate of 32 Kbit/s [4]. Figure 2 shows
a time vs. sequence number diagram of Skype traffic. All packets
sent have the Push flag set and carry only 42 bytes.
1When the receiving application can not read the buffer b2 fast
enough, the receiving TCP will notify thesending TCP by lowering
the receiver advertised window
2200
2100
2000
1900
1800
01.850001.800001.750001.7000 01.6500
sequence number
time
Skype conversation over TCP
?
?
?
?
?
?
?
?
?
?
?
?
Figure 2: A short piece of Skype connection.
A second typeof anapplication produces data inburstsseparated
from each other by idle periods. An example of such behavior is
Web browsing with persistent HTTP connections. The user clicks
on a link to load a web page, causing a transfer period, reads the
page, causing an idle period, and clicks on another link pointing
to the same web site, causing another transfer period. Another ex-
ample is BitTorrent that uses permanent TCP connections to send
blocks of data during transfer periods and keep-alive packets dur-
ing choked periods [6]. Figure 3 shows an example of a typical Bit-
Torrent connection that alternates between transfer periods (“verti-
cal” lines) and choked periods (“horizontal” lines). The upper line
tracks the receiver advertised window. Keep alive messages, visi-
ble as plain diamonds, are sent regularly during the choked periods.
Note that the transfer periods are visible as almost straight lines be-
cause the time scale is much larger than the one in Figure 2, for
example.
1500000
1000000
500000
0
18:30:00 18:25:00 18:20:00 18:15:00
sequence number
time
??????????
?
?????
?
SYN
Figure 3: 20 minutes of a BitTorrent connection.
Some TCP connections may even include combinations of both,
the first and the second type of behavior. For example, a BitTorrent
connection can alternate between choked and transfer periods, and,
in addition, the client application can enforce a transmission rate
limit during the transfer periods.
The third type of traffic is produced by FTP like applications that
typically transmit everything at once (see Figure 4).
These examples illustrate the diverse ways the application can
influence the shape of the TCP traffic. Given such a diversity, it is
quite challenging to design a generic algorithm that separates BTPs
from ALPs since the application may interfere on very different
time scales.

Page 3

ALP
merge, drop=0.8
2.0001 MB / 12 sec
2 MB / 10 sec
= 0.83 > 0.8 => SUCCESS
BTP BTP
5 sec
1 MB
2 sec
100 B 1 MB
5 sec
Figure 5: Successful merger.
merge, drop=0.8
1.11 MB / 11.3 sec
1.1 MB / 3.3 sec
= 0.29 < 0.8 => FAILED
ALPBTPSTP
3 sec
1 MB10 KB
8 sec
100 KB
0.3 sec
Figure 6: Failed merger.
200000
150000
100000
50000
0
56.5000 00:49:56 55.5000 00:49:55 54.5000
sequence number
time
FTP download
FIN
SYN
Figure 4: Entire FTP download connection.
3. THE ISOLATE & MERGE (IM) ALGO-
RITHM
3.1Context
We call our algorithm for identifying BTPs and ALPs the Isolate
& Merge (IM) Algorithm due to the way it proceeds. The algo-
rithm is generic in that it can be applied without any calibration
to traffic from any application. Additionally, it does not depend
on the version of TCP used. Instead, the algorithm relies only on
observing generic behavior common to all TCP versions. We de-
fine a TCP connection as a sequence of packets having the same
source-destination or destination-source pairs of IP addresses and
TCP port numbers. The IM algorithm processes only connections
consisting of atleast 130 datapackets: Connections withfewer than
130 packets are very likely to be dominated by the TCP slow start
algorithm and therefore convey little information about the TCP/IP
datapathfor futureanalysis. Wehavechosen thenumber of packets
to be at least 130, since a TCP sender that starts in slow start needs
to transmit approximately 130 data packets (assuming a MSS of
1460 bytes) in order to reach a congestion window size equal to 64
Kbytes, a typical size of a receiver advertised window [12]. For the
same reasons, we define the minimum required size of a BTP to be
130 data packets. We also define as short transfer period (STP) a
sequence of packets that contains fewer than 130 data packets and
whose rate of transfer is not application limited. We use the term
transfer period (TP) to refer to either a BTP or STP. The IM al-
gorithm identifies BTPs for a single direction of a connection at a
time, since a TCP connection may have two-way data transfers.
3.2Procedures
The IM algorithm consists of two phases: First, it partitions the
connection intoTPsseparatedbyALPs. Inthesecond phase, theal-
gorithm attempts to merge two consecutive TPs including the ALP
that separates these two TPs in order to create a new BTP.
In order to understand the reasoning behind the merging phase,
let us consider how the ALPs differ from the TPs. ALPs reach by
definition a lower throughput than the TPs do, because the appli-
cation prevents TCP from fully using the network resources. Thus,
the application interference is visible as a lowered throughput. The
merging phase is needed because, after the isolate phase, a connec-
tion may be divided into many BTPs and STPs separated by very
short ALPs. It would be often desirable to combine these periods
into one long BTP for subsequent analysis if the effect of these
short ALPs on the overall throughput achieved is small. For the
above reasons, the procedure of merging periods is based on com-
paring the throughputs of the periods involved in the merger.
The mergers are controlled with the threshold parameter drop ∈
[0,1]. Figures 5 and 6 demonstrate successful and failed mergers,
respectively. Periods can be merged if and only if the throughput
of the resulting merged BTP (total bytes divided by total duration)
is higher than the drop value times the throughput of the TPs com-
bined together excluding the ALP in the middle (sum of bytes of
TPs divided by sum of durations of TPs). In this way, the drop
parameter value limits the maximum amount of application inter-
ference, i.e. throughput decrease, within the resulting merged pe-
riods. Hence, by selecting a specific value of the drop parameter,
the user can choose the desired maximum amount of application
interference allowed to be present in the resulting BTPs that can
then be used for further analysis. The algorithm for merging peri-
ods proceeds in an iterative manner, which ensures that eventually
all possible mergers, and only those allowed, are performed.
Experimenting with different values of the drop parameter al-
lows for a quantitative analysis of the application impact on the
throughput achieved, which, as we show in Section 6, can provide
interesting input for characterizing the application behavior. The
procedures corresponding to thesetwo phases arecalled isolate and
merge and presented in detail in Appendix A.
We validated the IM algorithm with the help of the Web100 soft-
ware [11] that allows querying the TCP state information of active
TCP connections. We cross-checked the results of applying IM on
a large trace of Internet traffic with the Web100 data captured at the
sender and observed that the results matched in more than 95% of
the cases. The details are in Appendix B.
4.DATA SETS
We applied the IM algorithm to eight application-specific traffic
traces because we wanted to perform per-application analysis on
the resulting periods (see Sections 5 and 6). Except for the SSH
data set, all of the application specific traces were extracted from
the same original public ADSL access network traces (the first 19
days from Location 4 traces in [1], two traces per day, 15 minutes
each) by filteringon the well-known TCP port numbers of these ap-
plications. This method gives in most of the cases solely the traffic
from the expected application except for some cases where well-
known TCP ports, such as port 80, are used, for example, by P2P
applications to bypass firewalls. The SSH traffic data set consists
of scp downloads from various locations all over the world to a

Page 4

Table 1: Trace characteristics.
eDonkeyFTP data
4661,466220
4d 22h 18d 22h
44M 9M
20GB 7GB
1.6M5.9K
23K1.1K
5.5K 390
690MB4.3GB
3.0GB5.2GB
550KB2.9MB
780KB 13.4MB
2m 23s55s
4m 14s4m 31s
traffic type
port numbers
duration
packets
bytes
cnxs
cnxs carrying >10KB
cnxs with BTPs
bytes in BTPs (drop=1)
bytes in BTPs (drop=0.9)
avg BTP size (drop=1)
avg BTP size (drop=0.9)
avg BTP dur. (drop=1)
avg BTP dur. (drop=0.9)
BitTorrent
6881-6889
4d 22h
31M
19GB
150K
30K
10K
2.9GB
7.4GB
640KB
850KB
38s
1m 45s
SSH
22
7d
3.6M
2.9GB
48K
670
442
2.7GB
2.8GB
4.8MB
5.9MB
14s
17s
Gnutella
6346,6347
18d 22h
8M
2GB
410K
8.0K
940
560MB
1.0GB
590KB
1.2MB
51s
2m 26s
HTTP(S)
80,443
4d 22h
14M
9GB
590K
53K
3.2K
4.5GB
4.8GB
1.6MB
1.9MB
35s
51s
FastTrack
1214
18d 22h
20M
14GB
360K
11K
5.6K
7.0GB
11GB
770KB
1.9MB
1m 47s
5m 13s
WinMX
6699
18d 22h
13M
5GB
6.3K
3.3K
480
150MB
1.2GB
290KB
3.7MB
27s
6m 7s
single destination.
Table 1 summarizes the characteristics of the traces. We used
th = 3 with Algorithm 1 (see Appendix A for details). Regardless
of the application type, BTPs were found only in a small fraction
of the connections, which is mostly explained by the large number
of small connections and the fact that BTPs are required to con-
tain at least 130 packets. BTPs generally carry the majority of the
bytes. Though, BitTorrent and eDonkey traffic are exceptions with
BTPs containing a smaller fraction of the bytes, which can be ex-
plained by the fact that these applications often throttle their trans-
mission rates, hence, generating only ALPs. The average size of
the connections including no BTPs was below 30KB for all ap-
plications except for FTP which had an average of 220KB. Oddly
enough, the largest ones of these FTP connections, carrying up to
90MB, appeared clearly to be rate limited by the application send-
ing constantly small packets. These unexpected examples clearly
emphasize the need to identify the BTPs even for “bulk transfer
applications” such as FTP.
5. DISTORTION DUE TO ALPS ON END-
TO-END PATH STUDIES
BTPs can capture the TCP/IP path properties in a very different
way than do the entire connections. If TCPsends at full rate, the ef-
fects for the data path (e.g. congestion) and, thus, the behavior ob-
served (e.g. retransmissions), are different from the situation when
the application limitsthe transmission rate. Inmany cases (network
health monitoring, network awareapplications etc.), itwould bede-
sirable tocapture only the effectsof the TCP/IPdata path excluding
the application impact.
In this section, we attempt to quantify what we call distortion in
the TCP/IP data path analysis results due to the presence of ALPs.
We present two case studies. The first one focuses on the character-
istics of the rates, i.e. the throughput achieved on a given data path.
In thesecond one, weperform running estimatesof theRTTof con-
nections. Note that our goal is not to demonstrate that connection-
level measurements yield necessarily wrong results (especially in
the first case study). Instead, through the following examples, we
want to underline the fact that one should carefully consider what
is exactly being measured when drawing conclusions based on the
measurements. There are cases when connection-level measure-
ments are desirable, however, there are also other cases where they
can be misleading.
5.1Studying Characteristics of Rates
Throughput is one of the key measures of the performance of an
Internet application. It can be seen as a manifestation of the under-
lying TCP/IPdata path characteristics at a given timeinstant. How-
ever, if the application controls the transmission rate, such an inter-
pretation is false. In order to demonstrate the difference in measur-
ing the mean throughput on connection level vs. filtering out first
the application impact, wecompared themean ratesof BTPswithin
a connection to the mean rates of entire connections. Throughout
this study, we used drop = 0.9 when identifying the BTPs used
in the analysis, which means that we allowed a maximum of 10%
of reduction in the throughput of the merged TPs. We computed
the ratio(
connection bytes
connection duration)
?
?BTP bytes
?BTP duration
? , which is the throughput computed
for the entire connetion divided by the throughput obtained when
including only the bytes and durations of the BTPs of the connec-
tion. The mean values of the ratios for each application data set are
in Table 2. These values show that the results can differ a lot de-
pending on the application. The interpretation depends also on the
application: For example, while the average download throughput
of a BitTorrent BTP might express the average achievable through-
put of that specific TCP/IP path, the average download throughput
of an entire BitTorrent connection could be interpreted as the aver-
age rate a specific peer is providing to another peer. On the other
hand, in the case of web browsing using persistent HTTP connec-
tions, a difference between these two throughput values could be
interpreted as a sign of particular user behavior (e.g. large differ-
ence means that the user spends a long time reading the current
page before clicking on a new link).
Table 2: Mean Values of the Throughput Ratio.
traffic type
BitTorrent
avg tput ratio
0.36
traffic type
Gnutella
avg tput ratio
0.74
eDonkey
0.86
HTTP(S)
0.64
FTP data
0.96
FastTrack
0.94
SSH
0.73
WinMX
0.87
In [16] and [3], the authors looked at the rate distributions and
observed that they were well described by a log-normal distribu-
tion. As in both of those papers, we also use Q-Q plots to visually
check the validity2of this hypothesis in our data sets. Figure 7
shows a Q-Q plot that compares the distribution of log of through-
puts of the BitTorrent BTPs (using drop = 0.9) to the normal dis-
tribution. Figure 8 shows a similar Q-Q plot comparing the normal
distribution to the log of throughputs of the entire BitTorrent con-
nections transferring at least 100KB. The log of BTP rates (Figure
7) seem visually to agree rather well with the normal distribution
since the markers (+) showing quantile to quantile comparison do
2In fact, Q-Q plot can only be used to reject the normality hypothe-
sis as it does not constitute a normality test. However, at this point,
we only want to do a rough comparison with the normal law.

Page 5

−4−2
Standard Normal Quantiles
024
4
6
8
10
12
14
Quantiles of log of throughput
Figure7: Q-Qplotof through-
puts for the BitTorrent BTPs
having drop = 0.9.
−505
0
2
4
6
8
10
12
Standard Normal Quantiles
Quantiles of log of throughput
Figure8: Q-Qplotof through-
puts for the BitTorrent con-
nections transferring at least
100KB.
not deviate much from the dashed line, which passes through the
25th and 75th percentiles, except at the highest quantiles implying
a longer tail than the one of normal distribution. The same can not
be stated about the distribution of the rates of the entire connec-
tions (Figure 8), which is skewed to the right since both ends of
the quantiles of the rates are larger than the quantiles of the normal
distribution.
The authors found in [16] that the rates and sizes of transfers
were highly correlated (coefficients of correlation consistently over
0.8) which they considered as an indication of specific user be-
havior: the users choose what they download based on the avail-
able bandwidth. Table 3 contains the coefficients of correlation
between the rates (throughputs) and sizes (number of bytes trans-
ferred) computed for entire connections and BTPs of our data sets.
In the case of BTPs, average throughput and sum of transferred
bytes was computed for each connection. As in [16], we compared
the logarithms of the rates and sizes because of the large range and
uneven distribution.
Table 3: Coefficients of correlation between log of through-
put and log of number of bytes transferred. Only connections
transferring at least 100KB were included and drop = 0.9 was
used when determining the BTPs.
traffic type
connections
BTPs
traffic type
connections
BTPs
BitTorrent
0.92
0.37
Gnutella
0.63
0.48
eDonkey
0.66
0.42
HTTP(S)
0.19
0.13
FTP data
0.41
0.32
FastTrack
0.56
0.52
SSH
0.83
0.16
WinMX
0.91
0.77
Wealsoobservesomecorrelationthroughout our datasets. How-
ever, the results vary a lot depending on the application. Further-
more, when comparing connection and BTP-level results for each
application, the difference in the degree of correlation varies from
negligible (HTTP and FTP) to very large (BitTorrent and SSH).
The large difference for BitTorrent traffic is due to two character-
istics specific to the application protocol. First, BitTorrent favors
fast peers. Fast peers, i.e. the peers having large available band-
width, are less likely to be choked and, hence, get to transfer more
bytes than slower peers. Slow peers are more likely to be choked
more often and, thus, transfer less bytes. While this effect is also
visible in the correlations when looking at the BTPs, it is ampli-
fied when the throughput is computed for the entire connection.
The reason is that the choked periods, during which the peer is idle
(see Figure 3), are identified as ALPs, which, therefore, decrease
the connection-level throughput but do not affect the throughput of
the BTPs. The second reason are the BitTorrent download connec-
tions that are not used simultaneously to upload torrent data. In this
case, the upstream data traffic of these connections consists only of
periodically sent very small packets containing requests for new
chunks and other control messages. This type of traffic generates
very low-rate (< 5Kbit/s) small-size connections that are identi-
fiedasALPsand, therefore, excluded whenstudying theBTPs. The
large difference in the degree of correlation in connection-level and
BTP-level results for SSH traffic is explained by the parameter ne-
gotiation in the beginning of the connection. This negotiation takes
a relatively long time (even up to a few seconds) during which few
bytes are transferred. Since the very low throughput during this ne-
gotiation phase is controlled by the application, this period is iden-
tified as an ALP. Therefore, it only decreases the connection-level
throughput. Moreover, the fewer are the bytes transmitted in total,
the larger is the impact on the rate of the connection.
Overall, the degrees of correlation seem to be slightly higher
for the P2Papplications (BitTorrent,eDonkey, Gnutella, FastTrack,
and WinMX). One explanation is their ability to download a given
file in pieces from several sources simultaneously: the faster the
peer, the more it contributes by transferring more pieces, i.e. a
larger portion of the file. This behavior may be reflected in both
connection-level andBTP-levelresultsdepending onwhether atrans-
fer of multiple pieces is identified as a single or multiple BTPs. In
the case that the application waits for a download of a piece to
finish before requesting a new piece, which can cause an ALP, a
transfer of a piece is likely to be identified as a separate BTP. If the
application “pipelines” the requests, the transfer of multiple pieces
is likely to be continuous and be identified as a single BTP.
The relatively low correlation for FTP and HTTP contradicts
with the results in [16] and suggests that users download content
regardless of the available bandwidth. In other words, the content
is what matters most. The data sets used in [16] date back to 2001
and 2002, which could partially explain this change in behavior.
Five years ago, many users were still accessing the Internet using
standard modem and ISDN lines with relatively low access capac-
ities and paying for each minute of connection. In such a case, a
cost-aware user may not want to wait a long time for a large down-
load to finishand, thus, aborts it or does not start it at all if the avail-
able bandwidth is low. An impatient user may do the same. Today,
the standard is broadband access (e.g. DSL and cable modems)
which is typically flat rate, as is the case for our data sets originat-
ing from an ADSL access network. In addition, the typical access
link speeds have multiplied. Therefore, there are fewer reasons for
choosing the content size based on the available bandwidth today.
We also ranked connections based on their rates. We identified
the set of 50 fastest connections for BitTorrent, eDonkey, and SSH
traffic first by computing the throughput for the whole connection
and then by computing the average of the BTP throughputs for a
given connection when using drop = 0.9. When comparing the
resulting two sets, we found only 13, 22, and 36 common connec-
tions for BitTorrent, eDonkey, and SSH traffic, respectively. These
numbers indicate that the ranking is highly affected by the appli-
cation behavior. As an example, Figure 9 shows the corresponding
throughputs for the common connections in the two sets for Bit-
Torrent traffic. We observe that the ranking is completely different
also within the set of the common connections.
5.2Case Study on RTT Estimation
The case of RTT estimation is particularly interesting, since the
ALPs may distort the results in yet another way when the measure-
ment point is in the middle of the TCP/IP path, a common situation