Multipath TCP MPTCP Wei Wang 04192011 CISC 856

Multipath TCP (MPTCP) Wei Wang 04/19/2011 CISC 856 University of Delaware

Reference Materials • Draft-ietf-mptcp-multiaddressed-03 • Draft-ietf-mptcp-architecture-05 • Draft-ietf-mptcp-congestion-02

Motivation • Growing number of multihomed hosts – IPad and Smart Phones with 3 G + WIFI – Laptops with wired and wireless connections • When TCP encounters multihomed host – Inefficient (Throughput) – One interface, one connection (Reliability)

Possible Scenario: Mobile Client 3 G Celltower Mobile Client Server

Scenario: Mobile Client (2) Mobile Client Server Wifi

Scenario: Mobile Client (3) Server Mobile Client Wifi

Scenario: Mobile Client (4) Server Wifi Mobile Client Wifi

MPTCP in the Networking Stack Application TCP IP Application MPTCP Subflow(TCP) … Subflow(TCP) IP Standard TCP vs. MPTCP Protocol Stack

MPTCP Option 0 1 2 3 4 5 6 7 8 9 0 1 Sub- (Subtype-specific Kind Length type data---------------------------------- Variable length) Symbol Name Subtype Value MP_CAPABLE MP_JOIN Multipath Capable Join Connection Data Sequence Signal 0 x 0 0 x 1 … … DSS … 0 x 2

Example Usage Scenario Host A A 1 A 2 Host B B 1 Initial Connection Setup Additional Subflow Setup B 2

Connection Initiation • Single path B (Listener) A (Initiator) A’s Key (SYN) B’s Key (ACK+SYN) A’s Key & B’s Key (ACK)

Connection Initiation (2) • MP_CAPABLE option – 64 -bit key to authenticate the addition of future subflows – The mapping – Initial Data Sequence Number (64 -bit Connection Sub. Vertruncation of hash Kind Length of the key) C (reserved) S type sion – Used in the first subflow of a connection Sender’s Key Token (Key. A, Key. B (64 bits) ) Receiver’s Key (64 bits) (if Length == 20)

Starting a New Subflow Host A Host. B • SYN/ACK Exchange w/ MP_JOIN option A 1 A 2 B 1 SYN+MP_CAPABLE (Key-A) SYN/ACK+MP_CAPABLE(Key-B) ACK+MP_CAPABLE(Key-A, Key-B) SYN+MP_JOIN(Token-B, R-A) SYN/ACK+MP_JOIN(MAC-B, R-B) ACK+MP_JOIN(MAC-A)

Starting a New Subflow (2) • MP_JOIN option (initial SYN) – Token • Identify the MPTCP connection • Mapped to 5 -tuples after arrival • Demultiplexing using 5 -tuples upon successful subflow setup • Cryptographic hash of the receiver’s key = 12 –Kind Random Length number Subtype B Address ID • Prevent replay attacks on authentication Receiver’s Token (32 bits) Sender’s Random Number (32 bits)

Starting a New Subflow (3) • MP_JOIN option (responding SYN + ACK) – MAC(Key, Msg) • Key from initial handshake, Msg from Random Numbers • MAC-B = MAC (Key=(Key-B+Key-A), Msg=(R-B+RA)) Kind Length = 12 Subtype B Address ID Sender’s Truncated MAC (64 bits) Sender’s Random Number (32 bits)

Starting a New Subflow (4) • MP_JOIN option (third ACK) – MAC-A = MAC (Key=(Key-A+Key-B), Msg=(RA+R-B)) Kind Length = 12 Subtype B Sender’s MAC (160 bits SHA-1)

Sequence Numbers • PDUs go multiple paths – Need sequence numbers to put them back in sequence – Need sequence numbers to infer loss on a single path • Options – One sequence space shared across all paths? – One sequence space per path, plus an extra one to put data back in the correct order at the receiver?

Single Sequence Space • Stripe the data sequence numbers across subflows • Use data cumulative ack ACK: 1, 3, 5 5 3 1 1 2 3 4 5 6 6 4 2 ACK: 2, 4, 6

Lost PDU • Problem – Cannot tell which subflows lost data ACK: 1, 1, 1 5 3 1 1 1 2 3 4 5 6 6 4 2 ACK: 1, 1, 1 3 4 5 6

Multiple Sequence Spaces • Each subflow has its own sequence number space • Data sequence numbers are mapped on the subflow that sends them (DSN) • Use cumulative ack on each subflow for simplicity

(Explicit) Data Sequence Mapping ACK: 1, 2, 3 3, 5 2, 3 1, 1 1 2 3 4 5 6 3, 6 2, 4 1, 2 ACK: 1, 2, 3 Subflow sequence number Data sequence number

Lost PDU ACK: 1, 1, 1 3, 5 2, 3 1, 1 1 2 33 44 55 66 1 2 3 4 5 6 4, 1 3, 6 2, 4 1, 2 ACK: 1, 2, 33, 4 Subflow sequence number Data sequence number

Data ACK • Rationale – Deadlock conditions: acked at subflow level but failed to reach application – Freedom to drop segments at subflow level – Left edge of the advertised receive window • Shared by all subflows • Relative to Data ACK

Closing a Connection • FIN in MPTCP only affects the 80, subflow on A segment with DSN and which it is length sent 11, with DATA FIN set, would be acked with a DATA • DATA FIN ACK of 91. – Decoupled from subflow FIN – Included in the Data-level Length, not at subflow level – Once acked, remaining subflows close w/ standard FIN exchanges • Connection closed after both host’s DATA FIN acked

Acknowledgement • Multipath TCP Implementors Workshop, Maastricht et al • Work in progress (MPTCP), Mark Handley et al • Designing a Multipath Transport Protocol, Costin Raiciu & Mark Handley

Backup Slides

MPTCP Terminology • • • Path Subflow MPTCP Connection Data-level (Connection-level) Token Host

Summary of Goals • • • Improve throughput Be “fair” Improve resilience Application compatibility Network compatibility Fallback to regular TCP

Summary of Design Decisions • Improve throughput & Be “fair” – Congestion control: coupled increases algorithm • Improve resilience – Either end can add paths – Re-transmit on any path • Application compatibility – TCP API – no mods to apps – Modify TCP stack • Network compatibility – Subflows look like regular TCP – Connection & subflow sequence spaces, acks… – Signal “MPTCP capable” with TCP option on SYN • Fallback to regular TCP

Graceful Degradation (Fallback) • Connection Initiation – Page 13