An Analysis of TCP Maximum Segment SizesShane Alcock and Richard Nelson

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

AbstractThe Maximum Segment Size (MSS) is a basic yetcritical property of any TCP connection. Yet surprisingly, therehave been no recent studies examining the MSS values thatare announced and utilised by TCP senders in any detail. Thispaper analyses packet traces from several different locations andinvestigates the advertised and observed MSS values for eachcaptured TCP connection. In particular, this study focuses on therange of MSS values that are announced by TCP endpoints andthe relationship between the advertised MSS value and the MSSused by TCP senders. We find that although 1460 bytes remainsthe most commonly announced MSS, it accounts for less than halfof all MSS advertisements. Instead, slightly smaller MSS valuesare increasing in popularity due to the rise in PPPoE and VPNtechnologies. We also find that many TCP sessions do not utiliseeither of the announced MSS values, possibly due to applicationbehaviour, and that a small but not insignificant number of TCPsenders transmit segments larger than permitted by the MSSannounced to them.

I. INTRODUCTIONThe Maximum Segment Size (MSS) is a fundamental at-

tribute of a TCP connection that defines how large blocksof data are divided into segments for transmission over anetwork. Despite this, there have been no recent studies thathave examined the MSS values that are announced and usedby TCP senders in any detail. Rather, there are several well-known common MSS values that are often assumed to beprevalent on the Internet; in particular, 1460 byte MSS valuesare typically utilised by TCP traffic models. However, thisis done without any reference to recent measurements thatconfirm these values as being representative of contemporaryInternet traffic.

In this paper, we present the results of using passive networkpacket traces to investigate the MSS values that are announcedand utilised by TCP senders. Traces from several differentdata sets were analysed, including captures of residential DSLtraffic, to ensure that the results encompass a broad sampleof users, devices and applications. We have examined thedistribution of MSS values that were announced in each traceset and have identified occasions where the announced MSSdid not correspond to the MSS that the sender was using.

The primary contribution of this work is that it is a dedicatedand in-depth study of the MSS as utilised by modern TCPhosts. Given the rate and nature of evolution of the Internet,it is important to periodically re-evaluate the conventionalwisdom regarding properties like the MSS to ensure thatexisting models of TCP accurately reflect the traffic that isobserved in reality. For instance, the increased prevalence ofprotocols and technologies which reduce the effective MTUfor links, such as the Point-to-Point Protocol over Ethernet

(PPPoE) and Virtual LANs, will also result in a reduction inthe MSS that can be supported by a TCP endpoint. However,until now there have been no published studies that haveinvestigated the impact of these technologies. Recent studiesthat have examined the MSS, such as [1], have done so in acursory fashion as part of a much wider study of basic TCP/IPtraffic properties within a single data set and therefore havenot studied the topic in any depth.

In addition, we have identified and documented some prob-lems that arise when attempting to determine the MSS usedby a TCP sender from a passive packet trace. These problemsinclude TCP senders that violate the TCP standard by trans-mitting segments that exceed the MSS that was announcedto them and the effect of middleboxes that modify the MSSannouncement after it has been observed by the passive mon-itor. These have significant implications for passive analysisapproaches 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 inferobject boundaries. Another example is passive congestionwindow estimation, such as in [3], where the behaviour of theNewReno congestion control algorithm [4] differs dependingon whether the amount of data acknowledged is greater orsmaller than the MSS. In both cases, the MSS must be inferredpassively from packet traces but if the inferred MSS differsfrom that which was actually used by the TCP sender, theresulting analysis may produce results that do not reflect realTCP behaviour.

II. BACKGROUNDThe TCP Maximum Segment Size is defined as the largest

TCP segment that can be accepted by a receiver for a TCPconnection. This value is measured in data octets following theIP and TCP headers; these headers are not counted towards thesegment size (however, IP and TCP options present in theseheaders are included in the segment size [5]). Each endpointparticipating in a TCP connection can announce an MSS on anoutgoing SYN packet during connection establishment usingthe TCP MSS Option [6]. There are two independent MSSvalues announced for any given TCP connection; one foreach direction. By definition, a transmitting host must notsend a TCP segment that exceeds the MSS announced by thedestination host.

The MSS that will be announced by a host is typicallydetermined by subtracting a fixed value from the MaximumTransmission Unit (MTU) for that host. For IPv4, the sub-tracted value is usually 40 bytes, which is the combined size of

