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

From: Sébastien Barré <[email-masked]>
Date: Wed, 17 Nov 2010 17:47:03 +0100

Hi Costin, Magnus,

Sorry to excavate a one year old conversation :-).
Given that I received recently from Andreas Seelinger a patch for our 
MPTCP implementation, to support the port addition to the ADDR option, I 
was trying to understand the real uses of that port addition.

AFAIU, there are two main uses I can identify from the conversation of 
last year:
*The host has a local firewall (or remote in fact) that allows incoming 
connections through only some specific ports. We then need to force the 
peer to use one of them when trying to contact us for establishing subflows.
*We are behind a NAT with port forwarding enabled, again with some 
specific port(s). We can learn our public address through some external 
server, and then advertise to the peer the only combination that works 
to reach us: <public address+open port>.

However, from the draft, I only read one example, which has nothing to 
do with the above two: port-based load balancing. From this, I propose 
two things:
*Regarding the port-based load balancing, it would be useful to provide 
a more precise description of what the port advertisement is useful for 
in that area. IMHO, to do port-based load-balancing, we only need to 
play with the source port. The destination port should not be used for 
this.  Hence, as I understand it, the only example use provided in the 
draft, is in fact an example of when we do not need it at all... Do I 
miss something ? Well one specific case would be that some box on the 
incoming path directs the flows based on the dest port, but is this ever 
done ?
*In general, as an implementer, after reading section 3.5.1 as it is, I 
am not really tempted to support the port option. However by reading the 
conversation that motivated the port option, I do see it as useful. 
Hence I really think that some examples (like the two above, maybe a 
more detailed version of the port-based load balancing thing if it makes 
sense, maybe other additional examples) would be good to be added in the 
draft, so that the reader gets the point without going to the archive of 
the mailing list.

thanks !

Séb.

Op 20-11-09 17:11, Costin Raiciu schreef:
> Magnus,
>
> You've convinced me :).
>
> Costin
>
> On 20 Nov 2009, at 14:24, Magnus Westerlund wrote:
>
>> Costin Raiciu skrev:
>>> Hi Magnus,
>>>
>>> In case 1, do you assume a local firewall? I guess in that case the
>>> stack can just inform the firewall about the open port, without 
>>> actually
>>> binding it. I have no idea how this is done today - does the firewall
>>> monitor bound/listeninng ports?
>>
>> Today, it appears that you bind to a socket, which makes the FW check
>> the rules for the application that is binding and if the port number is
>> allowed. Variations exist.
>>
>> For non-local firewalls, you can open a particular port for a service,
>> thus you end up with a requirement to use a particular port, otherwise
>> it doesn't work.
>>
>> I am convinced that you will need to be able to indicate the address and
>> port on which you are listening to make MPTCP to be reasonably
>> applicable. Otherwise you will find numerous issues where the SYN simply
>>  goes to dev/null.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> IETF Transport Area Director
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Fdrvgatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>> ----------------------------------------------------------------------
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Arnd Hannemann <[email-masked]>
Date: Thu, 18 Nov 2010 13:49:15 +0100

Hi,

Am 17.11.2010 17:47, schrieb Sébastien Barré:
> AFAIU, there are two main uses I can identify from the conversation of last year:
>  connections through only some specific ports. We then need to force the>

> *We are behind a NAT with port forwarding enabled, again with some specific port(s).
>  We can learn our public address through some external server, and then advertise to
>  the peer the only combination that works to reach us: <public address+open port>.

Third: (I know this is out of your scope, but wanted to mention it anyway)
Fortunately the current protocol specification allows with minor changes to implement
a  "single addressed" version, where path diversity is assured by other means.
However, to not totally confuse every party involved, if the same endpoint addresses
are used, at least the ports must be different to get different TCP four-tuples.

> However, from the draft, I only read one example, which has nothing to do with the 
> above two: port-based load balancing. From this, I propose two things:
> *Regarding the port-based load balancing, it would be useful to provide a more
> precise description of what the port advertisement is useful for in that area.
> IMHO, to do port-based load-balancing, we only need to play with the source port.
> The destination port should not be used for this.  Hence, as I understand it, 
> the only example use provided in the draft, is in fact an example of when we do
> not need it at all... Do I miss something ? Well one specific case would be that
> some box on the incoming path directs the flows based on the dest port,
>  but is this ever done ?

For a multipath capable router/switch it generally makes sense to use/include
the port number for a load balancing decisions.
e.g. from cisco ios manual load-balance options for port aggregation:
port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port}

> *In general, as an implementer, after reading section 3.5.1 as it is, I am not really
>  tempted to support the port option. However by reading the conversation that motivated
>  the port option, I do see it as useful. Hence I really think that some examples
>  (like the two above, maybe a more detailed version of the port-based load balancing 
>  thing if it makes sense, maybe other additional examples) would be good to be added
>  in the draft, so that the reader gets the point without going to the archive of the
>  mailing list.

Agreed.

Regards
Arnd

--
Dipl.-Inform. Arnd Hannemann
RWTH Aachen University
Dept. of Computer Science, Chair for Communication Systems
Ahornstr. 55, D-52074 Aachen, Germany
Phone: (+49 241) 80-21423 Fax: (+49 241) 80-22222

---

From: Sébastien Barré <[email-masked]>
Date: Thu, 18 Nov 2010 14:57:11 +0100

Hi Arnd,

Op 18-11-10 13:49, Arnd Hannemann schreef:
>>   the peer the only combination that works to reach us:<public address+open port>.
This is fully in scope in fact, for me at least :-). I have proposed in 
the past 
(http://trilogy-project.org/fileadmin/publications/Deliverables/D4_-_Design_Space_Analysis_for_Reachability.pdf) 
a way to decouple path management from the MPTCP-specific stuff. This 
allowed using MPTCP to be used with path managers like Shim6, v4 
multi-address (the default currently), LISP, or label-based flow 
control. Of them, Shim6 and the default path managers are implemented 
(although Shim6 needs an upgrade).

Hence, I am really happy that Andreas implemented the port-based path 
management (although, I think, this does not require
to use the port addition to the ADDR option in all cases).
> are used, at least the ports must be different to get different TCP four-tuples.
Makes sense indeed.

Just to comment more about why the port option is not always needed: The 
receiver of a SYN+JOIN does not use a listening socket for this, and 
thus there is no port binding. Connection identification is based on the 
token. The security is ensured by other means (under discussion at the 
moment). It is thus possible to use multiple ports without announcing 
them explicitly.

> port-channel load-balance {src-mac | dst-mac | src-dst-mac | src-ip | dst-ip | src-dst-ip | src-port | dst-port | src-dst-port}
Indeed. But here was my point: In the context of load balancing, having 
a host telling the other that it needs to be contacted on some specific 
port, assumes that the host knows how those load-balancers are 
configured. I am not convinced at all that this case is very usual. 
Moreover, I guess that if we know that load balancers are in the path, 
we can just select some random source port (hence avoiding the need for 
the port addition) for a new subflow, to give it chances to be sent on a 
different path.
To summarize, in that area, explicitly mentioning the port is needed 
only to work with load balancers:
i) that balance using *only* the dest port.
ii) whose config is known by the end-host.

Finally I'm not arguing against the port addition to ADDR option. Just 
arguing that we should clearly know when it really helps, because it is 
a costly addition (it eats bytes in a small option space, where the ADDR 
is already the biggest one).

regards,

Sébastien.