CISC856 University of Delaware Multipath TCP (MPTCP) Wei Wang 04/19/2011 CISC856 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 3G + WIFI Laptops with wired and wireless connections When TCP encounters multihomed host Inefficient (Throughput) One interface, one connection (Reliability) Note: When I connect to wired network, I usually disconnect wireless connection.

Possible Scenario: Mobile Client 3G Celltower Mobile Client Server

Scenario: Mobile Client (2) Server Wifi Wifi

Scenario: Mobile Client (3) Server Wifi

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

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

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

Example Usage Scenario Host A Host B A1 A2 B1 B2 Initial Connection Setup Additional Subflow Setup

Connection Initiation Single path A (Initiator) B (Listener) 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 truncation of hash of the key) Used in the first subflow of a connection Connection Token (KeyA,KeyB) Kind Length Sub-type Ver-sion C (reserved) S Sender’s Key (64 bits) Receiver’s Key (64 bits) (if Length == 20)

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

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 Random number Prevent replay attacks on authentication Kind Length = 12 Subtype B Address ID 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+R-A)) Kind Length = 12 Sub-type B Address ID Sender’s Truncated MAC (64bits) 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=(R-A+R-B)) Kind Length = 12 Sub-type B Sender’s MAC (160 bits SHA-1)

Sequence Numbers PDUs go multiple paths Options 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 1 2 3 4 5 6 6 4 2 ACK: 2, 4, 6

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

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 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 3 4 5 6 1 2 3 4 5 6 2 3 4 5 6 4,1 3,6 2,4 1,2 ACK: 1, 2, 3 ACK: 1, 2, 3, 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 subflow on which it is sent DATA FIN 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 A segment with DSN 80, and length 11, with DATA FIN set, would be acked with a DATA ACK of 91.

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 Improve throughput Better than regular TCP on best path Be “fair” To regular TCP at shared bottlenecks Paths may not be disjoint Improve resilience Use multiple paths interchangeably Paths may disappear Assume identify paths by IP addresses Application compatibility Same API as regular TCP Network compatibility Work on current Internet Traverse predominant middleboxes 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