a TCP and IPv4 header without any trailing options, althoughother values are possible [6]. The IPv6 header is larger thanthe IPv4 header, so in that case 60 bytes will be subtractedfrom the MTU instead.

A host will always know the MTU of the interface beingused for the TCP connection, but it may not know about linksfurther along the path from the remote endpoint to the host.Path MTU discovery can be used to determine the MTU forthe entire path, but this technique is not always successful.Without accurate path MTU information, it is possible fora host to announce an MSS that will not be valid for theentire path that the TCP connection will operate over. Thisis exacerbated by the growing prevalence of protocols thatoperate between the link and IP layers, such as Point-to-PointProtocol over Ethernet (PPPoE) and 802.1Q (more commonlyknown as Virtual LANs), and tunnelling protocols (includingthe Layer 2 Tunnelling Protocol (L2TP) and Virtual PrivateNetworks (VPNs)). These protocols and technologies reducethe effective MTU for the path.

As a result, it is common practice to adjust the announcedMSS to decrease the probability of a lower path MTU invali-dating the MSS and causing TCP segments to be fragmented.In some cases, this is done manually by a user editing theconfiguration of the operating system on the TCP endpoint andchanging the interface MTU to a value that they deem sensible.Network administrators can similarly adjust the configurationof network devices to use a lower MTU value to minimise thelikelihood of segment sizes exceeding the path MTU.

Another solution is MSS clamping, where a device inthe path automatically adjusts the announced MSS value inoutgoing TCP SYN packets to a lower value. This may bebased on knowledge of a neighbouring link, such as a DSLrouter placing an upper bound on MSS advertisements over aPPPoE link to account for the eight bytes required for a PPPoEheader. This is also commonly observed with network devicesthat provide VPN support, where the MSS is limited to ensurethat the tunnelling overhead will not exceed the MTU of thepath that the VPN is operating over.

Therefore, there is reason to suspect that the current assump-tion that most TCP senders announce a 1460 byte MSS nolonger applies. Rather, it is likely that the range of announcedMSS values is much larger than previously thought. Theincreased frequency of hard-coded MSS adjustments may alsolead to misconfigurations where the MSS is set to an incorrect,inefficient or simply nonsensical value. This is especially likelyif an end-user is involved, as they may not fully understandthe implications of their actions.

III. DATA SETSFor the purposes of this study we have analysed several sets

of packet traces that have been collected at different locationsaround New Zealand by the WAND Group at the Universityof Waikato. The basic properties of the traces, including thenumber of TCP connections that we examined during thecourse of our study, are shown in Table I. Each of the tracesets and the methods used to capture them are documented in

TABLE ILIST OF ANALYSED DATA SETS.

Name Date Duration TCP FlowsISP B Feb 2007 5 days 508 millionWaikato Feb 2008 6.5 days 20 millionISP C-I Jan 2009 10 days 130 millionAuckland Oct 2009 9 days 230 millionISP C-II Jan 2010 9 days 197 million

detail on the WITS trace archive website [7], so the discussionof the traces will be limited to aspects that are relevant to ourMSS analysis. All of the trace sets were captured within thepast four years meaning that the results presented here are bothrelevant and timely. Each of the examined traces was capturedby monitoring a symmetric link, enabling us to analyse andcompare both halves of a given TCP connection.

Three of the trace sets, ISP B [8], ISP C-I [9] and ISPC-II [10], were captured from two different New ZealandISPs, enabling us to examine the MSS values being usedby residential broadband users as well as the wide varietyof servers and peers that these users typically connect to. Inmost cases, these users self-administer their home networksand may be more likely to misconfigure the announced MSSon a device. The variety of devices and operating systemsbeing used is also likely to be much wider compared to anacademic or corporate network.

The ISP B trace set was taken at a prominent New ZealandISP and was the largest of the data sets that we examined. Thetraces contain incoming and outgoing traffic for a subset of theresidential DSL customer base. The ISP C-I and C-II trace setswere captured from a smaller New Zealand ISP, but the datais more recent than the other ISP trace set and encompassesall of the customers, including corporate and wireless users.However, we used BPF filters based on known IP rangesto examine DSL subscribers only to ensure the results arecomparable with the ISP B data. The two ISP C data setswere taken exactly one year apart, so we can also examinetrends in MSS behaviour over time.

