Re: [multipathtcp] Interesting paper

[William Herrin <[e-mail]>]

On Wed, Nov 4, 2009 at 8:35 AM, marcelo bagnulo braun
<[e-mail]> wrote:
> Scott Brim escribió:
>>> Mark Handley escribió:
>>>
>>>> We definitely intend MP-TCP to work for both v4 and v6.  More
>>>> debatable is whether we want to permit mixed v4/v6 connections (some
>>>> v4 subflows, some v6, in the same connection).  I'm unconvinced.
>>
>> IMHO the issue is in the API.
>
> The MPTCP extended API. In this case i understnad we should distinguish
> whether the connection was open as an IPv6 connection or as an IPv4
> connection.
> If it was open as an IPv6 connection, i think there is no problem, since
> IPv4 addresses can be represented as IPv4-mapped addresses, so the API
> allows to handle both IPv4 and IPv6 addresses in the same way (i.e. as IPv6
> addresses). some degree of care should be taken not to form incompatible
> address pairs with one IPv4 and one IPv6 address.
> If it was opened as an IPv4 connection, then i thin more thought is needed.

Hi Marcelo,

We could just set up the extended API to be protocol agnostic from the
start, yes? We don't routinely tell it which protocol to use; it tells
us which protocols it has used. Which at some point in the distant
future may be IPv12 and we'd like the then-legacy apps to still behave
in a reasonable fashion.

Main difference would be passing textual representations through the
API instead of protocol-specific structures.



On Wed, Nov 4, 2009 at 1:44 PM, Rémi Després <[e-mail]> wrote:
> But isn't the real question whether the protocol will support NAT
> traversals?
>
> If yes, it would be a pity to make the IPv6 solution more complex than
> needed just to support NAT traversals.

Hi Rémi ,

If subflows are basically TCP streams joined to the larger TCP stream
then we can't expect the connection's acceptor to make new connections
to the initiator. That'll blow up with any firewall, not just NAT.
That was a hard lesson with active-mode FTP too. I would hope we don't
have to learn it again.

If we assume that only the initiator will start new subflows then
client-side NAT (the initiator's end) only really raises an
authentication-by-source-address issue. Which is pretty weak
authentication to begin with so I'd hate to see it derail
compatibility with client-side NAT.

That only leaves server-side NAT. Unless someone identifies a really
elegant solution for handling legacy server-side NAT, my view is:
detect and fail.

Include the destination address in a TCP option when you first
initiate the connection and if the server sees a different address
than you do (because it passed through a NAT that wasn't
MPTCP-compatible enough to change the option too) then MPTCP is
disabled for that connection. As for folks who want to run MPTCP in a
server-side NAT environment, that's the NAT box's problem and the
system administrator's configuration problem, not ours.


> Can't we expect that before MPTCP is agreed on and deployed, the vast
> majority of multihomed hosts will have IPv6?

No. Making any prediction about IPv6 deployment beyond "slow" would be
unwise. That most especially includes predictions about whether any
significant portion of IPv6 users will employ NAT.

Regards,
Bill Herrin


-- 
William D. Herrin ................ [e-mail]  [e-mail]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004