Subject: [multipathtcp] comments on MPTCP Application Interface considerations

From: <[email-masked]>
Date: Thu, 28 Oct 2010 09:40:03 +0100

I like the draft, especially now you've split the "basic" vs "advanced" extended api

A few minor comments.

I suggest in S2 you spell out that there are 3 options:

*         Legacy API - use the current TCP API. Consideration of impact of using is in scope of doc.

*         Basic API - a MPTCP API that is a simple extension to the TCP api etc. In scope of doc

*         Advanced API - a MPTCP API that is a more advanced api with more fine-grained control .... Outside scope of doc

S3.2.2 - something here should be about subflows [rather than flows]?

S4.2.1 - so mptcp is only used if app binds to INADDR_ANY?

S5.1 <<Yet, the signaling of the receiver's needs is outside of the scope of this document.>> - you could refer here the "B flag" [S3.3 of the protocol draft] - the Receiver can indicate to source whether it prefers interface to be used or only as a back-up [ie spread traffic according to congestion control algorithm vs. standby] . also, it's not outside the scope of the "document" but outside the scope of the "basic API" [it's mentioned in the advanced API appendix]

6.3 <<it is very likely that multiple addresses refer to multiple servers >> - "possible" -?

Thanks

phil

---

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 28 Oct 2010 18:53:26 +0200

Phil,

thanks a lot for the feedback. We will address all of them in the next
version. Please find some remarks inline.

Michael

> *         Advanced API - a MPTCP API that is a more advanced 
> api with more fine-grained control .... Outside scope of doc

Good point.

> S3.2.2 - something here should be about subflows [rather than flows]?

True, that is the wrong term, it should be "subflow".

> S4.2.1 - so mptcp is only used if app binds to INADDR_ANY?

This raises an interesting point that is currently not clearly
described.

My understanding is that MPTCP should not be used if an app binds to a
specific address, as the app then has a preference for that address.
This is what the text currently implies.

Yet, there seems to be an exception: If the app announces by some other
means that it actually wants to use MPTCP, or if it adds further
addresses (e. g., by the basic API), it of course makes sense to use
MPTCP. This case is not explicitly mentioned in the text, but it is also
not excluded. I'd suggest to add a sentence that clearly states that in
that case MPTCP can be used as well.

> S5.1 <<Yet, the signaling of the receiver's needs is outside 
> of the scope of this document.>> - you could refer here the 
> "B flag" [S3.3 of the protocol draft] - the Receiver can 
> indicate to source whether it prefers interface to be used or 
> only as a back-up [ie spread traffic according to congestion 
> control algorithm vs. standby] . also, it's not outside the 
> scope of the "document" but outside the scope of the "basic 
> API" [it's mentioned in the advanced API appendix]

The term "signaling" is maybe a little bit misleading here. In the
context of the API, it actully should refer to the question how an app
could sets such preferences, not to the corresponding MPTCP message.

I'd rephrase it as follow:  "A receiver may also have preferences about
data transfer choices, and it may have performance requirements, too.
Yet, the configuration of such preferences is outside
of the scope of the basic API."

Is that better?

> multiple servers >> - "possible" -?

Yes, probably this is a better term here.