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.