The remaining two trace sets were captured from academicnetworks as part of long-running and well-known trace sets.Academic networks and the end hosts within are usuallyadministered by professionals who should be much less likelyto adjust the MSS or MTU for a link unnecessarily. However,many academic networks often employ firewall appliances orsimilar hardware that reduce the path MTU and may thereforeaffect the MSS. Virtual Private Networks (VPNs) are also morelikely to be utilised, which will also affect the MSS.

We selected several days of data from the Waikato VI traceset [11] which was captured at the edge of the Universityof Waikato network. The IP addresses in the Waikato traceswere sanitised and the anonymisation key was changed onceper week. This meant that we were unable to analyse morethan a week of data at once, as our analysis technique requiredhost IP addresses to be consistent. The final trace set analysedwas a short trace set captured at the University of Auckland,

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 IPv6traffic in most of the trace sets that were available to us. Oneavenue for further research would be to repeat this study forIPv6 hosts.

IV. RESULTSA. Announced MSS Values

Figure 1 shows the distribution of announced MSS valuesfrom the ISP B, Waikato and ISP C-II data sets. Due to spaceconstraints, we have not included graphs for all of the tracesets here.

The announced MSS values were determined by extractingthe value of the MSS TCP option from the SYN packet sentby the TCP host. If no MSS option was present, the MSS wasassumed to be 536 bytes [6]. To avoid any bias towards hoststhat had participated in multiple connections, each unique MSSvalue was counted only once per announcing host. Also, MSSvalues that were advertised to a host that did not subsequentlytransmit any payload-bearing packets for that connection wereignored to eliminate probes, scans and exploit attempts fromthe analysis.

As expected, there was a heavy concentration of valuesaround 1460 bytes in all of the trace sets but the range ofannounced values was much wider than we had anticipated.For instance, there were 1029 unique values announced in theISP B trace, ranging from a single byte (which was advertisedby 3 unique hosts) through to 65535 bytes (announced by8 unique hosts), the maximum allowable value given thatthe MSS option is limited to 16 bits. It is hard to imaginecircumstances whether the values at either end of the rangeare practical. It would be very inefficient to conduct a TCPexchange where each segment can be no larger than one byteand no link technology currently exists that could support 64kilobyte segments.

However, the overall proportion of announced MSS valuesthat were outside of a conventional range was very small, asshown in Table II. Across all the examined data sets, less than0.4% of announced MSS values were not between 536 and1460 bytes inclusive. We define this as a conventional rangegiven that 536 bytes is the default MSS value [6] and 1460bytes is the largest MSS value possible for standard Ethernet.

The most popular announced MSS values for each data setare shown in Table III. 1460 is the most frequently announcedvalue by a significant margin but still accounted for less thanhalf of all MSS announcements in each trace set. 1452 and1440 were also prominent values and are primarily due toDSL subscribers that are using PPPoE to connect to theirISP. PPPoE reduces the Ethernet MTU by 8 bytes resultingin a 1452 byte MSS whereas Windows operating systems willoften use an MTU of 1480 for PPP over Ethernet interfaces[13]. Subtracting 40 bytes then produces the 1440 byte MSSseen in the table. Comparing the ISP C data sets suggests thatthe popularity of 1460 byte MSS announcements decreased in2010 in favour of MSS values that are compatible with PPPoE.

1

10

100

1000

10000

100000

1e+06

1e+07

1 10 100 1000 10000 100000

Freq

uenc

y

Announced MSS (bytes)(a) ISP B

1

10

100

1000

10000

100000

1e+06

10 100 1000 10000 100000

Freq

uenc

y

Announced MSS (bytes)(b) Waikato

1

10

100

1000

10000

100000

1e+06

1e+07

1 10 100 1000 10000 100000

Freq

uenc

y

Announced MSS (bytes)(c) ISP C-II

Fig. 1. Distribution of announced MSS values in the datasets.

536 byte MSS announcements barely featured in any ofthe ISP trace sets, accounting for less than 0.25% of MSSannouncements in each case. Only in the Waikato trace set didan announced MSS of 536 bytes feature prominently, where21.1% of all TCP half-connections either explicitly announceda 536 byte MSS or did not include an MSS option on theinitial SYN. Further investigation revealed that only 1.4% of

