An Analysis of TCP Maximum Segment Sizes

Shane Alcock and Richard Nelson

University of Waikato, Hamilton, New Zealand
Email: {salcock, richardn}@cs.waikato.ac.nz

AbstractThe Maximum Segment Size (MSS) is a basic yet

critical property of any TCP connection. Yet surprisingly, there
have been no recent studies examining the MSS values that
are announced and utilised by TCP senders in any detail. This
paper analyses packet traces from several different locations and
investigates the advertised and observed MSS values for each
captured TCP connection. In particular, this study focuses on the
range of MSS values that are announced by TCP endpoints and
the relationship between the advertised MSS value and the MSS
used by TCP senders. We find that although 1460 bytes remains
the most commonly announced MSS, it accounts for less than half
of all MSS advertisements. Instead, slightly smaller MSS values
are increasing in popularity due to the rise in PPPoE and VPN
technologies. We also find that many TCP sessions do not utilise
either of the announced MSS values, possibly due to application
behaviour, and that a small but not insignificant number of TCP
senders transmit segments larger than permitted by the MSS
announced to them.

I. I NTRODUCTION
The Maximum Segment Size (MSS) is a fundamental attribute of a TCP connection that defines how large blocks
of data are divided into segments for transmission over a
network. Despite this, there have been no recent studies that
have examined the MSS values that are announced and used
by TCP senders in any detail. Rather, there are several wellknown common MSS values that are often assumed to be
prevalent on the Internet; in particular, 1460 byte MSS values
are typically utilised by TCP traffic models. However, this
is done without any reference to recent measurements that
confirm these values as being representative of contemporary
Internet traffic.
In this paper, we present the results of using passive network
packet traces to investigate the MSS values that are announced
and utilised by TCP senders. Traces from several different
data sets were analysed, including captures of residential DSL
traffic, to ensure that the results encompass a broad sample
of users, devices and applications. We have examined the
distribution of MSS values that were announced in each trace
set and have identified occasions where the announced MSS
did not correspond to the MSS that the sender was using.
The primary contribution of this work is that it is a dedicated
and in-depth study of the MSS as utilised by modern TCP
hosts. Given the rate and nature of evolution of the Internet,
it is important to periodically re-evaluate the conventional
wisdom regarding properties like the MSS to ensure that
existing models of TCP accurately reflect the traffic that is
observed in reality. For instance, the increased prevalence of
protocols and technologies which reduce the effective MTU
for links, such as the Point-to-Point Protocol over Ethernet

(PPPoE) and Virtual LANs, will also result in a reduction in

the MSS that can be supported by a TCP endpoint. However,
until now there have been no published studies that have
investigated the impact of these technologies. Recent studies
that have examined the MSS, such as [1], have done so in a
cursory fashion as part of a much wider study of basic TCP/IP
traffic properties within a single data set and therefore have
not studied the topic in any depth.
In addition, we have identified and documented some problems that arise when attempting to determine the MSS used
by a TCP sender from a passive packet trace. These problems
include TCP senders that violate the TCP standard by transmitting segments that exceed the MSS that was announced
to them and the effect of middleboxes that modify the MSS
announcement after it has been observed by the passive monitor. These have significant implications for passive analysis
approaches that depend on an accurate estimate of the MSS.
For example, the TCP object extraction method described in
[2] uses segments that are smaller than the MSS to infer
object boundaries. Another example is passive congestion
window estimation, such as in [3], where the behaviour of the
NewReno congestion control algorithm [4] differs depending
on whether the amount of data acknowledged is greater or
smaller than the MSS. In both cases, the MSS must be inferred
passively from packet traces but if the inferred MSS differs
from that which was actually used by the TCP sender, the
resulting analysis may produce results that do not reflect real
TCP behaviour.
II. BACKGROUND
The TCP Maximum Segment Size is defined as the largest
TCP segment that can be accepted by a receiver for a TCP
connection. This value is measured in data octets following the
IP and TCP headers; these headers are not counted towards the
segment size (however, IP and TCP options present in these
headers are included in the segment size [5]). Each endpoint
participating in a TCP connection can announce an MSS on an
outgoing SYN packet during connection establishment using
the TCP MSS Option [6]. There are two independent MSS
values announced for any given TCP connection; one for
each direction. By definition, a transmitting host must not
send a TCP segment that exceeds the MSS announced by the
destination host.
The MSS that will be announced by a host is typically
determined by subtracting a fixed value from the Maximum
Transmission Unit (MTU) for that host. For IPv4, the subtracted value is usually 40 bytes, which is the combined size of

