Subject: [multipathtcp] codepoint for mptcp options

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 3 Feb 2012 11:38:12 -0800

Hello,

After some discussions with ADs, we think we'll need to discuss which
codepoint we should use for mptcp options.
I think we have the following choices for this.

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

If we go 1, I think we'll need to list rationales to convince IESG.
If we don't have good reason for 1, I think we'd better go 3. 2 might
not be good for wider experiments

My concern for 3 is using draft-ietf-tcpm-experimental-options-00 will
require extra option space for magic number, which might cause issues
since some mptcp options use lots of space (e.g. DSS)

Please let us know your thoughts on this.

Thanks,
--
Yoshifumi & Phil

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Feb 2012 19:49:52 +0000

Hi,

> If we go 1, I think we'll need to list rationales to convince IESG.

I think we want to go for #1.

If I were to make the argument, I'd say that (1) MPTCP is safe for experimentation on the broader Internet, (2) there is considerable interest(*) and (3) therefore a standards-track bis is likely to come shortly. Hence, we want permanent, dedicated option numbers.

Lars

(*) With a Linux implementation scheduled to be merged upstream, and a BSD implementation funded for implementation.

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Feb 2012 15:08:23 -0800

Hi, all,

#1 is appropriate if and when this is reconsidered as standards-track 
only. I don't like the idea of experimental protocols using assigned 
options.  It burns a TCP option that can't be reclaimed.

IMO, #3 is appropriate IMO.

At some point, if a new standards-track version released, you can then 
more easily decide whether to support both the #1 and #3 variant or just 
the #1 variant - based on whether there are protocol changes in the 
standards-track version that are not backward compatible.

Joe

On 2/3/2012 11:49 AM, Eggert, Lars wrote:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 4 Feb 2012 00:41:32 +0000

Hi,

On Feb 3, 2012, at 15:08, Joe Touch wrote:
> #1 is appropriate if and when this is reconsidered as standards-track only. I don't like the idea of experimental protocols using assigned options.  It burns a TCP option that can't be reclaimed.

so while I'm fully in agreement with the conservation principle, let me say that we have assigned option numbers for experimental use through the IETF before, i.e., RFC 4782. Yes, we have only done this once, but there is precedence.

Also, could we even burn the additional byte in the beginning of the option with MPTCP? What would the impact be, e.g., does this the amount of SACK we can transport? 

Finally, this is an IETF effort with (soon) multiple available implementations. Yes, it's Experimental, but IMO it's much less Experimental than Quickstart (RFC4782) was.

MPTCP has already introduced sub-option numbers so that it can operate using only one assigned option number. IMO we should just assign the option number.

What do others think?

Lars

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 05 Feb 2012 00:07:43 -0500

> Please let us know your thoughts on this.

Based on the situation, my opinion is that *if* we can spare the
resources, option 3 is functionally identical to option 1, and is
"the right thing" to do.  If we can't spare the space, I'm personally
supportive of option 1, largely for the same reasons that Lars
described.

The "if" above is something I don't know the answer to.  We need to
"show the math" in order to justify option 1.

Option 2 is definitely "wrong", based on what we know about TCP options
today.

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.

-- 
Wes Eddy
MTI Systems

---

From: John Leslie <[email-masked]>
Date: Sun, 5 Feb 2012 05:35:46 -0500

>> 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.

> 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 <[email-masked]>

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 14 Feb 2012 10:32:16 +0200

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

---

From: Guillaume DUGUE <[email-masked]>
Date: Tue, 14 Feb 2012 09:59:45 +0100

Dear working group and contributors,

I do not think I have seen it so far, but can anyone give me any insight 
about a draft being under study for the description of the MPTCP MIB.

Thank you very much,

Best regards,

Guillaume Dugué
LAAS-CNRS, Toulouse, FRANCE

---

From: Scott Brim <[email-masked]>
Date: Tue, 14 Feb 2012 08:44:00 -0500

> - Intel are actively working on integrating MPTCP on Android and seeing how MPTCP works for mobility.

While I agree on getting a new codepoint, I would not use the vast
popularity and widepspread deployment of MPTCP as a justification :-)

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Feb 2012 15:41:25 +0000

Hi,

On Feb 14, 2012, at 0:59, Guillaume DUGUE wrote:
> I do not think I have seen it so far, but can anyone give me any insight about a draft being under study for the description of the MPTCP MIB.

I don't think there is such a draft at the moment. And I think we need more experience with the implementations before we can really know what parameters/metrics would be useful to include in one.

Lars