Subject: [multipathtcp] TCP option kind assignment for MPTCP

From: <[email-masked]>
Date: Fri, 24 Feb 2012 08:43:48 +0000

Thanks for all the discussion about this and your help clarifying the issues which has been very useful.

There seems to be consensus to go for Yoshifumi's option 1, ie ask for a new standards allocation (rather than use the experimental codepoint 253/254). Here is a draft email request for IANA and IESG, please correct errors introduced and suggest any improvements
Thanks!
Phil & Yoshifumi
---

Dear IESG and IANA,
Thank-you for your advice about the steps we need to take to understand what IANA request the MPTCP WG should make for assignment of a TCP Option Kind Number. We have now discussed this and the WG has reached consensus to request IANA to allocate a new (standards) codepoint.

The Multipath TCP WG has been developing the MPTCP protocol. The main parts of the protocol have been stable for some time and the I-D is currently in WG last call http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed
As defined by our charter, the protocol is experimental track - although we hope to re-charter soon and include a standards track bis.

The WG has discussed two IANA options:

1)      A new standards codepoint

2)      Use an experimental codepoint + http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options

Since the protocol is currently Experimental track, option (2) seems more logical. We now explain why the WG has concluded it is not the right one, essentially due to a lack of space in the TCP options field.

If option 2) is chosen, there are two cases to consider:

A)     SYN packets
Several of MPTCP's messages are sent on the TCP-SYN handshake, including MP_JOIN which adds a new sub-flow to an existing MPTCP connection (Section 2.2, http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-06#page-9 ). Space is most critical for MP_JOIN on the SYN/ACK (Fig 6) where typically we'd expect:
* MSS (4 bytes)
* window scale (3 bytes),
* SACK permitted (2 bytes)
* timestamp (10 bytes)
* Magic Number for Experimental Option (2 or 4 bytes)
* MP_JOIN on SYN/ACK (16 bytes)
TOTAL 37-39 bytes.

This appears to fit into the max 40 bytes of the TCP option field.
However, some operating systems pad each option up to a word boundary (a brief survey suggests Windows XP and Mac OS X do this, whereas Linux does not), which leads to TOTAL 44 bytes which doesn't fit.

Since we do not want MPTCP to be limited to Linux-only, this would imply that MP_JOIN must be re-designed, which would have security implications.

B)      TCP data packets
The MPTCP message DATA_SEQUENCE_SIGNAL contains a mapping between the sequence numbers of a MPTCP sub-flow and the MPTCP connection (Section 2.4 http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-06#section-2.4 ). Typically we'd expect:
* timestamp (10 bytes)
* Magic Number for Experimental Option (2 or 4 bytes)
* MPTCP's DATA_SEQUENCE_SIGNAL (max 28 bytes)
TOTAL 40-42 bytes, or 44 bytes with word padding.

However, the DATA_SEQUENCE_SIGNAL has been designed flexibly and can use less than 28bytes, so we could fit within the 40 byte limit. It contains a Data Sequence Number and Data ACK, both of which can be 0, 4 or 8 bytes in length; for example, it might be possible to alternate which one is included, although this may have performance implications.

Therefore the critical factor is that using an Experimental codepoint for the TCP Option Kind Number will either require re-design of MP_JOIN and (presumably) poorer security, or else will limit MPTCP to operating systems that don't pad each TCP option up to a word boundary.

There is also a positive case for choosing Option 1) (A new standards codepoint):-
* MPTCP is being implemented by multiple operating systems. There is a reference implementation in Linux, available at http://mptcp.info.ucl.ac.be/ The plan is to push this upstream starting the end of this year. A Free BSD implementation has been funded recently, it is also being implemented in Solaris, and there is work to integrate it on Android. The existing implementation has already had quite a lot of downloads and experimentation. All this indicates considerable interest in MPTCP.
* We intend for MPTCP to get wide use and would like it to be used by default.
* A standards-track bis is likely to come shortly - we want to re-charter to do this. Migration should be easier with a standards codepoint, as it should be easier to avoid interoperability problems between different MPTCP stacks.
* MPTCP is designed to use only one option number whilst being extensible. It uses a version field in the initial handshake and the protocol uses sub-option numbers (8 sub-option types are defined for the various MPTCP messages) and also has flags to allow other cryptographic handshake algorithms (beyond HMAC-SHA1). In summary, an additional option number will not be required.
* There is a prior instance of allocation of a TCP Option kind number for an Experimental track protocol (Quick-Start).

Our preferred allocation is TCP Option Kind #30 as this is what the implementation uses.

Best wishes
Philip Eardley & Yoshifumi Nishida, MPTCP WG Chairs

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Feb 2012 09:50:54 -0500

The parts about exceeding 40 bytes are excellent.

   Alas, there are several WMDs in the rest: let me recommend rewording...

[email-masked] <[email-masked]> wrote:
> 
> Since the protocol is currently Experimental track, option (2) seems
> more logical...
  ^^^^ ^^^^^^^
   This isn't even right, and it definitely sets the wrong tone.
I suggest "might seem logical".

> * MPTCP is being implemented by multiple operating systems...

   This is a subtle point. It's not that MPTCP _is_ being implemented on
multiple OSs, it's that MPTCP _needs_to_ be implemented on multiple OSs.
Otherwise we couldn't run useful experiments.

   s/ is / needs to be /

> * There is a prior instance of allocation of a TCP Option kind number
>   for an Experimental track protocol (Quick-Start).

   This should go at the end.

   It would help (IMHO) to quote from the IANA page:
" 
" Registration Procedures
"   IESG Approval or Standards Action

and
" 
" [*] It is only appropriate to use these values in explicitly-
"     configured experiments; they MUST NOT be shipped as defaults in
"     implementations.

and note the difficulties of obeying this restriction given our need for
implementation in multiple operating systems.

> Our preferred allocation is TCP Option Kind #30 as this is what the

   This _should_not_ be in the request. It makes _us_ look like squatters.

====

   I also recommend including some text discussing the need to experiment
with multiple operating systems and with options visible in the backbone.
(It's not that they need to be acted upon in the backbone: it's that
they need to find their way between endpoints without requiring action
by middleboxes. Of course, there will _be_ middleboxes, some of which we
must treat as damage; but we need real-Internet experience with paths
free of middleboxes.)

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 09:00:50 +0000

Thanks. will work all these in

We will drop the request for option #30 & let IANA decide (if our request is approved) - it seems there is already someone (else) using it
http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086447/Accessing-TCP-Options-from-iRules.aspx 
or:
http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-00 

phil
-----Original Message-----
From: John Leslie [mailto:[email-masked]] 
Sent: 24 February 2012 14:51
To: Eardley,PL,Philip,DUB8 R
Cc: [email-masked]
Subject: Re: [multipathtcp] TCP option kind assignment for MPTCP

  ^^^^ ^^^^^^^

   s/ is / needs to be /

and
" 

====