Re: [apps-discuss] AD Fail - MPTCP API

[John Leslie <[e-mail]>]

Marc Blanchet <[e-mail]> wrote:
> 
> to me, it remains to be seen how the interaction of:
> - happy eyeballs
> - IPv4 vs IPv6 address family preference
> - application using a non-80 port and then falling back to port
>   80/443 because of outgoing port blocking in some access networks
>   (I wrote a draft on that)
> - multiple interfaces which are pretty common these days, such as
>   wifi and cell data-3G-LTE-...
> 
> all of those are common cases today,  many with specific APIs.
> Then you add MP-TCP on top of that.
> 
> I fail to see how those interactions will work. Each of them, taken
> separately, does a good job for its own purpose. but the common case
> shall include all of these. Not sure the underlying OS could do all
> the job for the APP, too.
> 
> so, no clear suggestion, but a concern about complexity of apps and
> how well these techniques will interact and work each other.

   I think this deserves some discussion (and I was hoping someone else
would start it. ;^)

   Understand, first, that MPTCP can only use multiple paths if

- one TCP connection is established with MP_CAPABLE negotiated by
  three-way handshake with the MP_CAPABLE TCP option (this presumably
  will be quite common, eventually);

- at least one endpoint originates another TCP connection with MP_JOIN
  (instead of MP_CAPABLE) negotiated by three-way handshake with the
  MP_JOIN TCP option.

(i.e. without three MP_CAPABLE TCP options, followed by three MP_JOIN
options, there can be no multiple paths involved.)

   The MP_CAPABLE handshake exchanges keys. If for any reason the
MP_JOIN reaches a different endpoint, the keys will not match.

   In the simple case, the host originating the MP_JOIN will send it to
the same remote address, but from a different interface using a different
source IP address. But there's also a way to advise the other endpoint
of another local address, using ADD_ADDR.

   With ADD_ADDR it is possible to enable multiple paths using both
IPv4 and IPv6, as well as different ports, though some implementations
may not support this, and even if supported by the endpoints, things
can go wrong in the middle.

   So, let me try to chip away at the cases Marc asked about...

> - happy eyeballs

   Happy eyeballs is implemented in different ways, but generally
overlaps an attempt to establish an IPv6 connection with an attempt to
establish an IPv4 connection, discarding the one which doesn't complete
first.

   Both attempted connections are likely to carry the MP_CAPABLE option,
and may or may not succeed in negotiating it. But only one will be used.
Attempting an MP_JOIN must happen later, though I suppose ADD_ADDRs
could be exchanged so that the other IP version could be tried for a
secondary path -- that probably won't be common -- and even with that
there would be no re-use of the connection which finished second.

> - IPv4 vs IPv6 address family preference

   Same as "happy eyeballs". (Note that ADD_ADDRs would need to be
exchanged to make use of both address families.)

> - application using a non-80 port and then falling back to port 
>   80/443 because of outgoing port blocking in some access networks 

   Really the same, also; though different ports within the same
address families are easier to implement.

> - multiple interfaces which are pretty common these days, such as 
>   wifi and cell data-3G-LTE-...

   It would be quite practical to establish the initial TCP connection
on a more expensive service; then do MP_JOINs on the less expensive
service, essentially dropping the more expensive service so long as
the less expensive one keeps working.

   Note also that MPTCP _intends_ to keep the same MPTCP connection
(group) functioning as an interface gets different IP addresses.

====

   (I have only answered for what the protocol allows for. YMMV with
differing implementations.)

   The draft named in this thread covers only a basic API, which
could give the endpoint application(s) better control over various
tradeoffs involved in the internals of an MPTCP implementation. The
protocol itself is found in draft-ietf-mptcp-multiaddressed, which
is already approved for publication as an Experimental track RFC.

--
John Leslie <[e-mail]>