1. CISC856 University of Delaware
Multipath TCP (MPTCP)
Wei Wang
04/19/2011
CISC856 University of Delaware

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

3. 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.

4. Possible Scenario: Mobile Client
3G Celltower
Mobile Client
Server

5. Scenario: Mobile Client (2)
Server
Wifi
Wifi

6. Scenario: Mobile Client (3)
Server
Wifi

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

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

9. MPTCP Option Kind Length Sub-type1 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 …

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

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

12. 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)

13. 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

14. 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)

15. 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)

16. 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)

17. 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?

18. 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

19. 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

20. 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

21. (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

22. 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

23. 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

24. 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.

25. 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

26. Backup Slides

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

28. 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

29. 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

30. Graceful Degradation (Fallback)
Connection Initiation
Page 13