Internet DRAFT - draft-bonaventure-mptcp-long-options
draft-bonaventure-mptcp-long-options
MPTCP Working Group O. Bonaventure
Internet-Draft UCLouvain
Intended status: Informational July 06, 2015
Expires: January 7, 2016
Supporting long TCP options in Multipath TCP
draft-bonaventure-mptcp-long-options-00
Abstract
The extensibility of TCP is severely limited by the Data Offset field
of the TCP header that limits the number of bytes that can be used in
each segment to transport options. This document considers Multipath
TCP as the starting point and analyses different alternatives to
improve the ability of Multipath TCP to transport TCP extensions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bonaventure Expires January 7, 2016 [Page 1]
Internet-Draft MPTCP Long Options July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Lessons learned with Multipath TCP . . . . . . . . . . . . . 3
3. Extending the DSS option . . . . . . . . . . . . . . . . . . 4
3.1. First approach : TCP EOL as marker . . . . . . . . . . . 6
3.2. Second approach : Option length in DSS . . . . . . . . . 9
3.3. Third approach : using the control stream for options . . 10
3.4. Middlebox interference . . . . . . . . . . . . . . . . . 12
4. Negotiating the extended DSS option . . . . . . . . . . . . . 16
5. Compatibility with the existing TCP options . . . . . . . . . 16
5.1. End-of-Option List . . . . . . . . . . . . . . . . . . . 16
5.2. Maximum Segment Size . . . . . . . . . . . . . . . . . . 16
5.3. No-Operation . . . . . . . . . . . . . . . . . . . . . . 16
5.4. SACK-Permitted . . . . . . . . . . . . . . . . . . . . . 16
5.5. SACK option . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 17
5.7. TCP-TFO . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.8. TCP-AO option . . . . . . . . . . . . . . . . . . . . . . 17
5.9. TCP-User Timeout . . . . . . . . . . . . . . . . . . . . 17
5.10. Multipath TCP options . . . . . . . . . . . . . . . . . . 17
6. Security consideration . . . . . . . . . . . . . . . . . . . 18
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Multipath TCP is an extension to TCP [RFC0793] that was standardized
in [RFC6824]. Multipath TCP uses several types of TCP options to
exchange data. Like other TCP extensions, Multipath TCP suffers from
the 4 bits Data Offset field of the TCP header that limits the size
of the entire header, including options to 60 bytes. This limits the
total length of the TCP options to 40 bytes, which becomes a problem
for segments that include SACK [RFC2018], Timestamp [RFC1323],
Multipath TCP [RFC6824] and TCP-AO [RFC5925]. For example, it
becomes difficult to combine these four option types in a single
segment.
Various techniques to extend the TCP option space are being discussed
[I-D.ietf-tcpm-tcp-edo] within the TCPM working group. As of this
writing, there is not enough experience with such extensions and
their possible interference with middleboxes that are known to limit
the extensibility of TCP [IMC11].
Instead of starting from regular TCP as the other proposals, we
assume that Multipath TCP has been successfully negotiated for the
Bonaventure Expires January 7, 2016 [Page 2]
Internet-Draft MPTCP Long Options July 2015
TCP connection and evaluate how the unique features of Multipath TCP
can be tweaked to carry large TCP options including long SACK blocks.
Instead of changing the semantics of the Data Offset field, adding a
new TCP option or encoding the payload, we start from the DSS options
used by Multipath TCP. This gives us more flexibility and leverages
the middlebox resilience provided by Multipath TCP.
In this document, we focus on the transport of longer TCP options
once the Multipath TCP connection has been established. We leave for
further work the problem of extending the TCP option space in the SYN
segment during the three-way handshake.
This document is organized as follows. We first discuss the lessons
that were learned from the specification, implementation and
deployment of Multipath TCP in section Section 2. We then discuss in
Section 3 several solutions that modify the DSS option to support the
transmission of additional TCP options. We propose in Section 4 to
negotiate the utilisation of this option as a new Multipath TCP
version. Section 5 discusses how the existing TCP options can be
supported with the solution proposed in this document.
2. Lessons learned with Multipath TCP
During the design, implementation and deployment of Multipath TCP
during the last years we have learned some lessons on how various
types of middleboxes can interfere with a TCP extension. These
lessons have been documented in several scientific publications
[IMC11] [HotMiddlebox13], but it is worth summarising them again.
The first lesson concerns the initial three way handshake. Most TCP
extensions assume that the utilisation of a new option can be safely
negotiated by sending an option inside the initial SYN segment and
verifying that the same option is present in the returned SYN+ACK.
This is the approach used for SACK [RFC2018] and to some extent the
WSCALE and TS extensions defined in [RFC7323]. Unfortunately,
measurements with Multipath TCP showed that there are middleboxes
that simply echo in the SYN+ACK segment any unknown option received
in the SYN segment. To cope with such middleboxes, the TCP option
used to negotiate the utilisation of a TCP extension cannot be the
same in the SYN and SYN+ACK segments. The active opener must verify
that the option sent in the SYN segment has not been modified before
being returned in the SYN+ACK segment.
The second lesson is also about the initial three way handshake. A
middlebox can modify the SYN+ACK segment on the return path without
having observed the option contained in the SYN segment. This kind
of middlebox interference can be a problem for the negotiation of the
utilisation of a TCP extension since the states of the active and the
Bonaventure Expires January 7, 2016 [Page 3]
Internet-Draft MPTCP Long Options July 2015
passive opener might disagree. Multipath TCP solves this problem by
sending information in the third ACK.
The third lesson is that despite a successful negotiation during the
three way handshake by using option type x, middleboxes might still
remove option type x in some segments on the connection. Any TCP
extension must be able to cope with segments that do not contain an
expected option.
The fourth lesson is that middleboxes can split segments. Such
middleboxes can be located inside the network or be simply the TSO
implementation on the network interface card of the sending hosts
[IMC11]. These network interface cards are very popular and it is
difficult for a TCP stack to correctly detect their exact behaviour
concerning the handling of TCP options. These cards expose a large
MSS to the TCP stack and then split the large segment in smaller
segments that are (usually) checksummed by the card. According to
[IMC11] all the tested cards copy all the options included in the
large segment into the smaller ones.
The fifth lesson is that middleboxes can coalesce segments. Such
middleboxes can be located inside the network or more likely on the
receiving host. Most network interface cards implement GRO by
performing the opposite operation of TSO. If the segments that are
received in sequence always contain the same option, then these
segments are coalesced in a larger segment which is delivered to the
TCP stack. Note that the size of the segments that are delivered to
the TCP stack will vary in function of the packet losses and also of
the utilisation of options by the sending host.
The sixth lesson is that middleboxes can modify, inject or remove
data from the payload of TCP segments. A typical example are the
Application Level Gateways used on Network Address Translators to
"seamlessly" support application-level protocols that exchange IP
addresses in the bytestream. To support these applications, ALGs
need to modify the IP addresses (and possibly port numbers) exchanged
in the bytestream.
3. Extending the DSS option
The DSS option is defined in [RFC6824]. This option has a variable
length depending on the utilisation of the 'm', 'M', 'a' and 'A'
flags. The format of this option in shown in Figure 1. An important
point to note is that it contains several flags that are currently
reserved for future use.
Bonaventure Expires January 7, 2016 [Page 4]
Internet-Draft MPTCP Long Options July 2015
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| ( reser.) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Data sequence number (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Checksum (2 octets) |
+-------------------------------+------------------------------+
Figure 1: DSS option
We assume in this document that the utilisation of the modified DSS
option is negotiated as a new Multipath TCP version in the three way
handshake.
The general approach evaluated in this document is to place the
additional TCP options inside the payload and modify the DSS to
indicate which part of the payload contains TCP options (if any) and
which part contains payload data (if any). The generic solution is
shown graphically in Figure 2.
<- ext. ->
options
+--------+---------+--------+----------+--------...-----+
| ip hdr | TCP hdr | DSS | Options | User Data |
+--------+---------+--------+----------+--------...-----+
<- DO -> <- Payload of TCP segment-->
covered covered by DSS mapping
Figure 2: Usage of the modified DSS option
The key question for all the approaches discussed in this section is
how to modify the DSS option to indicate the boundary between the
additional TCP options and the payload. For simplicity, we assume in
this section that only the Multipath TCP DSS option is placed in the
extended TCP header. The other TCP are placed inside the payload
which is covered by the DSS option.
Bonaventure Expires January 7, 2016 [Page 5]
Internet-Draft MPTCP Long Options July 2015
3.1. First approach : TCP EOL as marker
A first approach to extend the TCP option space is to simply assume
that each DSS option is always followed by one or more TCP options
and that the EOL option, defined in [RFC0793] is used to mark the end
of the additional TCP options. For simplicity, we assume that the
DSS option is the only option that consumes space in the TCP header
extension (i.e. the Data Offset field of the TCP header has a value
equal to the length of the DSS option, possibly with a few NOP
options to align it on 32 bits boundaries). The length included in
the DSS option remains the length of the payload which is part of the
bytestream without taking into account the bytes consummed by the
included TCP options. This is illustrated in Figure 3. If the DSS
checksum has been negotiated, it is computed only on the user data
and the pseudo-header defined in [RFC6824].
+--------+---------+--------+--------+-----+------...-----+
| IP hdr | TCP hdr | DSS | Opt x | EOL | User data |
+--------+---------+--------+--------+-----+------...-----+
<- Payload of TCP segment-->
covered by DSS mapping
Figure 3: Using the TCP EOL option to mark the boundary between TCP
options and user data
In this figure, Option x and the payload are optional. With this
design there is always one byte used by the EOL option inside each
segment that contains a DSS option.
Let us now analyse how this solution react to middleboxes that
coalesce or split segments. Figure 4 illustrates a middlebox that
splits a large segment and copies the DSS option in both. The DSS
option shows the mapping between the DSN (2) and the subflow sequence
number (1) and the length covered by the DSS option.
Bonaventure Expires January 7, 2016 [Page 6]
Internet-Draft MPTCP Long Options July 2015
+---------+--------+-----+------...---+
| TCP hdr | DSS | EOL | Payload |
| seq=1 | 2->1 | | 4 bytes |
| len=5 | len=4 | | |
+---------+--------+-----+------...---+
||
\/
+---------+--------+-----+------...---+
| TCP hdr | DSS | EOL | Payload |
| seq=1 | 2->1 | | 2 bytes |
| len=3 | len=4 | | |
+---------+--------+-----+------...---+
+---------+--------+-------...---+
| TCP hdr | DSS | Payload |
| seq=3 | 2->1 | 2 bytes |
| len=2 | len=4 | |
+---------+--------+-------...---+
Figure 4: Effect of Segment splitting
If the segment is split as shown in the above example, a Multipath
TCP receiver will parse the DSS option in the first segment and wait
until it has received all the mapped data before extracting the EOL
option and the payload. Segment splitting does not affect this
solution.
If a middlebox coalesces segments, the situation is different. Let
us consider the scenario shown in Figure 5.
Bonaventure Expires January 7, 2016 [Page 7]
Internet-Draft MPTCP Long Options July 2015
+---------+--------+-----+------...---+
| TCP hdr | DSS | EOL | Payload |
| seq=1 | 2->1 | | 2 bytes |
| len=3 | len=2 | | |
+---------+--------+-----+------...---+
+---------+--------+-----+-------...--+
| TCP hdr | DSS | EOL | Payload |
| seq=3 | 4->3 | | 2 bytes |
| len=3 | len=2 | | |
+---------+--------+-----+------...---+
||
\/
+---------+--------+-----+------...---+-----+------...---+
| TCP hdr | DSS | EOL | Payload | EOL | Payload |
| seq=1 | 2->1 | | 2 bytes | | 2 bytes |
| len=5 | len=2 | | | | |
+---------+--------+-----+------...---+-----+------------+
or
+---------+--------+-----+------...---+-----+------...---+
| TCP hdr | DSS | EOL | Payload | EOL | Payload |
| seq=1 | 3->3 | | 2 bytes | | 2 bytes |
| len=5 | len=2 | | | | |
+---------+--------+-----+------...---+-----+------------+
Figure 5: Effect of Segment Coalescing
Since the two small segments do not contain the same option, a
middlebox should not in theory coalesce them. Anyway, let us analyse
what happens in this case. If the middlebox only copies the TCP
option in the first segment, then the receiver will process the first
EOL option and the first block of 2 bytes of payload. The remaining
bytes are not covered by a mapping. The receiver will ack at the
data level the first block of two bytes in the payload but not the
second. After some time, the sender will retransmit the
unacknowledged data with a new DSS option that will cover the data of
the second segment. The same applies if the middlebox copies the
second DSS option in the coalesced segment.
A first drawback of this solution is that the TCP stack must parse
the payload to extract all the options that are included inside a DSS
map. A possible alternative to simplify this parsing would be to
redefine an unused bit of the DSS option to indicate that the mapped
Bonaventure Expires January 7, 2016 [Page 8]
Internet-Draft MPTCP Long Options July 2015
payload starts with TCP options. If this bit is reset, then there
are no options in the payload and the receiver can process the
payload as usual. Parsing the payload might have a performance
impact on packet filters used on some routers or firewalls that
process TCP options.
A second drawback of this approach is that the TCP options consumme
TCP sequence space and are transmitted reliably. This implies that a
measurement application that uses the difference between the sequence
number of the SYN and FIN segments to compute the number of bytes
exchanged over a connection will overestimate the number of bytes
exchanged by the communicating applications.
3.2. Second approach : Option length in DSS
The second approach is to include an 'Options length' field inside
the DSS option to indicate the part of the payload that follows the
DSS option that is used by TCP options. This is illustrated with the
modified DSS option below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| ( reser.) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Data sequence number (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Checksum (2 octets) |
+-------------------------------+------------------------------+
| TCP Options Length |
+-------------------------------+
Figure 6: Extending the DSS option to include a TCP options length
This 'TCP Options length' field could be encoded in several ways :
o as a 16 bits field that encodes the number of bytes used for
options. This solution has the advantage of being aligned on 16
bits boundaries and supports options of up to 64 KBytes.
o as an 8 bits field that encodes the number of bytes used for
options. This solution supports options of up to 255 bytes. The
Bonaventure Expires January 7, 2016 [Page 9]
Internet-Draft MPTCP Long Options July 2015
DSS option is not aligned on 32 bits boundaries and TCP option
padding might be required in the TCP extended header.
o as an 8 bits field that encodes the number of 32 bits words used
for options. This solution supports options of up to 1020 bytes.
The DSS option is aligned on 16 bits boundaries and TCP option
padding is required inside the DSS option.
The last solution is probably the best compromise between overhead
and extensibility. It however adds some complexity in the padding
mechanism that needs to be used to encode the TCP options that appear
before the DSS option and the TCP options that are encoded within the
DSS option since both need to be aligned on 32 bits boundaries.
With the three solutions above, it is possible to send data mapped by
a DSS option without any TCP option by using a Length field (i.e. 20,
24 or 28 bytes) for the DSS option that does not include space for
the 'Options Length'.
3.3. Third approach : using the control stream for options
The control stream is an extension to Multipath TCP that was proposed
in [I-D.paasch-mptcp-control-stream]. This extension redefines one
flag (called 'S' in Figure 7) of the DSS option.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype|(reserved)|S|F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Control ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
|Control sequence number (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
|Control-Level Length (2 octets)| Checksum (2 octets) |
+-------------------------------+------------------------------+
Figure 7: Modification of the DSS option to indicate whether it maps
user data (S=0) or TCP options (S=1)
The control stream defines two separate bytestreams. The default
bytestream is used to carry application level data. These datas are
mapped by using the above DSS option with the 'S' flag set to 0.
When the 'S' flag of the DSS option is set to 1, this indicates that
the mapped data belongs to the second bytestream. In
Bonaventure Expires January 7, 2016 [Page 10]
Internet-Draft MPTCP Long Options July 2015
[I-D.paasch-mptcp-control-stream], this second bytestream was used to
exchange options using a special TLV format. One of the use cases
mentioned in [I-D.paasch-mptcp-control-stream] was the exchange of
security keys. However, this solution was neither implemented nor
deployed. We reuse it to map TCP options on the second bytestream.
Figure 8 shows some examples of segments containing only TCP options,
only user data or both user data and TCP options. In the first
example, the S bit is set to 1 and thus the mapped payload only
contains TCP options. In this segment, the DO field of the TCP
header covers only the DSS option. In the second example, the S bit
is set to zero and the payload contains user data. Again, the DO
field of the TCP header only covers the DSS option. The third
example combines both options and user data in a single segment. The
first part of the payload, containing 'Opt x', is covered by the DSS
with the S bit set to 1. This DSS maps TCP options. The second part
of the payload contains user data. In this last example, the DO
field of the TCP header covers the two DSS options.
TCP segment containing extended options
+--------+---------+--------------+--------+-------+
| IP hdr | TCP hdr | DSS (S=1) | Opt x | Opt y |
+--------+---------+--------------+--------+-------+
<-- Payload ---->
Covered by DSS
TCP segment containing data
+--------+---------+--------------+------...---+
| IP hdr | TCP hdr | DSS (S=0) | Payload |
+--------+---------+--------------+------...---+
<- Payload ->
Covered by DSS
TCP segment containing both extended options and data
covered by DSS (S=0)
<-- + --->
+--------+---------+-----------+-----------+-------+---...---+
| IP hdr | TCP hdr | DSS (S=1) | DSS (S=0) |Opt x | Payload |
+--------+---------+-----------+-----------+-------+---...---+
<- + ->
covered by DSS (S=1)
Figure 8: Examples of extended segments
Bonaventure Expires January 7, 2016 [Page 11]
Internet-Draft MPTCP Long Options July 2015
Note that to support both data and extended TCP options, two DSS
options must be placed inside the segment. This implies that each of
them must have a length of 20 bytes. In practice, we do not expect
that hosts will often need to send extended options and data
simultaneously. A better approach is to send data and extended
options in different segments.
Each TCP option that is included in the payload mapped by a DSS
option MUST be encoded by using the standard Type-Length-Value format
for TCP options [RFC0793]. The TCP options that are included in the
payload mapped by a DSS option MAY end with TCP option zero (End of
Option List). With this modified DSS option, the length of the
extended TCP options is only limited by the length than can be mapped
by a DSS option. Given that a DSS option can map up to 64 KBytes of
data, it is possible to send up to 64 KBytes worth of options.
3.4. Middlebox interference
We now qualitatively evaluate the last solution and analyze how
middleboxes could interfere with the transmission of extended TCP
options.
A first point to note is that although the example below assume for
simplicity that only the DSS option is part of the TCP header covered
by the Data Offset, this is not a requirement. A TCP segment can
include other TCP options inside the header covered by the Data
Offset field.
Our first use case is a middlebox that inserts a new TCP option and
modifies the TCP Data Offset. Figure 9 considers the impact of such
a middlebox on both a segment containing userdata and a segment
containing extended TCP options. Such a middlebox was proposed in
[I-D.ananth-middisc-tcpopt].
Bonaventure Expires January 7, 2016 [Page 12]
Internet-Draft MPTCP Long Options July 2015
Initial segment containing options
<--- DO covered ---> <-- DSS mapped-->
+---------+--------------+--------+-------+
| TCP hdr | DSS (S=1) | Opt x | Opt y |
+---------+--------------+--------+-------+
Modified segment containing options
<--- DO covered ---> <-- DSS mapped-->
+---------+----------+--------------+--------+-------+
| TCP hdr |Added Opt | DSS (S=1) | Opt x | Opt y |
+---------+----------+--------------+--------+-------+
Initial segment containing userdata
<--- DO covered ---> <-- DSS mapped-->
+---------+--------------+--------+-------+
| TCP hdr | DSS (S=0) | User data |
+---------+--------------+--------+-------+
Modified segment containing options
<--- DO covered ---> <-- DSS mapped-->
+---------+----------+--------------+--------+-------+
| TCP hdr |Added Opt | DSS (S=0) | User data |
+---------+----------+--------------+--------+-------+
Figure 9: Impact of the insertion of a TCP option
The proposed solution correctly copes with such a middlebox. It does
not work on a path where a middlebox removes the DSS option because
this option is required for the operation of Multipath TCP. In this
case, Multipath TCP performs a fallback to regular TCP.
Our second use case is a middlebox that splits a segment that
contains TCP options or user data and copies the DSS option in both
resulting segments. This is illustrated in Figure 10
Bonaventure Expires January 7, 2016 [Page 13]
Internet-Draft MPTCP Long Options July 2015
+---------+--------+--------+
| TCP hdr | DSS(S1)| Opt x |
| seq=1 | 2->1 | 4 bytes|
| len=5 | len=4 | |
+---------+--------+--------+
||
\/
+---------+--------+--------+
| TCP hdr | DSS(S1)| Opt |
| seq=1 | 2->1 | 2 bytes|
| len=3 | len=4 | |
+---------+--------+--------+
+---------+--------+--------+
| TCP hdr | DSS(S1)| Opt |
| seq=3 | 2->1 | 2 bytes|
| len=5 | len=4 | |
+---------+--------+--------+
Figure 10: Effect of segment splitting
With such a middlebox that splits a segment and copies the DSS
option, the receiver can recover the extended option once it has
received the two segments. The same applies for user data and is
already supported by Multipath TCP implementations [IMC13a].
The third use case is a middlebox that coalesces two segments. We
consider the case where a segment containing extended options is
coalesced with a segment containing user data. A similar reasoning
applies for other types of segment. This is illustrated in
Figure 11.
Bonaventure Expires January 7, 2016 [Page 14]
Internet-Draft MPTCP Long Options July 2015
+---------+--------+-------------+
| TCP hdr | DSS(S1)| Options |
| seq=1 | 2->1 | 4 bytes |
| len=4 | len=4 | |
+---------+--------+-------------+
+---------+--------+-------- --+
| TCP hdr | DSS(S0)| User data |
| seq=5 | 4->5 | 2 bytes |
| len=2 | len=2 | |
+---------+--------+-----------+
||
\/ Coalescing middlebox
+---------+--------+----------+------------+
| TCP hdr | DSS(S1)| Options | User data |
| seq=1 | 2->1 | 4 bytes | 2 bytes |
| len=6 | len=4 | | |
+---------+--------+----------+------------+
or
+---------+--------+----------+------------+
| TCP hdr | DSS(S0)| Options | User data |
| seq=1 | 4->5 | 4 bytes | 2 bytes |
| len=6 | len=2 | | |
+---------+--------+----------+------------+
Figure 11: Effect of Segment Coalescing
Multipath TCP implementations already support middleboxes that
coalesce consecutive segments containing data as demonstrated in
[IMC13a].
There are two different possibilities depending on whether the first
or the second DSS option is copied in the coalesced segment If the
first DSS option is copied, then the receiver has a valid mapping for
the extended TCP options and can decode them but no mapping for the
user data. The sender will timeout and retransmit a segment
containing the user data with a valid mapping. If the second DSS
option is copied, then the receiver can process the user data but has
to wait for a retransmission of the mapping that covers the extended
TCP options.
Bonaventure Expires January 7, 2016 [Page 15]
Internet-Draft MPTCP Long Options July 2015
4. Negotiating the extended DSS option
The proposed extended DSS option should only be used between hosts
that support the extension. This should be negotiated during the
three way handshake for the initial subflow. There are two possible
solutions for this negotiation :
o Redefine one of the unused bits (e.g. 'B') of the MP_CAPABLE
option [RFC6824] to negotiate the utilisation of the extended DSS
option
o Define a new version of the Multipath protocol [RFC6824]
Given the impact of the change, it is probable safer to increment the
protocol version number.
5. Compatibility with the existing TCP options
In this section, we discuss how the existing TCP options can be
transported by using the control stream.
5.1. End-of-Option List
If used, this option, defined in [RFC0793] MUST appear as the last
TCP option in each DSS-mapped payload that contains TCP options.
5.2. Maximum Segment Size
The MSS option, defined in [RFC0793] can only appear in SYN segments.
It MUST never be sent inside a DSS-mapped payload. If a host
receives a DSS-mapped payload that contains this option, it MUST
ignore the entire DSS-mapped payload.
5.3. No-Operation
This option, defined in [RFC0793] is often used to align TCP options
to word boundaries. Some middleboxes replace existing TCP options
with this option [IMC11]. A host that sends TCP options inside a
DSS-mapped payload MAY send one or more No-Operation options inside
the DSS-mapped payload.
5.4. SACK-Permitted
This option, defined in [RFC2018], is used to negotiate the
utilisation of the selective acknowledgements during the three way
handshake. It MUST thus not appear in any DSS-mapped payload. If a
host receives a DSS-mapped payload that contains this option, it MUST
ignore the entire DSS-mapped payload.
Bonaventure Expires January 7, 2016 [Page 16]
Internet-Draft MPTCP Long Options July 2015
5.5. SACK option
This option, defined in [RFC2018], MAY either be sent as a regular
TCP option or inside a DSS-mapped payload. Placing the option in a
DSS-mapped payload has two advantages. First, the length of the SACK
option is not anymore limited by the maximum length of the TCP
header. Second, this option will be delivered reliably to the
destination.
5.6. Timestamps
This option, defined in [RFC1323] and revised in [RFC7323] SHOULD not
appear in any DSS-mapped payload. It does not benefit from the
reliability provided by the DSS-mapped payload.
5.7. TCP-TFO
Two options are defined in [I-D.ietf-tcpm-fastopen] : Fast Open
Cookie and Fast Open Cookie Request. These two options can only be
used inside SYN segments. For this reason, they MUST never be sent
inside a DSS-mapped payload. If a host receives a DSS-mapped payload
that contains one of these options, it MUST ignore the entire DSS-
mapped payload.
5.8. TCP-AO option
This option, defined in [RFC5925], allows to authenticate the TCP
segments exchanged between hosts. Given the processing rules defined
in [RFC5925], it seems difficult to place it as defined in [RFC5925]
inside a DSS-mapped payload. For this reason, a host MUST never send
the TCP-AO option inside a DSS-mapped payload.
It should be noted that a DSS option of length 20 bytes can be used
inside a segment that is covered by a TCP-AO option of 20 bytes or
less.
5.9. TCP-User Timeout
This option is defined in [RFC5482]. It MAY either be sent as a
regular TCP option or inside a DSS-mapped payload. Placing the
option in a DSS-mapped payload provides a reliable delivery of the
option for the applications requiring it.
5.10. Multipath TCP options
Several Multipath TCP options are defined in [RFC6824]. Some of them
can benefit from the reliability and the unrestricted length of the
DSS-mapped payload.
Bonaventure Expires January 7, 2016 [Page 17]
Internet-Draft MPTCP Long Options July 2015
The MP_CAPABLE and MP_JOIN options can only appear in SYN segments.
They MUST never be sent inside a DSS-mapped payload. If a host
receives a DSS-mapped payload that contains one of these options, it
MUST reject the entire DSS-mapped payload.
Similarly, a DSS option cannot appear inside a DSS-mapped payload.
If a host receives a DSS-mapped payload that contains another DSS
option, it MUST reject the entire DSS-mapped payload.
The ADD_ADDR and REMOVE_ADDR can benefit from the reliability of
being transported inside a DSS-mapped payload. As discussed in
[Cellnet12], the loss of such options can impact the performance of
Multipath TCP in failover scenarios. Another benefit of the DSS-
mapped payload is that a multihomed host that has several IPv6
addresses could advertise all its addresses by sending a single DSS-
mapped segment. The MP_PRIO option can also benefit from the added
reliability of placing it inside a DSS-mapped payload.
The MP_FAIL option is used when there are problems with middleboxes.
In this case, placing it inside a DSS-mapped payload is unlikely to
help. For this reason, it MUST never appear inside a DSS-mapped
payload.
The MP_FASTCLOSE option is used to abruptly terminate an MPTCP
connection.It can be transmitted as a DSS-mapped option.
6. Security consideration
The solution proposed in this document does not modify the security
properties of Multipath TCP. The security considerations listed in
[RFC6824] [RFC6181] apply.
7. Conclusion
In this document, we have proposed a simple modification to the
format of the DSS option in Multipath TCP to support the transport of
long TCP options inside the TCP payload while leveraging the existing
Multipath TCP mechanisms.
8. Acknowledgements
This work was partially supported by the FP7-Trilogy2 project. We
would like to thank Joe Touch and Bob Briscoe whose work on extending
the TCP option space [I-D.briscoe-tcpm-inner-space]
[I-D.ietf-tcpm-tcp-edo] has motivated this work. This document also
benefitted from comments and suggestions from Fabien Duchene,
Christoph Paasch and Benjamin Hesmans.
Bonaventure Expires January 7, 2016 [Page 18]
Internet-Draft MPTCP Long Options July 2015
9. Informative References
[Cellnet12]
Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O.
Bonaventure, "Exploring Mobile/WiFi Handover with
Multipath TCP", ACM SIGCOMM workshop on Cellular Networks
(Cellnet12) , 2012,
<http://inl.info.ucl.ac.be/publications/
exploring-mobilewifi-handover-multipath-tcp>.
[HotMiddlebox13]
Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O.
Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT
workshop HotMiddlebox , December 2013,
<http://inl.info.ucl.ac.be/publications/
are-tcp-extensions-middlebox-proof>.
[I-D.ananth-middisc-tcpopt]
Knutsen, A., Ramaiah, A., and A. Ramasamy, "TCP option for
transparent Middlebox negotiation", draft-ananth-middisc-
tcpopt-02 (work in progress), February 2013.
[I-D.briscoe-tcpm-inner-space]
Briscoe, B., "Inner Space for TCP Options", draft-briscoe-
tcpm-inner-space-01 (work in progress), October 2014.
[I-D.ietf-tcpm-fastopen]
Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", draft-ietf-tcpm-fastopen-10 (work in
progress), September 2014.
[I-D.ietf-tcpm-tcp-edo]
Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
draft-ietf-tcpm-tcp-edo-03 (work in progress), April 2015.
[I-D.paasch-mptcp-control-stream]
Paasch, C. and O. Bonaventure, "A generic control stream
for Multipath TCP", draft-paasch-mptcp-control-stream-00
(work in progress), February 2014.
[IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to
extend TCP?", Proceedings of the 2011 ACM SIGCOMM
conference on Internet measurement conference (IMC '11) ,
2011, <http://doi.acm.org/10.1145/2068816.2068834>.
Bonaventure Expires January 7, 2016 [Page 19]
Internet-Draft MPTCP Long Options July 2015
[IMC13a] Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., and
B. Donnet, "Revealing Middlebox Interference with
Tracebox", Proceedings of the 2013 ACM SIGCOMM conference
on Internet measurement conference , 2013,
<http://inl.info.ucl.ac.be/publications/
revealing-middlebox-interference-tracebox>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC
5482, March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181,
March 2011.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, "TCP Extensions for High Performance", RFC
7323, September 2014.
Author's Address
Olivier Bonaventure
UCLouvain
Email: Olivier.Bonaventure@uclouvain.be
Bonaventure Expires January 7, 2016 [Page 20]