TABLE IIRANGES OF ANNOUNCED MSS VALUES

MSS Range ISP B Auckland Waikato ISP C-I ISP C-II1 - 535 0.063% 0.017% 0.271% 0.195% 0.057%536 - 999 0.269% 0.275% 21.103% 0.274% 0.213%1000 - 1299 1.215% 1.272% 0.779% 1.544% 0.809%1300 - 1439 17.980% 21.075% 15.834% 16.792% 20.65%1440 - 1460 80.423% 77.327% 61.977% 81.195% 78.27%1461 - 8960 0.046% 0.030% 0.031% 0.001% 0.001%8961 - 66535 0.003% 0.004% 0.005% 0.000% 0.001%

TABLE IIIMOST FREQUENTLY ANNOUNCED MSS VALUES

Rank ISP B Auckland Waikato ISP C-I ISP C-II1 1460 (44.8%) 1460 (39.5%) 1460 (30.6%) 1460 (46.4%) 1460 (40.5%)2 1452 (19.3%) 1452 (19.1%) 536 (21.1%) 1440 (17.6%) 1440 (22.7%)3 1440 (15.6%) 1440 (15.7%) 1452 (17.5%) 1452 (15.2%) 1452 (13.5%)4 1360 (3.40%) 1360 (5.33%) 1440 (12.5%) 1360 (4.12%) 1360 (5.70%)5 1414 (2.83%) 1380 (2.92%) 1360 (3.28%) 1380 (1.95%) 1420 (2.87%)6 1412 (2.03%) 1400 (2.47%) 1380 (2.31%) 1414 (1.79%) 1380 (2.41%)7 1420 (1.95%) 1420 (2.44%) 1420 (1.92%) 1420 (1.50%) 1414 (2.20%)8 1380 (1.28%) 1442 (2.09%) 1412 (1.81%) 1412 (1.45%) 1400 (1.56%)9 1260 (1.07%) 1412 (1.41%) 1414 (1.33%) 1400 (1.12%) 1412 (1.03%)10 1432 (1.05%) 1414 (1.38%) 1400 (0.95%) 1456 (0.97%) 1408 (0.77%)

all 536 byte announcements in the Waikato data came froma host within the university network. Given that the Waikatopassive monitor was located on the edge of the network, anyclamping of the MSS to 536 bytes must have occurred priorto the packet reaching the university.

The announcements were coming from a variety of net-works, so they cannot be attributed to a single source witha small path MTU, such as another university. Also, 79%of the 536 byte MSS announcements were explicit, ratherthan due to the absence of an MSS option, so the cause wasunlikely to be a device that discards TCP options. Of the half-connections in the Waikato data that explicitly announced a536 byte MSS, 97% involved TCP port 25 (SMTP). However,these half-connections only accounted for 15% of all TCPport 25 sessions observed in the entire trace set. This suggeststhat this behaviour is related to email (albeit only some ofthe observed mail), but it is not clear what benefit is gainedthrough clamping the MSS to 536 bytes.

B. Observed MSS ValuesFigures 2 and 3 are scatter plots showing the announced

MSS value for a TCP half-connection against the largestsegment transmitted by the sender (including TCP and IPoptions) for that half-connection. To remove results wherethe application never had a full-sized segment to send, onlyhalf-connections where the observed MSS was achieved bymultiple segments are shown. Also, the X-axis has beenlimited to a maximum of 1500 bytes to ensure that thepatterns in the data can be seen clearly. Because the traceswere captured from an Ethernet link, there were no observedsegments that exceeded 1500 bytes in size.

0

200

400

600

800

1000

1200

1400

1600

0 200 400 600 800 1000 1200 1400

Obs

erve

d M

SS (b

ytes)

Announced MSS (bytes)

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

There is a clear diagonal line in both graphs where theobserved MSS matches the announced value, representing theexpected scenario where the advertised MSS is utilised by thesender. There is also vertical banding occurring at many ofthe commonly announced values, such as those appearing inTable III. This is primarily due to the increased sample sizeat those values, although it does also suggest that there is adegree of independence between the announced and observedMSS values.

There were also a number of occasions where the observedMSS exceeded the value that had been announced, i.e. a pointappears above the diagonal line, which is a violation of thestandard defined in [6]. The violations were not restrictedto instances where the announced MSS might be regarded

