Re: [multipathtcp] Comments on draft-ietf-mptcp-architecture-02

["SCHARF, Michael" <[e-mail]>]

Alan, 

> (although regarding the first point, a key purpose of this 
> draft is to explain how the various outputs of the WG fit 
> together to create a Multipath TCP solution, and therefore 
> referring to these drafts is necessary in places). 

yes, I agree that that they are necessary in some places.

> Regarding a paragraph about the comparison with SCTP, this 
> would likely be useful to new readers but I would appreciate 
> input from people more familiar with SCTP for some text. Here 
> is some suggested text as a starting point:
> 
> 2.4 Related Protocols
>   There are several similarities between SCTP [RFC4960] and
>   MPTCP, in that both can make use of multiple addresses at 
> end hosts to give
>   some multi-path capability. In SCTP, this is by default to 
> support multihoming
>   and mobility (i.e. a single path will change one of its end 
> host addresses).
>   Extensions are proposed to support simultaneous multipath transport
>   [I-D.draft-tuexen-tsvwg-sctp-multipath] but these are yet to
>   be standardised. SCTP is, however, a completely new 
> transport protocol and
>   as such does not meet the network and application 
> compatibility goals as
>   specified above. For network compatibility, there are 
> issues with various
>   middleboxes (especially NATs) that are unaware of SCTP and 
> consequently
>   end up blocking it. For application compatibility, 
> applications need to
>   actively choose to use SCTP, and with the deployment issues 
> very few choose
>   to do so. MPTCP's compatibility goals are in part based on 
> these observations
>   of SCTP's deployment issues.

I think that this text is quite reasonable (apart from the "new", of course). I am not an SCTP expert, but I think that the following statement could maybe make sense as well:

It might be possible to use rather similar algorithms or heuristics both for MPTCP and for SCTP concerning certain functions that are needed in both cases, e. g., a management of paths. However, the additional protocol features of SCTP (e. g., unordered delivery) typically result in additional constraints that the design of MPTCP does not have to take into account.

Just a thought...

Michael