Subject: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.txt

From: [email-masked]
Date: Mon, 14 Mar 2011 05:00:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multipath TCP Working Group of the IETF.

	Title           : MPTCP Application Interface Considerations
	Author(s)       : M. Scharf, A. Ford
	Filename        : draft-ietf-mptcp-api-01.txt
	Pages           : 27
	Date            : 2011-03-14

Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session.  Even though it is designed to be totally
backward compatible to applications, the data transport differs
compared to regular TCP, and there are several additional degrees of
freedom that applications may wish to exploit.  This document
summarizes the impact that MPTCP may have on applications, such as
changes in performance.  Furthermore, it discusses compatibility
issues of MPTCP in combination with non-MPTCP-aware applications.
Finally, the document describes a basic application interface for
MPTCP-aware applications that provides access to multipath address
information and a level of control equivalent to regular TCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 30 Mar 2011 13:04:20 +0200

Dear all,

I read the ID and have the following comments:

* I'm not sure why you need REQ4. In SCTP we do have this for
  1-to-many style sockets, but I do not see that you use this
  for MPTCP. On 1-to-1 style sockets, it is not needed for
  SCTP at least.

* Section 5.3.1: Why can't you use TCP_MUTLIPATH_REMOVE only after connection setup?

* Table 1: What is a "list of addresses"?

* Table 1: What is a "list of pairs of addresses"?

* Section 5.3.5: Why is TCP_MULTIPATH_CONNID needed?

* Section 6.1: Are you suggesting that sctp_bindx(), sctp_connectx(),
  sctp_getladdrs(), sctp_getpaddrs() are also provided for MPTCP?
  This sounds strange.
  Maybe one can introduce bindx(), connectx(), getladdrs(), getpaddrs()
  which supports SCTP and MPTCP. Kacheong suggested that a while ago.
  Maybe it is time to do that.
  Please note that you missed sctp_freeladdrs() and sctp_freepaddrs().

Best regards
Michael
On Mar 14, 2011, at 1:00 PM, [email-masked] wrote:

> <Mail Attachment>_______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 30 Mar 2011 12:27:43 +0100

Hi Michael,

Many thanks for your review. Comments inline...

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of Michael Tüxen
> Sent: 30 March 2011 12:04
> To: mptcp
> Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-api-01.txt
> 
> Dear all,
> 

The logic for REQ4 (connection ID) is explained in the text below that list:

   Finally, it should be possible for the
   application to retrieve a unique connection identifier (local to the
   endpoint on which it is running) for the MPTCP connection.  This is
   equivalent to using the (address, port) pair for a connection 
   identifier in single-path TCP, which is no longer static in MPTCP.

Since there is no longer a single, static (address, port) pair for a connection, we should provide a static connection ID for MPTCP-aware applications to track its connections.

> * Section 5.3.1: Why can't you use TCP_MUTLIPATH_REMOVE only after

Not sure there's much of a call for it, but I guess there's no reason to prevent its use in address list management before setting up a connection.

> * Table 1: What is a "list of addresses"?

An abstract data structure consisting of a list of IP (v4 and/or v6) addresses (and optionally ports).

Do you consider it necessary to be more explicit? The data structures are explained in more detail in the following sections.

> * Table 1: What is a "list of pairs of addresses"?

See above, but this time with pairs within the list :)

> * Section 5.3.5: Why is TCP_MULTIPATH_CONNID needed?

See my response to REQ4 above.

>   Please note that you missed sctp_freeladdrs() and sctp_freepaddrs().

I'll leave Michael to answer that one :)

Cheers,
Alan