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

[William Herrin <[e-mail]>]

On Tue, Nov 3, 2009 at 5:20 PM, Joe Touch <[e-mail]> wrote:
> TCP negotiates all options during the SYN - that's the only 'handshake'
> there is. TCP does not define option negotiation after connection
> establishment.
>
> I.e., you can decide to start the separate connections later, but you
> need to negotiate support for the option during the SYN.

Hi Joe,

I assume that's a convention rather than a hard protocol requirement.
Something previous folks working in the space have deemed a "wise
idea" rather than a "all these things will break if we don't" kind of
thing, yes?

Is there a good discussion on this somewhere so I can read up on the
rationale that brought it into being?




On Tue, Nov 3, 2009 at 6:03 PM, Ford, Alan <[e-mail]> wrote:
> I think Scott's concern is with an IDS that may look at traffic which
> does not behave maliciously until it is spread across multiple subflows,
> thus requiring the IDS to do some correlation between (what it sees as)
> multiple traffic flows. But I'm sure Scott can be more specific...

Oh, I see. Like splitting the HTTP request into multiple subflows so
that the IDS can't see the request, yes?

Smells like a system configuration issue to me: if you want the IDS to
do deep packet inspection, you have to arrange for all possible flows
to and from the protected system to go past the same IDS and if your
protected systems are configured to support MP then then the IDS must
be able to recognize MP as well.

I'll entertain suggestions why it's actually worse than that, but at
the moment I don't see how that's a con versus MPTCP that breaks up
traffic some other way than subflows.


> I do have a
> concern that recommending APIs return a null value in such a case may
> itself be overloading an error signal to an application. I would hope
> that applications should be able to cope with such a return value, but
> it is unlikely that all will.

I figure that if we accept the proposal that we should support
applications using the legacy API at all then the best we can do for
the ones who need to know the local and/or remote address and port
information is to provide values which:

A. Are unlikely to induce a security problem, and
B. Will tend to pull up information about multipath TCP and legacy
apps if the user plugs the unexpected values into a google search.

My thought on this is that we should identify some IP address which is
routable as a destination in as few deployed IP stacks as possible. We
can register it with IANA as meaning "multipath TCP in operation but
legacy API in use."


>> 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.
>
> Yes. And it also takes the initial decision to use MPTCP away from the
> initiating endpoint (not necessarily a bad idea, just something that
> changes what one may expect a transport protocol's behaviour to be).

Allowing either side to start MPTCP creates some complexity since:

1. The sides' attempts to start MPTCP could overlap requiring one of
them to yield to the other.
2. Regardless of who starts MPTCP, only the connection's initiator can
start up new subflows without running afoul of the firewall.


>> 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.
>
> What we have in the design as it stands is that, once a segment of data
> is transmitted on a subflow, that segment of subflow sequence space must
> only be used for that data. That does not, however, preclude also
> sending the same data on another subflow. The data-level sequence
> numbering will permit correct reassembly at the receiver, and this will
> ensure reliability and survivability over failure.
>
> Ah, well, that's kinda what I was describing above. What does your can
> of worms contain?

Closed windows. When the one or more subflows stall, the buffers in
the other flows will fill while the receiver waits for one of them to
contain the next packet in the sequence. How do you make sure there's
always enough buffer left in the other subflows to retransmit packets
from the stalled flow?

Regards,
Bill Herrin


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