MPTCP Protocol – Status Updatedraft-ietf-mptcp-multiaddressed-01

Alan Fordalan.ford@roke.co.ukIETF 78 – Maastricht

2

What’s happened since IETF77?

• draft-ford-mptcp-multiaddressed adopted as WG item

• Technical additions to -00• Textual changes to -01

3

Differences since IETF77

• Editorial changes:– Terminology moved later– Address signalling moved later– Heuristics begun to be separated– Options given more sensible names

• Explicitly stated fallback at handshake• Clarifications of window/DATA_ACK algorithms• Clarified separation of subflow- and connection-

level processing (also for buffer management)

4

Differences since IETF77 (2)

• Add Port to ADD_ADDR• Path liveness check in REM_ADDR• Checksum in DSN_MAP, leading to…• Mid-connection fallback mechanism:– Closing affected subflows– If there is only one subflow, it is possible to fall-

back without restarting• Middlebox discussion improved

5

Detecting Content-Changing Middleboxes

• Identified as a major issue at IETF77• We don’t want to prevent such boxes– Allowing e.g. address translation is not directly a problem

for MPTCP– The problem is with losing DSN_MAP sync

• So, checksumming allows detection of changes to the content of DSN_MAP content

• But is this the best way?– It’s relatively expensive, rarely needed, and potentially

difficult for offload engines• Open to other ideas– Hot off the press: copy last payload byte(s) to DSN_MAP?

6

What now?

• Open issues: – Subflow policy– Handshake security – hash chains?– Middlebox compatibility

• Making some components optional?– A lightweight subset of features for specialised,

controlled use cases, e.g. data centres

• Reviews please!