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

Abstract—The Maximum Segment Size (MSS) is a basic yet (PPPoE) and Virtual LANs, will also result in a reduction in critical property of any TCP connection. Yet surprisingly, there the MSS that can be supported by a TCP endpoint. However, have been no recent studies examining the MSS values that until now there have been no published studies that have are announced and utilised by TCP senders in any detail. This paper analyses packet traces from several different locations and investigated the impact of these technologies. Recent studies investigates the advertised and observed MSS values for each that have examined the MSS, such as [1], have done so in a captured TCP connection. In particular, this study focuses on the cursory fashion as part of a much wider study of basic TCP/IP range of MSS values that are announced by TCP endpoints and traffic properties within a single data set and therefore have the relationship between the advertised MSS value and the MSS not studied the topic in any depth. used by TCP senders. We find that although 1460 bytes remains the most commonly announced MSS, it accounts for less than half In addition, we have identified and documented some prob- of all MSS advertisements. Instead, slightly smaller MSS values lems that arise when attempting to determine the MSS used are increasing in popularity due to the rise in PPPoE and VPN by a TCP sender from a passive packet trace. These problems technologies. We also find that many TCP sessions do not utilise include TCP senders that violate the TCP standard by trans- either of the announced MSS values, possibly due to application mitting segments that exceed the MSS that was announced behaviour, and that a small but not insignificant number of TCP senders transmit segments larger than permitted by the MSS to them and the effect of middleboxes that modify the MSS announced to them. announcement after it has been observed by the passive mon- itor. These have significant implications for passive analysis I. INTRODUCTION approaches that depend on an accurate estimate of the MSS. The Maximum Segment Size (MSS) is a fundamental at- For example, the TCP object extraction method described in tribute of a TCP connection that defines how large blocks [2] uses segments that are smaller than the MSS to infer of data are divided into segments for transmission over a object boundaries. Another example is passive congestion network. Despite this, there have been no recent studies that window estimation, such as in [3], where the behaviour of the have examined the MSS values that are announced and used NewReno congestion control algorithm [4] differs depending by TCP senders in any detail. Rather, there are several well- on whether the amount of data acknowledged is greater or known “common” MSS values that are often assumed to be smaller than the MSS. In both cases, the MSS must be inferred prevalent on the Internet; in particular, 1460 byte MSS values passively from packet traces but if the inferred MSS differs are typically utilised by TCP traffic models. However, this from that which was actually used by the TCP sender, the is done without any reference to recent measurements that resulting analysis may produce results that do not reflect real confirm these values as being representative of contemporary TCP behaviour. Internet traffic. In this paper, we present the results of using passive network II. BACKGROUND packet traces to investigate the MSS values that are announced The TCP Maximum Segment Size is defined as the largest and utilised by TCP senders. Traces from several different TCP segment that can be accepted by a receiver for a TCP data sets were analysed, including captures of residential DSL connection. This value is measured in data octets following the traffic, to ensure that the results encompass a broad sample IP and TCP headers; these headers are not counted towards the of users, devices and applications. We have examined the segment size (however, IP and TCP options present in these distribution of MSS values that were announced in each trace headers are included in the segment size [5]). Each endpoint set and have identified occasions where the announced MSS participating in a TCP connection can announce an MSS on an did not correspond to the MSS that the sender was using. outgoing SYN packet during connection establishment using The primary contribution of this work is that it is a dedicated the TCP MSS Option [6]. There are two independent MSS and in-depth study of the MSS as utilised by modern TCP values announced for any given TCP connection; one for hosts. Given the rate and nature of evolution of the Internet, each direction. By definition, a transmitting host must not it is important to periodically re-evaluate the conventional send a TCP segment that exceeds the MSS announced by the wisdom regarding properties like the MSS to ensure that destination host. existing models of TCP accurately reflect the traffic that is The MSS that will be announced by a host is typically observed in reality. For instance, the increased prevalence of determined by subtracting a fixed value from the Maximum protocols and technologies which reduce the effective MTU Transmission Unit (MTU) for that host. For IPv4, the sub- for links, such as the Point-to-Point Protocol over Ethernet tracted value is usually 40 bytes, which is the combined size of TABLE I a TCP and IPv4 header without any trailing options, although LIST OF ANALYSED DATA SETS. other values are possible [6]. The IPv6 header is larger than the IPv4 header, so in that case 60 bytes will be subtracted Name Date Duration TCP Flows from the MTU instead. ISP B Feb 2007 5 days 508 million A host will always know the MTU of the interface being Waikato Feb 2008 6.5 days 20 million used for the TCP connection, but it may not know about links ISP C-I Jan 2009 10 days 130 million Auckland Oct 2009 9 days 230 million further along the path from the remote endpoint to the host. ISP C-II Jan 2010 9 days 197 million 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 detail on the WITS trace archive website [7], so the discussion entire path that the TCP connection will operate over. This of the traces will be limited to aspects that are relevant to our is exacerbated by the growing prevalence of protocols that MSS analysis. All of the trace sets were captured within the operate between the link and IP layers, such as Point-to-Point past four years meaning that the results presented here are both Protocol over Ethernet (PPPoE) and 802.1Q (more commonly relevant and timely. Each of the examined traces was captured known as Virtual LANs), and tunnelling protocols (including by monitoring a symmetric link, enabling us to analyse and the Layer 2 Tunnelling Protocol (L2TP) and Virtual Private compare both halves of a given TCP connection. Networks (VPNs)). These protocols and technologies reduce Three of the trace sets, ISP B [8], ISP C-I [9] and ISP the effective MTU for the path. C-II [10], were captured from two different New Zealand As a result, it is common practice to adjust the announced ISPs, enabling us to examine the MSS values being used MSS to decrease the probability of a lower path MTU invali- by residential broadband users as well as the wide variety dating the MSS and causing TCP segments to be fragmented. of servers and peers that these users typically connect to. In In some cases, this is done manually by a user editing the most cases, these users self-administer their home networks configuration of the operating system on the TCP endpoint and and may be more likely to misconfigure the announced MSS changing the interface MTU to a value that they deem sensible. on a device. The variety of devices and operating systems Network administrators can similarly adjust the configuration being used is also likely to be much wider compared to an of network devices to use a lower MTU value to minimise the academic or corporate network. likelihood of segment sizes exceeding the path MTU. The ISP B trace set was taken at a prominent New Zealand Another solution is MSS clamping, where a device in ISP and was the largest of the data sets that we examined. The the path automatically adjusts the announced MSS value in traces contain incoming and outgoing traffic for a subset of the outgoing TCP SYN packets to a lower value. This may be residential DSL customer base. The ISP C-I and C-II trace sets based on knowledge of a neighbouring link, such as a DSL were captured from a smaller New Zealand ISP, but the data router placing an upper bound on MSS advertisements over a is more recent than the other ISP trace set and encompasses PPPoE link to account for the eight bytes required for a PPPoE all of the customers, including corporate and wireless users. header. This is also commonly observed with network devices However, we used BPF filters based on known IP ranges that provide VPN support, where the MSS is limited to ensure to examine DSL subscribers only to ensure the results are that the tunnelling overhead will not exceed the MTU of the comparable with the ISP B data. The two ISP C data sets path that the VPN is operating over. were taken exactly one year apart, so we can also examine Therefore, there is reason to suspect that the current assump- trends in MSS behaviour over time. tion that most TCP senders announce a 1460 byte MSS no The remaining two trace sets were captured from academic longer applies. Rather, it is likely that the range of announced networks as part of long-running and well-known trace sets. MSS values is much larger than previously thought. The Academic networks and the end hosts within are usually increased frequency of hard-coded MSS adjustments may also administered by professionals who should be much less likely lead to misconfigurations where the MSS is set to an incorrect, to adjust the MSS or MTU for a link unnecessarily. However, inefficient or simply nonsensical value. This is especially likely many academic networks often employ firewall appliances or if an end-user is involved, as they may not fully understand similar hardware that reduce the path MTU and may therefore the implications of their actions. affect the MSS. Virtual Private Networks (VPNs) are also more likely to be utilised, which will also affect the MSS. III. DATA SETS We selected several days of data from the Waikato VI trace For the purposes of this study we have analysed several sets set [11] which was captured at the edge of the University of packet traces that have been collected at different locations of Waikato network. The IP addresses in the Waikato traces around New Zealand by the WAND Group at the University were sanitised and the anonymisation key was changed once of Waikato. The basic properties of the traces, including the per week. This meant that we were unable to analyse more number of TCP connections that we examined during the than a week of data at once, as our analysis technique required course of our study, are shown in Table I. Each of the trace host IP addresses to be consistent. The final trace set analysed sets and the methods used to capture them are documented in was a short trace set captured at the University of Auckland, called Auckland X [12], which was captured in October 2009. 1e+07 It should be noted that only IPv4 traffic was examined in 1e+06 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 100000 avenue for further research would be to repeat this study for IPv6 hosts. 10000