0

200

400

600

800

1000

1200

1400

1600

0 200 400 600 800 1000 1200 1400

Obs

erve

d M

SS (b

ytes)

Announced MSS (bytes)

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

as impractical, e.g. below 536 bytes, where sending largersegments might be expected. There also appears to be somehorizontal banding at 1414 and 1360 bytes, both of which wereshown to be commonly announced values. This may be dueto the sender adopting the MSS value from an announcementother than the one provided by the receiving host.

Table IV categorises and quantifies the disparities betweenthe announced and observed MSS values as shown in theprevious graphs. Again, only half-connections where the ob-served MSS was achieved by more than one packet weretaken into account. The first column describes which (if any)of the announced MSS values for the connection matchedthe observed MSS, where the expected scenario is that theobserved MSS would match the MSS advertised by the re-ceiver. In the event of the sender and receiver announcementsbeing equal, the half-connection was deemed to have matchedthe receiver MSS. The second column distinguishes betweenobserved MSS values that were less than or equal to the MSSannounced by the receiver, which we term valid, and those thatexceed the advertised value. The case where the observed MSSmatched the size advertised by the receiver is, by definition,always valid.

Overall, the frequency of invalid behaviour is low acrossall of the trace sets that we examined: less than 0.3% of thehalf-connections utilise an MSS greater than the one that wasannounced by the receiver. The majority of these cases appearto occur when the sender replaces the receivers announcedMSS with their own larger value. This is probably causedby an error in the sender TCP implementation. For instance,the two advertised values may have been inverted, due to aprogramming error or a misinterpretation of the specifications.It is also possible that the sender did not treat both halves ofthe connection as distinct, i.e. only one MSS variable wasstored for each connection.

One interesting result is the prevalence of senders utilisingan MSS other that announced by either of the TCP endpointsinvolved in the connection, especially in the ISP datasets.We suspect that application behaviour may be a major con-

Host A Host B

Middlebox

Monitor

MSS=1460

MSS=1460MSS=536

MSS=536

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

tributing factor to this result, whereby the application writesconsistently-sized objects to the network that are smaller thanthe MSS. This object size is regarded as the observed MSSby our analysis, when the TCP sender never received enoughdata at any one time to send a genuine MSS-sized segment.

We also observed instances where the sender adopted theMSS that they announced rather than the one announced tothem. This occurred in over a third of the Waikato half-connections. Although this does not strictly conform to thedirectional independence implied in [6], this approach islegitimate whenever the senders MTU limits the outboundsegment size below that announced by the receiver. In thiscase, it makes sense for the sender to override the announcedvalue to avoid fragmentation.

However, there is another possibility, which we demonstratein Figure 4. It shows the MSS being clamped by a middlebox,but the clamping is only observed in one direction due to thelocation of the passive monitor. As a result, it appears thatHost A has adopted the smaller MSS that it had advertised toHost B rather than the 1460 byte MSS that Host B announcedto it. In reality, both endpoints had received a 536 byteannouncement due to the MSS clamping performed by themiddlebox. This is the likely reason for the high rate of senderMSS adoption observed in the Waikato trace, especially giventhe frequency of 536 bytes announcements observed fromoutside the university.

V. RELATED WORK

John and Tafvelin [1] conducted a study of TCP/IP headeranomalies using traces captured from a single Internet back-bone link in April 2006. A similar study was published byAllman [14] using packet traces taken from a single web serverbetween 1998 and 2000. In both cases, the announced MSSvalues were examined as part of a much broader investigation.Both studies noted that there were some unexpected valuesbeing announced using the MSS option, but did not pursuethese in any depth. Allman also compared the announcedMSS with the largest segment observed but did not reportany occasions where the announced MSS was exceeded by aTCP sender.

TABLE IVRELATIONSHIP BETWEEN THE OBSERVED MSS AND THE ADVERTISED VALUES FOR THE CONNECTION.

MSS Matched Valid ISP B Auckland Waikato ISP C-I ISP C-IIReceiver Yes 68.5% 77.8% 53.0% 69.7% 69.0%Sender Yes 13.3% 11.4% 37.4% 13.4% 13.3%Sender No 0.2% < 0.1% 0.2% 0.1% 0.1%Neither Yes 17.9% 10.8% 9.4% 16.8% 17.7%Neither No