1. MPTCP Application Considerations draft-scharf-mptcp-api-01 Michael Scharf Alan Ford IETF 77, March 2010

2. 2 | draft-scharf-mptcp-api-01 | 2010 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. 3 | draft-scharf-mptcp-api-01 | 2010 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. 4 | draft-scharf-mptcp-api-01 | 2010 Operation of MPTCP with Legacy Applications Selected 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. 5 | draft-scharf-mptcp-api-01 | 2010 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. 6 | draft-scharf-mptcp-api-01 | 2010 Operation of MPTCP with Legacy Applications Selected 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 applications choice Preferences could be expressed by the extended sockets API No fundamental changes

7. 7 | draft-scharf-mptcp-api-01 | 2010 Operation of MPTCP with MPTCP-aware Applications Minimal 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. 8 | draft-scharf-mptcp-api-01 | 2010 Operation of MPTCP with MPTCP-aware Applications Interactions 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. 9 | draft-scharf-mptcp-api-01 | 2010 Operation of MPTCP with MPTCP-aware Applications MPTCP 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. 10 | draft-scharf-mptcp-api-01 | 2010 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) - Turn on/off - Obtain information about flows - Get/set preferences - Get/set redundancy -... - Restrict MPTCP to interfaces - Set/get the application profile RTT 10ms RTT 100ms RTT 10ms RTT 100ms RTT 10ms RTT 100ms Pooling Overflow Hot standby Degree of control by apps Currently the main scope of draft

11. 11 | draft-scharf-mptcp-api-01 | 2010 Operation of MPTCP with MPTCP-aware Applications Preliminary 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. 12 | draft-scharf-mptcp-api-01 | 2010 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