a TCP and IPv4 header without any trailing options, although

other values are possible [6]. The IPv6 header is larger than
the IPv4 header, so in that case 60 bytes will be subtracted
from the MTU instead.
A host will always know the MTU of the interface being
used for the TCP connection, but it may not know about links
further along the path from the remote endpoint to the host.
Path MTU discovery can be used to determine the MTU for
the entire path, but this technique is not always successful.
Without accurate path MTU information, it is possible for
a host to announce an MSS that will not be valid for the
entire path that the TCP connection will operate over. This
is exacerbated by the growing prevalence of protocols that
operate between the link and IP layers, such as Point-to-Point
Protocol over Ethernet (PPPoE) and 802.1Q (more commonly
known as Virtual LANs), and tunnelling protocols (including
the Layer 2 Tunnelling Protocol (L2TP) and Virtual Private
Networks (VPNs)). These protocols and technologies reduce
the effective MTU for the path.
As a result, it is common practice to adjust the announced
MSS to decrease the probability of a lower path MTU invalidating the MSS and causing TCP segments to be fragmented.
In some cases, this is done manually by a user editing the
configuration of the operating system on the TCP endpoint and
changing the interface MTU to a value that they deem sensible.
Network administrators can similarly adjust the configuration
of network devices to use a lower MTU value to minimise the
likelihood of segment sizes exceeding the path MTU.
Another solution is MSS clamping, where a device in
the path automatically adjusts the announced MSS value in
outgoing TCP SYN packets to a lower value. This may be
based on knowledge of a neighbouring link, such as a DSL
router placing an upper bound on MSS advertisements over a
PPPoE link to account for the eight bytes required for a PPPoE
header. This is also commonly observed with network devices
that provide VPN support, where the MSS is limited to ensure
that the tunnelling overhead will not exceed the MTU of the
path that the VPN is operating over.
Therefore, there is reason to suspect that the current assumption that most TCP senders announce a 1460 byte MSS no
longer applies. Rather, it is likely that the range of announced
MSS values is much larger than previously thought. The
increased frequency of hard-coded MSS adjustments may also
lead to misconfigurations where the MSS is set to an incorrect,
inefficient or simply nonsensical value. This is especially likely
if an end-user is involved, as they may not fully understand
the implications of their actions.
III. DATA S ETS
For the purposes of this study we have analysed several sets
of packet traces that have been collected at different locations
around New Zealand by the WAND Group at the University
of Waikato. The basic properties of the traces, including the
number of TCP connections that we examined during the
course of our study, are shown in Table I. Each of the trace
sets and the methods used to capture them are documented in

TABLE I
L IST OF ANALYSED DATA SETS .
Name
ISP B
Waikato
ISP C-I
Auckland
ISP C-II

Date
Feb 2007
Feb 2008
Jan 2009
Oct 2009
Jan 2010

Duration
5 days
6.5 days
10 days
9 days
9 days

TCP Flows
508 million
20 million
130 million
230 million
197 million

detail on the WITS trace archive website [7], so the discussion

