1 / 12

MPTCP Application Considerations draft-scharf-mptcp-api-01

MPTCP Application Considerations draft-scharf-mptcp-api-01. Michael Scharf <michael.scharf@alcatel-lucent.com> Alan Ford <alan.ford@roke.co.uk> IETF 77, March 2010. Overview and Scope of draft-scharf-mptcp-api-01. Comparison of MPTCP and regular TCP

cicada
Download Presentation

MPTCP Application Considerations draft-scharf-mptcp-api-01

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 Application Considerationsdraft-scharf-mptcp-api-01 Michael Scharf <michael.scharf@alcatel-lucent.com>Alan Ford <alan.ford@roke.co.uk> IETF 77, March 2010

  2. Overview and Scope of draft-scharf-mptcp-api-01 • Comparison of MPTCP and regular TCP • Performance impact (throughput, delay, resilience) • Potential problems (middleboxes, outdated assumptions, security) • Tutorial-style description of MPTCP • Operation of MPTCP with legacy applications • Usage of addresses inside applications • Usage of existing socket options (such as TCP_NODELAY) • Default enabling • Important implications for legacy applications • Operation of MPTCP with MPTCP-aware applications • Minimal API Enhancements • Extended MPTCP API • Current focus mainly on minimal enhancements New in version -01: • Clear distinction of both cases • Indication of MPTCP-awareness by TCP_MP_ENABLE socket option (or by AF_MULTIPATH)

  3. Comparison of MPTCP and Regular TCP Tutorial-style Description • Performance improvement • Potentially higher throughput (reference to draft-raiciu-mptcp-congestion) • Delay jitter may increase • Better resilience • Potential problems • Middleboxes • Outdated assumptions about one-to-one mapping of socket to connection/addresses • Security issues (reference to draft-ietf-mptcp-threat) • Only minor updates compared to version -00

  4. Operation of MPTCP with Legacy ApplicationsSelected Issue: Default Enabling of MPTCP New statement concerning enabling for legacy applications: • It is up to a local policy whether MPTCP should enabled by default • May be under the control of the user through system preferences • Decision is up to the user, system administrator, or OS vendor

  5. Operation of MPTCP with Legacy Applications Selected Issue: Address Exposed to Applications • Discussed in Hiroshima and in the interim phone conference • Draft now states that address of first subflow MUST be returned for legacy applications • Even if first subflow is no longer in use • Stack MAY close whole MPTCP connection if first subflow is closed • The latter decision SHOULD be controlled by a local policy • Backward compatible by default

  6. Operation of MPTCP with Legacy ApplicationsSelected Issue: Usage of Existing Socket Options with MPTCP • Disabling the Nagle algorithm (TCP_NODELAY option) • Can be used with MTCP as usually and affects all subflows • Open question: Activation of a different path scheduler algorithm? • Send and receive buffers (SO_SNDBUF/SO_RCVBUF options) • Affects MPTCP connection buffers • MPTCP might not be enabled if buffers are manually set to a small size • Usage of a specific address by app (binding or SO_BINDTODEVICE option) • MPTCP respects the application’s choice • Preferences could be expressed by the extended sockets API • No fundamental changes

  7. Operation of MPTCP with MPTCP-aware ApplicationsMinimal API Enhancements • API for MPTCP-aware applications can be different from legacy applications • MPTCP awareness can be detected by a TCP_MP_ENABLE socket option • Or, e. g., by AF_MULTIPATH usage • Minimal API enhancement: Modify getpeername() and getsockname() • Text currently suggest that both functions SHOULD fail with a new error code (EMULTIPATH) • Still an open issue whether this is the best thing to do • If AF_MULTIPATH is used, different solutions are possible • For instance, functions could return AF_MULTIPATH structures... but this would not provide information about the address pairs of the subflows • Extended MPTCP API could include new functions, e. g., a getmppeer() function that takes a single address and returns an AF_MULTIPATH structure of all peer addresses

  8. Operation of MPTCP with MPTCP-aware ApplicationsInteractions and Incompatibilities with other Multihoming Solutions • MPTCP features, as well as the API, overlap with other multihoming solutions • Potential conflicts with SHIM and HIP API • draft-ietf-shim6-multihome-shim-api-13 notes that APIs may not be compatible • Current statement: In order to avoid any conflict, multiaddressed MPTCP SHOULD not be enabled if a network stack uses SHIM6 or HIP • Combinations of MPTCP and SHIM6/HIP are outside the scope of the document

  9. Operation of MPTCP with MPTCP-aware ApplicationsMPTCP Extended API • API for MPTCP-aware applications is not necessarily 100% backward compatible... but, of course, it should be as far as possible +-------------------------------+ | MPTCP-aware Application | +-------------------------------+ ^ |~~~~~~~~~~~|~~Extended API~~~|~~~~~~~~~~~ | v +-------------------------------+ | MPTCP | + - - - - - - - + - - - - - - - + | Subflow (TCP) | Subflow (TCP) | +-------------------------------+ | IP | IP | +-------------------------------+ • Objectives of the extended API • Provide the same level of control and information access over a MPTCP connection that an application can have over a regular TCP connection • Focus is the minimum set of API functions

  10. Operation of MPTCP with MPTCP-aware Applications Key Design Aspects of the API • Question: Features and expressiveness of the API? • Question: Is there a need for different application profiles?Examples: • Default: Bulk data transport • Latency-sensitive transport(with overflow) • Latency-sensitive transport(hot-standby) Degree of control by apps - Turn on/off- Obtain information about flows - Restrict MPTCP to interfaces- Set/get the application profile - Get/set preferences- Get/set redundancy- ... Currently the main scope of draft RTT 10ms Pooling RTT 100ms RTT 10ms Overflow RTT 100ms RTT 10ms Hot standby RTT 100ms

  11. Operation of MPTCP with MPTCP-aware ApplicationsPreliminary List of Requirements • Minimum functions to provide a service analogous to the one of regular TCP • REQ1: Turn on/off MPTCP • REQ2: Restrict MPTCP to binding to a given set of addresses or interfaces • REQ3: Know if multiple subflows are in use • REQ4: Obtain information about the subflows (addresses, usage, etc.) • REQ5: Extract a unique identifier for the connection • REQ6: Set/get the application profile • Further API functions possible if applications needs more explicit control • Comments?

  12. Summary and Next Steps • Main changes compared to version -00 • Distinction between legacy and MPTCP-aware applications • Guidance concerning default enabling and shutdown of the first sub-flow • Clearer structure of document and additional references to related work • Open questions concerning API design • What control functions make sense for an app? • What information from an app would be beneficial for MPTCP? • What aspects could be implicitly determined? • Next step: Discussion of API needed • One key aspect of the overall architecture! • Draft currently lists requirements as a starting point • Any feedback would be welcome

More Related