1000

IV. RESULTS Frequency

A. Announced MSS Values 100 Figure 1 shows the distribution of announced MSS values 10 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 1 sets here. 1 10 100 1000 10000 100000 Announced MSS (bytes) The announced MSS values were determined by extracting (a) ISP B 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 1e+06 assumed to be 536 bytes [6]. To avoid any bias towards hosts that had participated in multiple connections, each unique MSS 100000 value was counted only once per announcing host. Also, MSS values that were advertised to a host that did not subsequently 10000 transmit any payload-bearing packets for that connection were 1000 ignored to eliminate probes, scans and exploit attempts from the analysis. Frequency 100 As expected, there was a heavy concentration of values around 1460 bytes in all of the trace sets but the range of 10 announced values was much wider than we had anticipated. For instance, there were 1029 unique values announced in the 1 ISP B trace, ranging from a single byte (which was advertised 10 100 1000 10000 100000 by 3 unique hosts) through to 65535 bytes (announced by Announced MSS (bytes) 8 unique hosts), the maximum allowable value given that (b) Waikato the MSS option is limited to 16 bits. It is hard to imagine 1e+07 circumstances whether the values at either end of the range are practical. It would be very inefficient to conduct a TCP 1e+06 exchange where each segment can be no larger than one byte 100000 and no link technology currently exists that could support 64 kilobyte segments. 10000 However, the overall proportion of announced MSS values 1000 that were outside of a conventional range was very small, as Frequency shown in Table II. Across all the examined data sets, less than 100 0.4% of announced MSS values were not between 536 and 1460 bytes inclusive. We define this as a conventional range 10 given that 536 bytes is the default MSS value [6] and 1460 1 bytes is the largest MSS value possible for standard Ethernet. 1 10 100 1000 10000 100000 The most popular announced MSS values for each data set Announced MSS (bytes) are shown in Table III. 1460 is the most frequently announced (c) ISP C-II value by a significant margin but still accounted for less than Fig. 1. Distribution of announced MSS values in the datasets. 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 536 byte MSS announcements barely featured in any of in a 1452 byte MSS whereas Windows operating systems will the ISP trace sets, accounting for less than 0.25% of MSS often use an MTU of 1480 for PPP over Ethernet interfaces announcements in each case. Only in the Waikato trace set did [13]. Subtracting 40 bytes then produces the 1440 byte MSS an announced MSS of 536 bytes feature prominently, where seen in the table. Comparing the ISP C data sets suggests that 21.1% of all TCP half-connections either explicitly announced the popularity of 1460 byte MSS announcements decreased in a 536 byte MSS or did not include an MSS option on the 2010 in favour of MSS values that are compatible with PPPoE. initial SYN. Further investigation revealed that only 1.4% of TABLE II RANGES OF ANNOUNCED MSS VALUES

MSS Range ISP B Auckland Waikato ISP C-I ISP C-II 1 - 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 III MOST FREQUENTLY ANNOUNCED MSS VALUES

Rank ISP B Auckland Waikato ISP C-I ISP C-II 1 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 from 1600 a host within the university network. Given that the Waikato 1400 passive monitor was located on the edge of the network, any clamping of the MSS to 536 bytes must have occurred prior 1200 to the packet reaching the university. 1000 The announcements were coming from a variety of net- 800 works, so they cannot be attributed to a single source with a small path MTU, such as another university. Also, 79% 600

of the 536 byte MSS announcements were explicit, rather Observed MSS (bytes) 400 than due to the absence of an MSS option, so the cause was unlikely to be a device that discards TCP options. Of the half- 200 connections in the Waikato data that explicitly announced a 0 536 byte MSS, 97% involved TCP port 25 (SMTP). However, 0 200 400 600 800 1000 1200 1400 Announced MSS (bytes) these half-connections only accounted for 15% of all TCP port 25 sessions observed in the entire trace set. This suggests Fig. 2. Comparing the announced MSS against the observed MSS in the that this behaviour is related to email (albeit only some of ISP B traces. the observed mail), but it is not clear what benefit is gained through clamping the MSS to 536 bytes. There is a clear diagonal line in both graphs where the observed MSS matches the announced value, representing the B. Observed MSS Values expected scenario where the advertised MSS is utilised by the Figures 2 and 3 are scatter plots showing the announced sender. There is also vertical banding occurring at many of MSS value for a TCP half-connection against the largest the commonly announced values, such as those appearing in segment transmitted by the sender (including TCP and IP Table III. This is primarily due to the increased sample size options) for that half-connection. To remove results where at those values, although it does also suggest that there is a the application never had a full-sized segment to send, only degree of independence between the announced and observed half-connections where the observed MSS was achieved by MSS values. multiple segments are shown. Also, the X-axis has been There were also a number of occasions where the observed limited to a maximum of 1500 bytes to ensure that the MSS exceeded the value that had been announced, i.e. a point patterns in the data can be seen clearly. Because the traces appears above the diagonal line, which is a violation of the were captured from an Ethernet link, there were no observed standard defined in [6]. The violations were not restricted segments that exceeded 1500 bytes in size. to instances where the announced MSS might be regarded 1600 Middlebox

