draft-ietf-mptcp-api-02.txt   draft-ietf-mptcp-api-03.txt 
Internet Engineering Task Force M. Scharf Internet Engineering Task Force M. Scharf
Internet-Draft Alcatel-Lucent Bell Labs Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Informational A. Ford Intended status: Informational A. Ford
Expires: December 9, 2011 Roke Manor Research Expires: June 2, 2012 November 30, 2011
June 7, 2011
MPTCP Application Interface Considerations MPTCP Application Interface Considerations
draft-ietf-mptcp-api-02 draft-ietf-mptcp-api-03
Abstract Abstract
Multipath TCP (MPTCP) adds the capability of using multiple paths to Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session. Even though it is designed to be totally a regular TCP session. Even though it is designed to be totally
backward compatible to applications, the data transport differs backward compatible to applications, the data transport differs
compared to regular TCP, and there are several additional degrees of compared to regular TCP, and there are several additional degrees of
freedom that applications may wish to exploit. This document freedom that applications may wish to exploit. This document
summarizes the impact that MPTCP may have on applications, such as summarizes the impact that MPTCP may have on applications, such as
changes in performance. Furthermore, it discusses compatibility changes in performance. Furthermore, it discusses compatibility
skipping to change at page 1, line 41 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2011. This Internet-Draft will expire on June 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 20, line 23 skipping to change at page 20, line 23
advanced MPTCP API, which is not specified in this document. advanced MPTCP API, which is not specified in this document.
10. Acknowledgments 10. Acknowledgments
Authors sincerely thank to the following people for their helpful Authors sincerely thank to the following people for their helpful
comments and reviews of the document: Costin Raiciu, Philip Eardley, comments and reviews of the document: Costin Raiciu, Philip Eardley,
Javier Ubillos, and Michael Tuexen. Javier Ubillos, and Michael Tuexen.
Michael Scharf is supported by the German-Lab project Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de/) funded by the German Federal Ministry of (http://www.german-lab.de/) funded by the German Federal Ministry of
Education and Research (BMBF). Alan Ford is supported by Trilogy Education and Research (BMBF). Alan Ford was supported by Roke Manor
(http://www.trilogy-project.org/), a research project (ICT-216372) Research and by Trilogy (http://www.trilogy-project.org/), a research
partially funded by the European Community under its Seventh project (ICT-216372) partially funded by the European Community under
Framework Program. The views expressed here are those of the its Seventh Framework Program. The views expressed here are those of
author(s) only. The European Commission is not liable for any use the author(s) only. The European Commission is not liable for any
that may be made of the information in this document. use that may be made of the information in this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[2] Braden, R., "Requirements for Internet Hosts - Communication [2] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, [4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", "Architectural Guidelines for Multipath TCP Development",
RFC 6182, March 2011. RFC 6182, March 2011.
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP [5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Extensions for Multipath Operation with Multiple Addresses", Extensions for Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-03 (work in progress), draft-ietf-mptcp-multiaddressed-04 (work in progress),
March 2011. July 2011.
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", RFC 6181, March 2011. Operation with Multiple Addresses", RFC 6181, March 2011.
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion [7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Control for Multipath Transport Protocols", Control for Multipath Transport Protocols", RFC 6356,
draft-ietf-mptcp-congestion-03 (work in progress), April 2011. October 2011.
[8] "IEEE Std. 1003.1-2008 Standard for Information Technology -- [8] "IEEE Std. 1003.1-2008 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 7, 2008.". Technical Standard: Base Specifications, Issue 7, 2008.".
11.2. Informative References 11.2. Informative References
[9] Sarolahti, P., "Multi-address Interface in the Socket API", [9] Sarolahti, P., "Multi-address Interface in the Socket API",
draft-sarolahti-mptcp-af-multipath-01 (work in progress), draft-sarolahti-mptcp-af-multipath-01 (work in progress),
March 2010. March 2010.
[10] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced [10] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6", Sockets Application Program Interface (API) for IPv6",
RFC 3542, May 2003. RFC 3542, May 2003.
[11] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for [11] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for
Mobile IPv6", RFC 4584, July 2006. Mobile IPv6", RFC 4584, July 2006.
[12] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket [12] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets
Application Program Interface (API) for Multihoming Shim", Application Program Interface (API) for Multihoming Shim",
draft-ietf-shim6-multihome-shim-api-17 (work in progress), RFC 6316, July 2011.
April 2011.
[13] Komu, M. and T. Henderson, "Basic Socket Interface Extensions [13] Komu, M. and T. Henderson, "Basic Socket Interface Extensions
for Host Identity Protocol (HIP)", draft-ietf-hip-native-api-12 for the Host Identity Protocol (HIP)", RFC 6317, July 2011.
(work in progress), January 2010.
[14] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, [14] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich,
"Sockets API Extensions for Stream Control Transmission "Sockets API Extensions for Stream Control Transmission
Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-29 (work in Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-32 (work in
progress), April 2011. progress), October 2011.
[15] Blanchet, M. and P. Seite, "Multiple Interfaces and [15] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-15 (work in progress), draft-ietf-mif-problem-statement-15 (work in progress),
May 2011. May 2011.
[16] Wasserman, M. and P. Seite, "Current Practices for Multiple [16] Wasserman, M. and P. Seite, "Current Practices for Multiple
Interface Hosts", draft-ietf-mif-current-practices-11 (work in Interface Hosts", draft-ietf-mif-current-practices-12 (work in
progress), April 2011. progress), July 2011.
[17] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards [17] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Success with Dual-Stack Hosts", Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-05 (work in
draft-ietf-v6ops-happy-eyeballs-01 (work in progress), progress), October 2011.
March 2011.
Appendix A. Requirements on a Future Advanced MPTCP API Appendix A. Requirements on a Future Advanced MPTCP API
A.1. Design Considerations A.1. Design Considerations
Multipath transport results in many degrees of freedom. The basic Multipath transport results in many degrees of freedom. The basic
MPTCP API only defines a minimum set of the API extensions for the MPTCP API only defines a minimum set of the API extensions for the
interface between the MPTCP layer and applications, which does not interface between the MPTCP layer and applications, which does not
offer much control of the MPTCP implementation's behaviour. A offer much control of the MPTCP implementation's behaviour. A
future, advanced API could address further features of MPTCP and future, advanced API could address further features of MPTCP and
skipping to change at page 26, line 25 skipping to change at page 26, line 25
o sctp_freepaddrs() o sctp_freepaddrs()
The syntax and semantics of these functions are described in [14]. The syntax and semantics of these functions are described in [14].
A potential objective for the advanced API is to provide a consistent A potential objective for the advanced API is to provide a consistent
MPTCP and SCTP interface to the application. This is left for MPTCP and SCTP interface to the application. This is left for
further study in this document. further study in this document.
Appendix B. Change History of the Document Appendix B. Change History of the Document
Changes compared to version draft-ietf-mptcp-api-02:
o Updated references
o Editorial changes
Changes compared to version draft-ietf-mptcp-api-01: Changes compared to version draft-ietf-mptcp-api-01:
o Additional text on outdated assumptions if an MPTCP application o Additional text on outdated assumptions if an MPTCP application
does not use fate sharing. does not use fate sharing.
o The appendix explicitly mentions an integration of the advanced o The appendix explicitly mentions an integration of the advanced
MPTCP API and the SCTP API as a potential objective, which is left MPTCP API and the SCTP API as a potential objective, which is left
for further study for the basic API. for further study for the basic API.
o A short additional explanation of the parameters of the abstract o A short additional explanation of the parameters of the abstract
skipping to change at page 28, line 16 skipping to change at page 28, line 22
Michael Scharf Michael Scharf
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
EMail: michael.scharf@alcatel-lucent.com EMail: michael.scharf@alcatel-lucent.com
Alan Ford Alan Ford
Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
Phone: +44 1794 833 465 EMail: alan.ford@gmail.com
EMail: alan.ford@roke.co.uk
 End of changes. 15 change blocks. 
31 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/