Re: [multipathtcp] High-level design decisions /architecture

[William Herrin <[e-mail]>]

On Tue, Nov 3, 2009 at 11:00 AM, Scott Brim <[e-mail]> wrote:
> William Herrin allegedly wrote on 11/02/2009 4:28 PM:
>>> each MPTCP subflow looks exactly like an ordinary, semantically independent
>>> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are
>>> independent on each subflow
>>
>> I'm almost sold on the idea of subflows. Can you give me a run down on
>> the pros and cons, particularly the cons?
>
> My biggest con is if your destination is multiply connected behind two
> non-synchronized intrusion prevention devices.

Hi Scott,

I thought that was one of the pros of subflows? Since each subflow is
its own 2-way TCP connection between two specific addresses they can
interact with middleboxes independently without requiring the
middleboxes to talk to each other?

Or am I missing something?


On Tue, Nov 3, 2009 at 11:55 AM, Joe Touch <[e-mail]> wrote:
> Scott Brim wrote:
>> Joe, that's just not necessary except for legacy endpoint stacks.  See
>> the iPhone and "connectByName".  If the API revolves around a connection
>> ID, regardless of underlying addresses, then IP addresses can come and
>> go as they with as long as the transport layer has some mechanism of
>> maintaining session authenticity and continuity.
>
> This is fine if you're defining a new transport protocol. TCP *defines*
> a connection by the socket pair. If that socket pair disappears and you
> keep the connection up, I would argue you need to use a different
> protocol number because you've seriously changed the semantics.

Hi Joe,

I'll stake out a middle ground on this one.

On the one hand, this entire exercise is academic if we don't keep the
connection up when the original address pair fails. The high-level
purpose of something like MPTCP is to break TCP's dependence on IP
address stability. So, you're right: we've seriously changed the
semantics of the TCP connection.

On the other hand, the vast majority of TCP applications won't care
about the change in semantics. If it's possible to improve these apps'
capability without requiring the developers to touch them again,
that's a plus that's hard to argue against.

If you accept the preceding two points, it leaves an open question:
what do we do about the apps which *do* depend on the non-MP
semantics? My druthers here are: first and foremost be honest, and
second: do what I say; don't try to guess what I mean.

Where the old API can't accurately present what's going on, it should
offer a "no information" response, not an approximate response.


On Tue, Nov 3, 2009 at 3:54 AM, Yoshifumi Nishida
<[e-mail]> wrote:
> From: William Herrin <[e-mail]>
>>>> The MPTCP connection is identified, from an apps perspective, by the
>>>> addresses associated with the original path (even if that subflow /path
>>>> closes)
>  > I'm concerned about this idea.
>  > If the answer is C, protocols like FTP which initiate multiple TCP
>  > connections to the same IP address fail once an endpoint gives up its
>  > original address. That'll also impact web browsers which employ dns
>  > pinning.
>
> In case of ftp, the choice would be something like this?
>
>  1: we don't support this case. ftp will fail.
>  2: ftp client/server performs getsockname() before port/pasv
>     to check its own active IP address. (But, we need to
>     define getsockname() should return active IP address instead
>     of original IP)
>  3: Develop new ftp for MPTCP (using new API etc..)
>
> I personally prefer 1.. then might do 3 later..

Hi Yoshifumi,

I tend to think that has to be the result as well. But if so then we
should avoid offering faulty information via the APIs. That is, don't
identify the connection by it's original IP address pair. If an
old-api application cares what the address pair is but has been
incompatibly instructed to use MPTCP, help it fail quickly rather than
giving it a stochastic success rate.

This means that explicitly binding the local address should implicitly
turn MPTCP off. It also means calls like getpeername and getsockname
should return an error or zeroed values when MPTCP is enabled so that
we explicitly notify the application that we can't provide accurate
information.


> In case of dns pinning, I don't see any issues.

DNS pinning means that the browser will indefinitely refuse to try a
different IP address for new TCP connections to a server that it's
running javascript for. This means that although the individual
connections will succeed on the changed addresses, the web session
overall will still fail.

Not TCP's problem strictly speaking, but if we want MPTCP to be useful
at a practical level we should consider how the dozen most common
application categories (like browsers using HTTP and mail servers
using SMTP) will interact with it.


On Tue, Nov 3, 2009 at 2:37 PM, Ford, Alan <[e-mail]> wrote:
>> What's wrong
>> with starting all TCP connections in non-MP mode and allowing the
>> connection's initiator to request MPTCP starting with any packet that
>> expects an ACK?
>
> I'm intrigued with your suggestion, though. I see your point that there
> may not be any critical reason why this information should be known at
> the beginning of a session. I can't immediately think of any technical
> reason why doing it later in a session wouldn't work. But it would need
> further thought.

Hi Alan,

My druthers would be for an API and/or system tunable delay before
MPTCP starts up so that very short lived TCP connections don't suffer
any new overhead.

The only downside that jumps out at me is that if a connection is
eligible for MPTCP we can't report to the application that the
connection definitely isn't MPTCP.


>> each MPTCP subflow looks exactly like an ordinary, semantically independent
>> TCP flow. MPTCP effectively runs on top. So re-transmission, FINs etc are
>> independent on each subflow
>
> [Alan: Yes, I think this is an important high-level decision]

Whoops, missed this one on the first read through.

Retransmit is a problem. If retransmit is strictly independent then
the unexpected collapse of any subflow kills the entire connection.
That reduces overall TCP reliability to the product of each path's
reliability.

Even if we don't withdraw a segment from a subflow once it has been
assigned, we need to be able to send another copy in a different
subflow should the first subflow stall. Whole can of worms waiting for
us there.

Regards,
Bill Herrin



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