1400 MSS=1460 MSS=536 1200 Host A Host B

1000 MSS=536 MSS=1460

800

600 Monitor

Observed MSS (bytes) 400

200 Fig. 4. An illustration of how the location of the passive monitor can affect 0 an analysis of MSS announcements. If a device in the middle of the path is 0 200 400 600 800 1000 1200 1400 adjusting the announced MSS, the change is only seen in one direction at the Announced MSS (bytes) passive monitor.

Fig. 3. Comparing the announced MSS against the observed MSS in the ISP C-II traces. tributing factor to this result, whereby the application writes consistently-sized objects to the network that are smaller than as impractical, e.g. below 536 bytes, where sending larger the MSS. This object size is regarded as the “observed” MSS segments might be expected. There also appears to be some by our analysis, when the TCP sender never received enough horizontal banding at 1414 and 1360 bytes, both of which were data at any one time to send a genuine MSS-sized segment. shown to be commonly announced values. This may be due We also observed instances where the sender adopted the to the sender adopting the MSS value from an announcement MSS that they announced rather than the one announced to other than the one provided by the receiving host. them. This occurred in over a third of the Waikato half- connections. Although this does not strictly conform to the Table IV categorises and quantifies the disparities between directional independence implied in [6], this approach is the announced and observed MSS values as shown in the legitimate whenever the sender’s MTU limits the outbound previous graphs. Again, only half-connections where the ob- segment size below that announced by the receiver. In this served MSS was achieved by more than one packet were case, it makes sense for the sender to override the announced taken into account. The first column describes which (if any) value to avoid fragmentation. of the announced MSS values for the connection matched the observed MSS, where the expected scenario is that the However, there is another possibility, which we demonstrate observed MSS would match the MSS advertised by the re- in Figure 4. It shows the MSS being clamped by a middlebox, ceiver. In the event of the sender and receiver announcements but the clamping is only observed in one direction due to the being equal, the half-connection was deemed to have matched location of the passive monitor. As a result, it appears that the receiver MSS. The second column distinguishes between Host A has adopted the smaller MSS that it had advertised to observed MSS values that were less than or equal to the MSS Host B rather than the 1460 byte MSS that Host B announced announced by the receiver, which we term valid, and those that to it. In reality, both endpoints had received a 536 byte exceed the advertised value. The case where the observed MSS announcement due to the MSS clamping performed by the matched the size advertised by the receiver is, by definition, middlebox. This is the likely reason for the high rate of sender always valid. MSS adoption observed in the Waikato trace, especially given the frequency of 536 bytes announcements observed from Overall, the frequency of invalid behaviour is low across outside the university. 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 V. RELATED WORK announced by the receiver. The majority of these cases appear to occur when the sender replaces the receiver’s announced John and Tafvelin [1] conducted a study of TCP/IP header MSS with their own larger value. This is probably caused anomalies using traces captured from a single Internet back- by an error in the sender TCP implementation. For instance, bone link in April 2006. A similar study was published by the two advertised values may have been inverted, due to a Allman [14] using packet traces taken from a single web server programming error or a misinterpretation of the specifications. between 1998 and 2000. In both cases, the announced MSS It is also possible that the sender did not treat both halves of values were examined as part of a much broader investigation. the connection as distinct, i.e. only one MSS variable was Both studies noted that there were some unexpected values stored for each connection. being announced using the MSS option, but did not pursue One interesting result is the prevalence of senders utilising these in any depth. Allman also compared the announced an MSS other that announced by either of the TCP endpoints MSS with the largest segment observed but did not report involved in the connection, especially in the ISP datasets. any occasions where the announced MSS was exceeded by a We suspect that application behaviour may be a major con- TCP sender. TABLE IV RELATIONSHIP BETWEEN THE OBSERVED MSS AND THE ADVERTISED VALUES FOR THE CONNECTION.