of the traces will be limited to aspects that are relevant to our
MSS analysis. All of the trace sets were captured within the
past four years meaning that the results presented here are both
relevant and timely. Each of the examined traces was captured
by monitoring a symmetric link, enabling us to analyse and
compare both halves of a given TCP connection.
Three of the trace sets, ISP B [8], ISP C-I [9] and ISP
C-II [10], were captured from two different New Zealand
ISPs, enabling us to examine the MSS values being used
by residential broadband users as well as the wide variety
of servers and peers that these users typically connect to. In
most cases, these users self-administer their home networks
and may be more likely to misconfigure the announced MSS
on a device. The variety of devices and operating systems
being used is also likely to be much wider compared to an
academic or corporate network.
The ISP B trace set was taken at a prominent New Zealand
ISP and was the largest of the data sets that we examined. The
traces contain incoming and outgoing traffic for a subset of the
residential DSL customer base. The ISP C-I and C-II trace sets
were captured from a smaller New Zealand ISP, but the data
is more recent than the other ISP trace set and encompasses
all of the customers, including corporate and wireless users.
However, we used BPF filters based on known IP ranges
to examine DSL subscribers only to ensure the results are
comparable with the ISP B data. The two ISP C data sets
were taken exactly one year apart, so we can also examine
trends in MSS behaviour over time.
The remaining two trace sets were captured from academic
networks as part of long-running and well-known trace sets.
Academic networks and the end hosts within are usually
administered by professionals who should be much less likely
to adjust the MSS or MTU for a link unnecessarily. However,
many academic networks often employ firewall appliances or
similar hardware that reduce the path MTU and may therefore
affect the MSS. Virtual Private Networks (VPNs) are also more
likely to be utilised, which will also affect the MSS.
We selected several days of data from the Waikato VI trace
set [11] which was captured at the edge of the University
of Waikato network. The IP addresses in the Waikato traces
were sanitised and the anonymisation key was changed once
per week. This meant that we were unable to analyse more
than a week of data at once, as our analysis technique required
host IP addresses to be consistent. The final trace set analysed
was a short trace set captured at the University of Auckland,

IV. R ESULTS

1e+07
1e+06
100000
Frequency

called Auckland X [12], which was captured in October 2009.

It should be noted that only IPv4 traffic was examined in
the course of this study, primarily due to the lack of IPv6
traffic in most of the trace sets that were available to us. One
avenue for further research would be to repeat this study for
IPv6 hosts.

10000
1000

A. Announced MSS Values

10
1
1

10

100
1000
10000
Announced MSS (bytes)

100000

(a) ISP B
1e+06
100000

Frequency

10000
1000
100
10
1
10

100
1000
10000
Announced MSS (bytes)

100000

(b) Waikato
1e+07
1e+06
100000
Frequency

Figure 1 shows the distribution of announced MSS values

from the ISP B, Waikato and ISP C-II data sets. Due to space
constraints, we have not included graphs for all of the trace
sets here.
The announced MSS values were determined by extracting
the value of the MSS TCP option from the SYN packet sent
by the TCP host. If no MSS option was present, the MSS was
assumed to be 536 bytes [6]. To avoid any bias towards hosts
that had participated in multiple connections, each unique MSS
value was counted only once per announcing host. Also, MSS
values that were advertised to a host that did not subsequently
transmit any payload-bearing packets for that connection were
ignored to eliminate probes, scans and exploit attempts from
the analysis.
As expected, there was a heavy concentration of values
around 1460 bytes in all of the trace sets but the range of
announced values was much wider than we had anticipated.
For instance, there were 1029 unique values announced in the
ISP B trace, ranging from a single byte (which was advertised
by 3 unique hosts) through to 65535 bytes (announced by
8 unique hosts), the maximum allowable value given that
the MSS option is limited to 16 bits. It is hard to imagine
circumstances whether the values at either end of the range
are practical. It would be very inefficient to conduct a TCP
exchange where each segment can be no larger than one byte
and no link technology currently exists that could support 64
kilobyte segments.
However, the overall proportion of announced MSS values
that were outside of a conventional range was very small, as
shown in Table II. Across all the examined data sets, less than
0.4% of announced MSS values were not between 536 and
1460 bytes inclusive. We define this as a conventional range
given that 536 bytes is the default MSS value [6] and 1460
bytes is the largest MSS value possible for standard Ethernet.
The most popular announced MSS values for each data set
are shown in Table III. 1460 is the most frequently announced
value by a significant margin but still accounted for less than
half of all MSS announcements in each trace set. 1452 and
1440 were also prominent values and are primarily due to
DSL subscribers that are using PPPoE to connect to their
ISP. PPPoE reduces the Ethernet MTU by 8 bytes resulting
in a 1452 byte MSS whereas Windows operating systems will
often use an MTU of 1480 for PPP over Ethernet interfaces
[13]. Subtracting 40 bytes then produces the 1440 byte MSS
seen in the table. Comparing the ISP C data sets suggests that
the popularity of 1460 byte MSS announcements decreased in
2010 in favour of MSS values that are compatible with PPPoE.

