Hi,

As draft authors, we also strongly support going for a new codepoint. 

While we could make the experimental ones work with a lot of non-trivial bit gimnastics, it will be quite painful and may push us over the edge in what option usage is acceptable in practice.
Furthermore, MPTCP has lots of extensibility built in: a version field in the initial handshake, and different sub-types, have both been designed to ensure MPTCP only needs one codepoint for its deployment.

MPTCP is an important change to TCP whose time has come, as networks are effectively becoming multipath everywhere (mobiles device with many interfaces, wide-scale server multihoming and datacenters). As Lars said there is considerable interest in MPTCP:
- we have a solid Linux MPTCP stack that we are planning to push upstream starting the end of this year (this has been funded recently by Google, and Intel is also helping out with coding).
- a planned FreeBSD MPTCP implementation has been funded recently
- Intel are actively working on integrating MPTCP on Android and seeing how MPTCP works for mobility.

That is why I think MPTCP could evolve to Proposed Standard sooner rather than later. Even if we go with experimental codepoints now, when MPTCP evolves to PS we will need a new properly assigned codepoint. Using an experimental codepoint will only make evolution to proposed standard harder due to interop problems between the different MPTCP stacks.

Cheers,
Costin

On 5 Feb 2012, at 12:35, John Leslie wrote:

> Wesley Eddy <wes@mti-systems.com> wrote:
>> On 2/3/2012 2:38 PM, Yoshifumi Nishida wrote:
>>> 
>>> 1: Ask IANA to allocate new codepoint
>>> 2: Use experimental codepoint (253/254)
>>> 3: Use experimental codepoint (253/254) with
>>> draft-ietf-tcpm-experimental-options-00
> 
>   I agree with Lars that we should go for a new TCP option, rather than
> look like an experiment.
> 
>   The TCP Option Number space _is_ limited, but not all that limited.
> In the history of TCP we've burned through 29 of 255 (the first two
> really don't count, IMHO, but the two "experimental" ones do). Eleven
> of those are considered obsolete and could be reassigned if things
> got _really_ tight.
> 
>   The actual problem in TCP Option numbers is squatting (due to the
> difficulty of getting option numbers allocated for experiments).
> IANA lists ten known cases of squatting (and IMHO will try to avoid
> assigning those numbers):
> ] 
> ] 30     Reserved
> ] 31     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 32     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 33     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 34-75  Reserved
> ] 69     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 70     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 71-75  Reserved
> ] 76     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 77     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 78     Reserved (known unauthorized use without
> ]                  proper IANA assignment)
> ] 79-252 Reserved
> ] 253    RFC3692-style Experiment 1 (also improperly
> ]                  used for shipping products) [*][RFC4727]
> ] 254    RFC3692-style Experiment 2 (also improperly
> ]                  used for shipping products) [*][RFC4727]
> 
>   (That asterisk is very important, IMHO)
> ] 
> ] [*] It is only appropriate to use these values in explicitly-
> ]     configured experiments; they MUST NOT be shipped as defaults in
> ]     implementations.  See [RFC3692] for details.
> 
>> When the request came to the IESG this week from IANA, in order to get
>> an early allocation for MPTCP ("early" means prior to the RFC), I did
>> ask that the decision be deferred until the WG could make sure it has
>> consensus on the question Yoshifumi raised above and can technically
>> back the need for option 1, if it's the consensus.
> 
>   The IESG _does_ need to be careful in assigning these, but they
> have every reason to believe Lars understands the trade-offs. I doubt
> they will actually assign one without Wes agreeing to recommend it,
> but I don't believe they will get anal about whether the RFC defining
> it is "Experimental" status.
> 
>   MPTCP is a very necessary addition to TCP. IMHO we're chartered to
> produce an Experimental spec because it's considered so important that
> we need to get it right. If something _does_ go wrong, we'll keep at
> it until we get it right; and in the almost-unimaginable case where
> the Experimental use has to be suppressed, that will be far easier
> with a dedicated option number.
> 
> --
> John Leslie <john@jlc.net>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp