Subject: Re: [multipathtcp] codepoint for mptcp options

From: [email-masked] (Noel Chiappa)
Date: Tue, 14 Feb 2012 11:14:42 -0500 (EST)

> From: John Leslie <[email-masked]>

    > I agree with Lars that we should go for a new TCP option

Yes, I too think this makes sense.

    > The TCP Option Number space _is_ limited, but not all that limited.
    > In the history of TCP we've burned through 29 of 255 .... Eleven of
    > those are considered obsolete and could be reassigned if things got
    > _really_ tight.

When I compare the scarcity of the resource and the usage rate (above) on
the one hand, and the level of likely interest/usage in this design on the
other, it's clear that the balance is in favour of assigning one.

	Noel

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Feb 2012 08:33:43 -0800

FWIW, *if* this is assigned a TCP option of its own, I urge the group to select a name that is *accurately* describes the purpose of this option, e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and because TCP options persist, is likely to continue to cause confusion.

Joe

On Feb 14, 2012, at 8:14 AM, Noel Chiappa wrote:

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Feb 2012 16:39:46 +0000

> FWIW, *if* this is assigned a TCP option of its own, I urge the group to select a name that is *accurately* describes the purpose of this option, e.g. "multiaddress" or "multiIP". "Multipath" is mi…

I think "multipath" is the best term. If you have a single-homed host talking to a multi-homed host, MPTCP will be opening connections along multiple paths but only one IP address is in use at one end. I don't think this case is described by either "multi-address" or "multi-IP".

Also, the WG and protocol are also named "multipath" TCP. Using a different name for the option is confusing (and renaming the protocol and WG is impractical and confusing.) 

Lars

---

From: Alan Ford <[email-masked]>
Date: Tue, 14 Feb 2012 16:44:12 +0000

On 14/02/2012 16:39, "Eggert, Lars" <[email-masked]> wrote:
>> FWIW, *if* this is assigned a TCP option of its own, I urge the group to
>> select a name that is *accurately* describes the purpose of this option, e.g.
>> "multiaddress" or "multiIP". "Multipath" is misleading, and because TCP
>> options persist, is likely to continue to cause confusion.
> 
> I think "multipath" is the best term. If you have a single-homed host talking
> to a multi-homed host, MPTCP will be opening connections along multiple paths
> but only one IP address is in use at one end. I don't think this case is
> described by either "multi-address" or "multi-IP".
> 
> Also, the WG and protocol are also named "multipath" TCP. Using a different
> name for the option is confusing (and renaming the protocol and WG is
> impractical and confusing.)

Agreed.

What's more, the protocol, by using a version field in the initial
handshake, and extensible sub-types for messages, has been designed mindful
of the hope that new (and more accurate) path selection mechanisms *could*
be "plugged in" in the future.

Regards,
Alan

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Feb 2012 08:47:49 -0800

> Also, the WG and protocol are also named "multipath" TCP. Using a different name for the option is confusing (and renaming the protocol and WG is impractical and confusing.) 

IP addresses don't determine path. Even single-homed to multi-homed requires multiple addresses, but doesn't necessarily require independent paths.

Perhaps "multihomed" makes more sense - even by your own description above.

FWIW, I did bring this up when it was a BOF, so claiming inertia at this point doesn't cut it.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Feb 2012 08:49:29 -0800

> be "plugged in" in the future.

As an exercise, can you confirm whether you think this option could ever be used when there are two single-homed hosts in a way that differs from existing TCP? If so, you could accurately call that a path-selection extension to this at best.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Feb 2012 08:51:08 -0800

PS - I still think this is an end-run around process. TCP options are intended for standards-track extensions, and this isn't - yet.

IMO, this is a great place to emphasize the use of the experimental code point, esp. shared use. If we can't argue that successfully for this, then perhaps we never can and should abandon the concept of experimental code points altogether.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 14 Feb 2012 12:01:40 -0500

> FWIW, I did bring this up when it was a BOF, so claiming inertia at this point doesn't cut it.

The existing RFCs using "MPTCP" seem clear about what it is (e.g.
see RFC 6182), and an option allocation will need to relate to them
using the same name.  I think section 5.5 has a reasonable discussion
of the current use of addresses as an approximation.  Those RFCs are
just as persistent as the IANA registry (or moreso).

I hope we can move past talking about whether the name is slightly
misleading or not, since I don't think it's relevant to the decision.

-- 
Wes Eddy
MTI Systems

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Feb 2012 17:16:01 +0000

> As an exercise, can you confirm whether you think this option could ever be used when there are two single-homed hosts in a way that differs from existing TCP? If so, you could accurately call that…

Yes. There was someone on the MPTCP developers list recently who wanted to use four subflows between to single-homed machines, because their ISP capped single-flow throughput at a quarter of the upstream bandwidth.

(This isn't something that the implementation supports without manual configuration, but the code does support it.)

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 14 Feb 2012 17:18:34 +0000

> PS - I still think this is an end-run around process. TCP options are intended for standards-track extensions, and this isn't - yet.

That's not true. TCP options can be assigned via a Standards Action *or* IESG Approval.

IESG Approval is a choice exactly because there are cases where we want to be able to assign numbers without a Standards Action. It's not done often, but it can be done if the IESG can be convinced to do so. (Which is what we will need to do if we want to go that route.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Feb 2012 10:13:04 -0800

> (This isn't something that the implementation supports without manual configuration, but the code does support it.)

OK - that's multiflow then.

You're giving a lot of good reasons multipath is a really misleading name.

Joe

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 14 Feb 2012 22:24:34 +0200

> As an exercise, can you confirm whether you think this option could ever be used when there are two single-homed hosts in a way that differs from existing TCP? If so, you could accurately call that…

Actually MPTCP works very well with ECMP deployed in the network by operators. 

MPTCP enabled end-hosts open multiple subflows between the same addresses but different port combinations (i.e. at least one port has to differ).

This is used heavily when MPTCP is used in data-centers, which commonly employ ECMP to allows endpoints to use multiple paths.
Costin

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 14 Feb 2012 12:45:28 -0800

On Tue, Feb 14, 2012 at 10:13 AM, Joe Touch <[email-masked]> wrote:
>>> As an exercise, can you confirm whether you think this option could ever
>>> be used when there are two single-homed hosts in a way that differs from
>>> existing TCP? If so, you could accurately call that a path-selection
>>> extension to this at best.
>>
>>
>> Yes. There was someone on the MPTCP developers list recently who wanted to
>> use four subflows between to single-homed machines, because their ISP capped
>> single-flow throughput at a quarter of the upstream bandwidth.
>>
>> (This isn't something that the implementation supports without manual
>> configuration, but the code does support it.)
>>
>> Lars
>
>

IMO, I think we could call them flows in multiple logical paths, which
multipath doesn't sound misleading to me.

--
Yoshifumi

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 14 Feb 2012 21:56:39 +0100

Joe,

> FWIW, *if* this is assigned a TCP option of its own, I urge the group to select a name that is *accurately* describes the purpose of this option, e.g. "multiaddress" or "multiIP". "Multipath" is mi…

I would suggest using MPTCP as the option name. This is the acronym of
the WG, it correctly reflects the protocol. I don't think that we need
to spell out the acronym.

Olivier