100

10000
1000
100
10
1
1

10

100
1000
10000
Announced MSS (bytes)

100000

(c) ISP C-II

Fig. 1.

Distribution of announced MSS values in the datasets.

536 byte MSS announcements barely featured in any of

the ISP trace sets, accounting for less than 0.25% of MSS
announcements in each case. Only in the Waikato trace set did
an announced MSS of 536 bytes feature prominently, where
21.1% of all TCP half-connections either explicitly announced
a 536 byte MSS or did not include an MSS option on the
initial SYN. Further investigation revealed that only 1.4% of

TABLE II
R ANGES OF ANNOUNCED MSS VALUES
MSS Range
1 - 535
536 - 999
1000 - 1299
1300 - 1439
1440 - 1460
1461 - 8960
8961 - 66535

ISP B
0.063%
0.269%
1.215%
17.980%
80.423%
0.046%
0.003%

Auckland
0.017%
0.275%
1.272%
21.075%
77.327%
0.030%
0.004%

Waikato
0.271%
21.103%
0.779%
15.834%
61.977%
0.031%
0.005%

ISP C-I
0.195%
0.274%
1.544%
16.792%
81.195%
0.001%
0.000%

ISP C-II
0.057%
0.213%
0.809%
20.65%
78.27%
0.001%
0.001%

TABLE III
M OST FREQUENTLY ANNOUNCED MSS VALUES
ISP B
1460 (44.8%)
1452 (19.3%)
1440 (15.6%)
1360 (3.40%)
1414 (2.83%)
1412 (2.03%)
1420 (1.95%)
1380 (1.28%)
1260 (1.07%)
1432 (1.05%)

Auckland
1460 (39.5%)
1452 (19.1%)
1440 (15.7%)
1360 (5.33%)
1380 (2.92%)
1400 (2.47%)
1420 (2.44%)
1442 (2.09%)
1412 (1.41%)
1414 (1.38%)

Waikato
1460 (30.6%)
536 (21.1%)
1452 (17.5%)
1440 (12.5%)
1360 (3.28%)
1380 (2.31%)
1420 (1.92%)
1412 (1.81%)
1414 (1.33%)
1400 (0.95%)

all 536 byte announcements in the Waikato data came from

a host within the university network. Given that the Waikato
passive monitor was located on the edge of the network, any
clamping of the MSS to 536 bytes must have occurred prior
to the packet reaching the university.
The announcements were coming from a variety of networks, so they cannot be attributed to a single source with
a small path MTU, such as another university. Also, 79%
of the 536 byte MSS announcements were explicit, rather
than due to the absence of an MSS option, so the cause was
unlikely to be a device that discards TCP options. Of the halfconnections in the Waikato data that explicitly announced a
536 byte MSS, 97% involved TCP port 25 (SMTP). However,
these half-connections only accounted for 15% of all TCP
port 25 sessions observed in the entire trace set. This suggests
that this behaviour is related to email (albeit only some of
the observed mail), but it is not clear what benefit is gained
through clamping the MSS to 536 bytes.
B. Observed MSS Values
Figures 2 and 3 are scatter plots showing the announced
MSS value for a TCP half-connection against the largest
segment transmitted by the sender (including TCP and IP
options) for that half-connection. To remove results where
the application never had a full-sized segment to send, only
half-connections where the observed MSS was achieved by
multiple segments are shown. Also, the X-axis has been
limited to a maximum of 1500 bytes to ensure that the
patterns in the data can be seen clearly. Because the traces
were captured from an Ethernet link, there were no observed
segments that exceeded 1500 bytes in size.

ISP C-I
1460 (46.4%)
1440 (17.6%)
1452 (15.2%)
1360 (4.12%)
1380 (1.95%)
1414 (1.79%)
1420 (1.50%)
1412 (1.45%)
1400 (1.12%)
1456 (0.97%)

ISP C-II
1460 (40.5%)
1440 (22.7%)
1452 (13.5%)
1360 (5.70%)
1420 (2.87%)
1380 (2.41%)
1414 (2.20%)
1400 (1.56%)
1412 (1.03%)
1408 (0.77%)

1600
1400
Observed MSS (bytes)

Rank
1
2
3
4
5
6
7
8
9
10

1200
1000
800
600
400
200
0
0

200

400 600 800 1000 1200 1400

Announced MSS (bytes)

Fig. 2. Comparing the announced MSS against the observed MSS in the
ISP B traces.

There is a clear diagonal line in both graphs where the

observed MSS matches the announced value, representing the
expected scenario where the advertised MSS is utilised by the
sender. There is also vertical banding occurring at many of
the commonly announced values, such as those appearing in
Table III. This is primarily due to the increased sample size
at those values, although it does also suggest that there is a
degree of independence between the announced and observed
MSS values.
There were also a number of occasions where the observed
MSS exceeded the value that had been announced, i.e. a point
appears above the diagonal line, which is a violation of the
standard defined in [6]. The violations were not restricted
to instances where the announced MSS might be regarded

Middlebox

1600

Observed MSS (bytes)

1400

MSS=1460

MSS=536

Host B

Host A

1200

MSS=536

1000

MSS=1460

800
600

Monitor

400
200
0
0

200

400 600 800 1000 1200 1400

Announced MSS (bytes)

Fig. 3. Comparing the announced MSS against the observed MSS in the
ISP C-II traces.

as impractical, e.g. below 536 bytes, where sending larger

segments might be expected. There also appears to be some
horizontal banding at 1414 and 1360 bytes, both of which were
shown to be commonly announced values. This may be due
to the sender adopting the MSS value from an announcement
other than the one provided by the receiving host.
Table IV categorises and quantifies the disparities between
the announced and observed MSS values as shown in the
previous graphs. Again, only half-connections where the observed MSS was achieved by more than one packet were
taken into account. The first column describes which (if any)
of the announced MSS values for the connection matched
the observed MSS, where the expected scenario is that the
observed MSS would match the MSS advertised by the receiver. In the event of the sender and receiver announcements
being equal, the half-connection was deemed to have matched
the receiver MSS. The second column distinguishes between
observed MSS values that were less than or equal to the MSS
announced by the receiver, which we term valid, and those that
exceed the advertised value. The case where the observed MSS
matched the size advertised by the receiver is, by definition,
always valid.
Overall, the frequency of invalid behaviour is low across
all of the trace sets that we examined: less than 0.3% of the
half-connections utilise an MSS greater than the one that was
announced by the receiver. The majority of these cases appear
to occur when the sender replaces the receivers announced
MSS with their own larger value. This is probably caused
by an error in the sender TCP implementation. For instance,
the two advertised values may have been inverted, due to a
programming error or a misinterpretation of the specifications.
It is also possible that the sender did not treat both halves of
the connection as distinct, i.e. only one MSS variable was
stored for each connection.
One interesting result is the prevalence of senders utilising
an MSS other that announced by either of the TCP endpoints
involved in the connection, especially in the ISP datasets.
We suspect that application behaviour may be a major con-