MSS Matched Valid ISP B Auckland Waikato ISP C-I ISP C-II Receiver 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 <0.1% < 0.1% 0.1% < 0.1% < 0.1%

These studies only examined data taken from a single from the passive monitor, thus the MSS value observed in the measurement point, so they were not able to compare the MSS packet trace may not match the value seen by the destination announcements across networks with different user profiles, endpoint. We found that it is not uncommon for TCP senders e.g. academic versus residential broadband users. Furthermore, utilise a maximum segment size smaller than that announced Allman’s study is now over a decade old and therefore the to them. This may be because the announced MSS exceeds results may not be indicative of modern TCP behaviour, the sender’s MTU or because the application has limited the given the growth and advancement of Internet applications and size of network writes. As a result, passive analysis techniques technology since the study was published. that depend on an accurate MSS cannot just naively rely on Arlitt et al [15] briefly discussed the MSS values from a the announced MSS value. set of traces collected near several web servers in 2004. They Finally, we found that less than 0.3% of all TCP half- noted that virtually all the MSS values were at or close to connections sent segments larger than those specified by the 1460 bytes, as per conventional wisdom, with the remainder corresponding MSS announcement. While the overall propor- close to 512 bytes. However, they do not mention whether the tion was small, it is still disconcerting that we were able to MSS that was measured was the announced or observed value. observe senders that violated the MSS in each of the trace sets that we examined. One possible avenue of future work would VI. CONCLUSION be to investigate senders that violate the MSS in greater depth In this paper, we have presented the results of an in-depth to determine why and how this occurs. study of the MSS values that are announced and utilised by contemporary TCP hosts. The aim of the study was to REFERENCES determine whether the current assumptions about the MSS [1] W. John and S. Tafvelin, “Analysis of Internet Backbone Traffic and are still applicable, given the widespread adoption of new Header Anomalies Observed,” in IMC '07: Proceedings of the 7th ACM protocols and technologies that can reduce the path MTU SIGCOMM conference on Internet measurement, 2007, pp. 111–116. [2] S. Alcock, D. Lawson, and R. Nelson, “Extracting Application Objects and, therefore, the MSS. We also investigated the relationship from TCP Packet Traces,” in Proceedings of Australasian Telecommu- between the MSS value announced by a TCP receiver and the nication Networks and Applications Conference (ATNAC 2007), 2007. MSS that was actually utilised by the sender. [3] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D. Towsley, “Inferring TCP Connection Characteristics through Passive Measurements,” in Our results suggested the general perception that 1460 bytes Proceedings of IEEE Infocom, 2004, pp. 1582–1592. is the most common announced MSS value is still true, but [4] S. Floyd, T. Henderson, and A. Gurtov, “RFC 3782 - The NewReno 1460 byte MSS announcements account for less than half Modification to TCP’s Fast Recovery Algorithm,” 2004. [5] R. Braden, “RFC 1122 - Requirements for Internet Hosts - Communi- of all announcements that we observed. There also appeared cation Layers,” 1989. to be a trend towards announcing slightly smaller values to [6] J. Postel, “RFC 879 - TCP Maximum Segment Size and Related Topics,” compensate for the additional overhead of tunnelling protocols 1983. [7] “WITS: Waikato Internet Trace Storage,” http://www.wand.net.nz/wits/. such as PPP. Overall, there was a much greater variation in [8] “WITS: Local ISP B-III,” http://www.wand.net.nz/wits/localisp/b/3/. MSS advertisements than had been previously reported in [9] “WITS: Local ISP C-I,” http://www.wand.net.nz/wits/localisp/c/1/. literature, including impractical values at both ends of the size [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/. scale. [12] “WITS: Auckland X,” http://www.wand.net.nz/wits/auckland/10/. By contrast, there was little evidence indicating that the [13] Microsoft Help and Support, “The Default MTU sizes for Different default MSS of 536 bytes is commonly advertised by TCP Network Topologies,” http://support.microsoft.com/kb/314496/. [14] M. Allman, “A Web Server’s View of the Transport Layer,” SIGCOMM senders. However, we did find that 536 byte MSS announce- Computer Communication Review, vol. 30, no. 5, 2000. ments are still being received by some TCP endpoints, prob- [15] M. Arlitt, B. Krishnamurthy, and J. C. Mogul, “Predicting Short-Transfer ably due to the original announcements being overwritten Latency from TCP arcana: A Trace-based Validation,” in In Proceedings of Internet Measurement Conference, 2005, pp. 119–124. 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