Re: [multipathtcp] AD Review: draft-ietf-mptcp-architecture-03

[Sébastien Barré <[e-mail]>]

Hi Lars,

thanks for the comments !
Just three questions/reactions on this:

Op 17-12-10 13:01, Lars Eggert schreef:
>
> Section 5.4., paragraph 3:
>>     The MPTCP protocol design will, however, use TCP Options for this
>>     additional signalling.  This has been chosen as the mechanism most
>>     fitting in with the goals as specified in Section 2.
>    Aside: Instead of using several different TCP Option numbers, I wonder
>    if we can use one TCP Option Number for MPTCP and disambiguate based
>    on the Length field what kind of MPTCP option we have? (Assuming all
>    our different option kinds have different lengths...)
To me, this would not allow much extensibility for the protocol, given
any new option would need to be designed in such a way as to ensure that 
the len field is different from any previously used one.
OTOH, what is doable (at the cost of longer options though), is to add a 
'subtype' field. That is, TLV would become:
Type: MPTCP
Length: well, the length :-)
Value: Subtype (one byte)+real value.

In any case, going for a single option number would of course require a 
revision of draft-ietf-mptcp-multiaddressed-02.txt. Also, several 
options have currently variable lengths (like ADD_ADDR of DSN).
> Section 5.5., paragraph 6:
>>     The modularity of path management will permit alternative mechanisms
>>     to be employed if appropriate in the future.
>    What modularity of path management? Nothing in this section so far
>    talks about modularity. Suggest to drop this paragraph.
indeed. I guess this will more be the topic for the implementation draft.
>
> Section 5.8., paragraph 11:
>
>>     o  The desire to support a 'break-before-make' (as well as a 'make-
>>        before-break') approach to adding subflows implies that a host
>>        cannot rely on using a pre-existing subflow to support the
>>        addition of a new one.
>    But I don't think we want to support "unlimited" break-before-make,
>    i.e., just because we had the connection up yesterday doesn't mean I
>    should still be able to join a new first flow into it today. In other
>    words, we want to support break-before-make for some limited amount of
>    break time only.
agreed, but in what does it change the requirement that "a host cannot 
rely on using a pre-existing subflow to support the addition of a new 
one." ? BTW, I wonder to what extent this is reasonable given some 
security approaches for subflow establishment may require the exchange 
of data on other subflows. The constraint above *eliminates* all this 
class of security solutions. I am not sure what is best, just saying 
that we can decide to favor one or the other here, also taking into 
account that we are not yet stable with security stuff.

A possible alternative text (somewhere in between) would be: "The desire 
to support a 'break-before-make' (as well as a 'make-before-break') 
approach to adding subflows implies that a host cannot rely on using a 
specific pre-existing subflow to support the addition of a new one. It 
can however decide to use some available subflow to exchange data as 
part of its secure subflow establishment."
This would let more flexibility for the ongoing security discussion. 
Opinions ?

regards,

Sébastien.

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