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

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

Hi Yoshifumi, all, 

>  > > >           o [Question: Should we allow subflows in a single
MPTCP
>  > > >             connection to have different ports?]
>  > >
>  > > Seems like you'd have to - or you have to coordinate port use on
>  > > different addresses at a single endpoint constantly.
>  >
>  > Yes, and we have a demuxing value (the token) anyway. However, for
> optimality it is proposed that the same ports are used on the same
(and maybe
> different) addresses per connection.
> 
> Then, we might need to update Add Address option in the draft to
propagate
> port number.
> and the term Address ID might be a bit confusing.

I don't see that we do. The general principle is that an endpoint should
use the ports that are currently in use at the other endpoint on its new
connections, to maximise getting through firewalls and middleboxes, and
also to support any port-based QoS traffic engineering, etc. That
doesn't preclude an endpoint from trying other port numbers with the
same token, but the chances of that working would seem slim. I'm not
entirely sure whether we want to explicitly permit or explicitly forbid
that, yet.

Unless, there is some other use for signalling alternative port numbers
to use. The only case I can think of may be for tricking load balancers
with the same address to route on alternative paths, but that seems
tenuous at best.

> If we think about the possibility that application can get peer's
secondary
> IP address
> outside of MPTCP (e.g. from DNS) and wants to try it, it might be
convenient
> to
> use one single port for all subflows?

The idea of using additional addresses from DNS etc is an interesting
one. I'm reluctant to suggest this in the protocol - it would seem to
open a number of potential security issues.

One thing that adds a very elementary level of security in the current
design is that signalling of new subflows occurs both over the existing
connection and separately. This is not ideal yet and needs refinement.
Such a solution would not be possible at all with the out-of-band
knowledge exchange.

Besides, an endpoint that knows it has multiple addresses should signal
that immediately if it wants them to be used. (And if it doesn't want
its other endpoint to be used, this gives it the flexibility not to
signal it).

Regards,
Alan