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

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