1 / 6

MPTCP API draft-scharf-mptcp-api-03

MPTCP API draft-scharf-mptcp-api-03. Alan Ford <alan.ford@roke.co.uk> IETF79 – Beijing. Draft Overview. Differences between regular TCP and MPTCP for applications Interactions with non-MPTCP-aware applications (including address issues) i.e. behaviour of MPTCP with existing TCP API

madeline-golden
Download Presentation

MPTCP API draft-scharf-mptcp-api-03

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MPTCP APIdraft-scharf-mptcp-api-03 Alan Ford <alan.ford@roke.co.uk> IETF79 – Beijing

  2. Draft Overview • Differences between regular TCP and MPTCP for applications • Interactions with non-MPTCP-aware applications (including address issues) • i.e. behaviour of MPTCP with existing TCP API • Basic API using sockopts • Goal is to provide equivalent functionality to the TCP API for MPTCP • Extended API discussion in the appendix • Ideas to allow specific control of MPTCP behaviour

  3. Basic API • TCP_MULTIPATH_ENABLE • Enable/disable use of MPTCP • TCP_MULTIPATH_BIND • Specify local addresses to bind to • TCP_MULTIPATH_SUBFLOWS • Get address pairs in use on this MPTCP connection • TCP_MULTIPATH_CONNID • Get a unique local identifier for the connection

  4. Changes Since -02 • Specified getpeername() and getsockname() behaviour to be the same for both MPTCP-aware and non-MPTCP-aware applications • Reference to the SCTP API • Made address list management behaviour more explicit • Various editorial and terminology fixes

  5. Open Issue: Address List Management • Analogous to TCP’s bind(), but multiaddressed • Current proposal for TCP_MULTIPATH_BIND requires the full address list to bind to, both before connection establishment and for changes during the lifetime of a connection • Is it reasonable to expect an application to keep an address list itself? • The alternative would be TCP_MULTIPATH_ADD and TCP_MULTIPATH_REMOVE for use during connection lifetime

  6. Next steps? • WG has two related milestones: • Is this draft ready for WG adoption? Mar 2011 Submit to IESG an extended API for MPTCP as an or part of an experimental or informational RFC Mar 2011 Submit to IESG application considerations as an informational RFC

More Related