Fig. 4. An illustration of how the location of the passive monitor can affect
an analysis of MSS announcements. If a device in the middle of the path is
adjusting the announced MSS, the change is only seen in one direction at the
passive monitor.

tributing factor to this result, whereby the application writes

consistently-sized objects to the network that are smaller than
the MSS. This object size is regarded as the observed MSS
by our analysis, when the TCP sender never received enough
data at any one time to send a genuine MSS-sized segment.
We also observed instances where the sender adopted the
MSS that they announced rather than the one announced to
them. This occurred in over a third of the Waikato halfconnections. Although this does not strictly conform to the
directional independence implied in [6], this approach is
legitimate whenever the senders MTU limits the outbound
segment size below that announced by the receiver. In this
case, it makes sense for the sender to override the announced
value to avoid fragmentation.
However, there is another possibility, which we demonstrate
in Figure 4. It shows the MSS being clamped by a middlebox,
but the clamping is only observed in one direction due to the
location of the passive monitor. As a result, it appears that
Host A has adopted the smaller MSS that it had advertised to
Host B rather than the 1460 byte MSS that Host B announced
to it. In reality, both endpoints had received a 536 byte
announcement due to the MSS clamping performed by the
middlebox. This is the likely reason for the high rate of sender
MSS adoption observed in the Waikato trace, especially given
the frequency of 536 bytes announcements observed from
outside the university.
V. R ELATED W ORK
John and Tafvelin [1] conducted a study of TCP/IP header
anomalies using traces captured from a single Internet backbone link in April 2006. A similar study was published by
Allman [14] using packet traces taken from a single web server
between 1998 and 2000. In both cases, the announced MSS
values were examined as part of a much broader investigation.
Both studies noted that there were some unexpected values
being announced using the MSS option, but did not pursue
these in any depth. Allman also compared the announced
MSS with the largest segment observed but did not report
any occasions where the announced MSS was exceeded by a
TCP sender.

TABLE IV
R ELATIONSHIP BETWEEN THE OBSERVED MSS AND THE ADVERTISED VALUES FOR THE CONNECTION .
MSS Matched
Receiver
Sender
Sender
Neither
Neither

Valid
Yes
Yes
No
Yes
No

ISP B
68.5%
13.3%
0.2%
17.9%
<0.1%

Auckland
77.8%
11.4%
< 0.1%
10.8%
< 0.1%

These studies only examined data taken from a single

measurement point, so they were not able to compare the MSS
announcements across networks with different user profiles,
e.g. academic versus residential broadband users. Furthermore,
Allmans study is now over a decade old and therefore the
results may not be indicative of modern TCP behaviour,
given the growth and advancement of Internet applications and
technology since the study was published.
Arlitt et al [15] briefly discussed the MSS values from a
set of traces collected near several web servers in 2004. They
noted that virtually all the MSS values were at or close to
1460 bytes, as per conventional wisdom, with the remainder
close to 512 bytes. However, they do not mention whether the
MSS that was measured was the announced or observed value.
VI. C ONCLUSION
In this paper, we have presented the results of an in-depth
study of the MSS values that are announced and utilised
by contemporary TCP hosts. The aim of the study was to
determine whether the current assumptions about the MSS
are still applicable, given the widespread adoption of new
protocols and technologies that can reduce the path MTU
and, therefore, the MSS. We also investigated the relationship
between the MSS value announced by a TCP receiver and the
MSS that was actually utilised by the sender.
Our results suggested the general perception that 1460 bytes
is the most common announced MSS value is still true, but
1460 byte MSS announcements account for less than half
of all announcements that we observed. There also appeared
to be a trend towards announcing slightly smaller values to
compensate for the additional overhead of tunnelling protocols
such as PPP. Overall, there was a much greater variation in
MSS advertisements than had been previously reported in
literature, including impractical values at both ends of the size
scale.
By contrast, there was little evidence indicating that the
default MSS of 536 bytes is commonly advertised by TCP
senders. However, we did find that 536 byte MSS announcements are still being received by some TCP endpoints, probably due to the original announcements being overwritten
by middleboxes. We discovered that this behaviour primarily
affected SMTP transactions and involved a variety of remote
hosts.
We also demonstrated that an MSS value announced in a
captured SYN packet is not a reliable indicator of the MSS
that will be used for a TCP half-connection. Firstly, the MSS
announced may be modified by a device further down the path

