Subject: [multipathtcp] About the ID field in JOIN option and ADDR option

From: Sébastien Barré <[email-masked]>
Date: Fri, 05 Mar 2010 17:22:51 +0100

Hi,

The draft defines an address ID field to be inserted in the JOIN and 
ADDR option. But I think we should makes things more clear there.
Basically, we have three use cases for the ID:

*Addresses there are used from the beginning of the communications 
(identifiers of the connection).
*Addresses that are implicitly announced through the sending of the 
SYN+JOIN with such an address as the source. I understand that the goal 
of the ID in the JOIN is to handle this case.
*Addresses that are explicitly announced through the sending of an ADDR 
option. (which is why the ID is also in the ADDR option)

It seems that the two later cases are fine, but the first one seems to 
be ignored in the draft. I mean, the identifiers of a connection need 
not be announced implicitly nor explicitly, since they are part of the 
initial handshake. That implies that we never attach an ID to them.

Having no ID attached to the identifiers creates ambiguities in the 
protocol. For example, consider the following scenario:
*I start a handshake with A1->B1
*My peer sends an ADDR opt with B2, ID 1
*I send a join with A1->B2. The draft tells that I must add an ID, but 
there is no ID defined for A1.

The simple solution to that is to specify the ID 0 as reserved for the 
identifiers. Moreover, this would allow sending a REMADDR with 0 as ID 
if we want to stop using the main subflow.

Makes sense ?

regards,

Sébastien.

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

---

From: Costin Raiciu <[email-masked]>
Date: Fri, 5 Mar 2010 17:04:42 +0000

Hi Sebastien,

You are right, the draft is not clear. Your solution is the right way to fix it.

Cheers,
Costin

On 5 Mar 2010, at 16:22, Sébastien Barré wrote:

> Hi,
> 
> The draft defines an address ID field to be inserted in the JOIN and ADDR option. But I think we should makes things more clear there.
> *Addresses there are used from the beginning of the communications (identifiers of the connection).
> *Addresses that are implicitly announced through the sending of the SYN+JOIN with such an address as the source. I understand that the goal of the ID in the JOIN is to handle this case.
> *Addresses that are explicitly announced through the sending of an ADDR option. (which is why the ID is also in the ADDR option)
> 
> It seems that the two later cases are fine, but the first one seems to be ignored in the draft. I mean, the identifiers of a connection need not be announced implicitly nor explicitly, since they are part of the initial handshake. That implies that we never attach an ID to them.
> 
> Having no ID attached to the identifiers creates ambiguities in the protocol. For example, consider the following scenario:
> *I send a join with A1->B2. The draft tells that I must add an ID, but there is no ID defined for A1.
> 
> The simple solution to that is to specify the ID 0 as reserved for the identifiers. Moreover, this would allow sending a REMADDR with 0 as ID if we want to stop using the main subflow.
> 
> Makes sense ?
> 
> regards,
> 
> Sébastien.
> 
> -- 
> Sébastien Barré
> Researcher,