1 / 6

MPTCP Protocol – Status Update draft-ietf-mptcp-multiaddressed-01

MPTCP Protocol – Status Update draft-ietf-mptcp-multiaddressed-01. Alan Ford alan.ford@roke.co.uk IETF 78 – Maastricht. What’s happened since IETF77?. draft-ford-mptcp-multiaddressed adopted as WG item Technical additions to -00 Textual changes to -01. Differences since IETF77.

estelle-genero
Download Presentation

MPTCP Protocol – Status Update draft-ietf-mptcp-multiaddressed-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 Protocol – Status Updatedraft-ietf-mptcp-multiaddressed-01 Alan Fordalan.ford@roke.co.uk IETF 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!

More Related