Waikato
53.0%
37.4%
0.2%
9.4%
0.1%

ISP C-I
69.7%
13.4%
0.1%
16.8%
< 0.1%

ISP C-II
69.0%
13.3%
0.1%
17.7%
< 0.1%

from the passive monitor, thus the MSS value observed in the
packet trace may not match the value seen by the destination
endpoint. We found that it is not uncommon for TCP senders
utilise a maximum segment size smaller than that announced
to them. This may be because the announced MSS exceeds
the senders MTU or because the application has limited the
size of network writes. As a result, passive analysis techniques
that depend on an accurate MSS cannot just naively rely on
the announced MSS value.
Finally, we found that less than 0.3% of all TCP halfconnections sent segments larger than those specified by the
corresponding MSS announcement. While the overall proportion was small, it is still disconcerting that we were able to
observe senders that violated the MSS in each of the trace sets
that we examined. One possible avenue of future work would
be to investigate senders that violate the MSS in greater depth
to determine why and how this occurs.
R EFERENCES
[1] W. John and S. Tafvelin, Analysis of Internet Backbone Traffic and
Header Anomalies Observed, in IMC 07: Proceedings of the 7th ACM
SIGCOMM conference on Internet measurement, 2007, pp. 111116.
[2] S. Alcock, D. Lawson, and R. Nelson, Extracting Application Objects
from TCP Packet Traces, in Proceedings of Australasian Telecommunication Networks and Applications Conference (ATNAC 2007), 2007.
[3] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D. Towsley, Inferring
TCP Connection Characteristics through Passive Measurements, in
Proceedings of IEEE Infocom, 2004, pp. 15821592.
[4] S. Floyd, T. Henderson, and A. Gurtov, RFC 3782 - The NewReno
Modification to TCPs Fast Recovery Algorithm, 2004.
[5] R. Braden, RFC 1122 - Requirements for Internet Hosts - Communication Layers, 1989.
[6] J. Postel, RFC 879 - TCP Maximum Segment Size and Related Topics,
1983.
[7] WITS: Waikato Internet Trace Storage, http://www.wand.net.nz/wits/.
[8] WITS: Local ISP B-III, http://www.wand.net.nz/wits/localisp/b/3/.
[9] WITS: Local ISP C-I, http://www.wand.net.nz/wits/localisp/c/1/.
[10] WITS: Local ISP C-II, http://www.wand.net.nz/wits/localisp/c/2/.
[11] WITS: Waikato VI, http://www.wand.net.nz/wits/waikato/6/.
[12] WITS: Auckland X, http://www.wand.net.nz/wits/auckland/10/.
[13] Microsoft Help and Support, The Default MTU sizes for Different
Network Topologies, http://support.microsoft.com/kb/314496/.
[14] M. Allman, A Web Servers View of the Transport Layer, SIGCOMM
Computer Communication Review, vol. 30, no. 5, 2000.
[15] M. Arlitt, B. Krishnamurthy, and J. C. Mogul, Predicting Short-Transfer
Latency from TCP arcana: A Trace-based Validation, in In Proceedings
of Internet Measurement Conference, 2005, pp. 119124.