Re: [multipathtcp] draft-ford-mptcp-multiaddressed-02: Need ports in ADD address

Hi,

There is plenty of discussion on the mailing list about this, but  
maybe it doesn't cover all the issues. Let me try to summarize again:

- for ADDITIONAL subflows (i.e. not the first one) the port number in  
the SYN packet does not matter for the host; demultiplexing is done  
using the connection token.  (this addresses point 1 - you don't need  
to reserve that port on all interfaces).
- let's first answer the question of WHEN add address option is used.  
It is only used when subflow establishment fails from A to B (which  
probably means B is behind NAT). At this point, the host with address  
A will send add address on another subflow, telling the host with  
address B please contact me here. B will send a SYN to A, with the  
proper token. If A is behind a NAT (both A and B are now natted) this  
will not work. People are arguing that if a port were signalled from  
A to B this might work. I have doubts, since this doesn't really work  
today either. However, I have nothing against putting the port in if  
people think it would help reachability.

Costin

On 12 Nov 2009, at 11:17, Magnus Westerlund wrote:

> Hi,
>
> I just looked at draft-ford-mptcp-multiaddressed-02 and saw that  
> the add
> address option lacks a port number. I think that will not work for two
> reasons.
>
> 1. First, there will a large amount of single flow TCP connections and
> you will run into a synchronization issue and resource constrain issue
> if you limit your interface port to be the same over all interfaces.
>
> 2. Your NAT traversal will fail as soon it encounters a NAT that is
> unable to do port preservation. That is likelier and likelier to  
> happen,
> espeically for ISP place NATs where the load level is higher. Port
> preservation will also fail as soon as two sub-flows goes over the  
> same
> NAT. Thus to enable MPTCP to work in cases where you use either an
> explicit signalling protocol (UPnP, etc) or implicit methods, like  
> STUN
> to find out your external subflow address they will not be able to
> preserver the port in the generic case. Thus there is need to be  
> able to
> indicate the listening port.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp