mptcp application considerations draft-scharf-mptcp-api-01 michael scharf alan ford ietf 77, march...

MPTCP Application Considerations

draft-scharf-mptcp-api-01

Michael Scharf <[email protected]>Alan Ford <[email protected]>

IETF 77, March 2010

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)


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


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


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


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


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


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


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


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 10msRTT 100ms

RTT 10msRTT 100ms

RTT 10msRTT 100ms

Pooling

Overflow

Hot standby

Degree of control by apps

Currently the main scope of draft


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?


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

mptcp application considerations draft-scharf-mptcp-api-01 michael scharf alan ford ietf 77, march...

Documents