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

["Ford, Alan" <[e-mail]>]

Hi Bill, all,

> On Tue, Nov 3, 2009 at 11:00 AM, Scott Brim <[e-mail]>
wrote:
> > 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?

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...

> 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.

I'd definitely agree with those two points.

> 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.
[snip]
> 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.

I agree with the principle behind all of that. However, 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.

It may be the lesser of all evils, however.

> 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.

That's a very good point, actually. One of my long-standing concerns has
been how to best cope with applications that only need short-lived
sessions, and don't have the extended API to express it.

Another alternative could be a system-wide threshold for traffic before
kicking in multipath.

> 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).

> >> 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.

Ah, I may have read that point wrong.

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.

> 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.

Ah, well, that's kinda what I was describing above. What does your can
of worms contain?

Regards,
Alan