Multipath TCP (MPTCP) Wei Wang 04/19/2011 CISC856 University of Delaware.
-
Upload
katherine-burns -
Category
Documents
-
view
217 -
download
1
Transcript of Multipath TCP (MPTCP) Wei Wang 04/19/2011 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)
Possible Scenario: Mobile Client
Mobile Client
3G Celltower
Server
Scenario: Mobile Client (2)
Mobile ClientServer
Wifi
Wifi
Scenario: Mobile Client (3)
Mobile ClientServer
Wifi
Wifi
Scenario: Mobile Client (4)
Mobile Client
Server
Wifi
Wifi
MPTCP in the Networking Stack
Standard TCP vs. MPTCP Protocol Stack
Application
TCP
IP
Application
MPTCPSubflow(TCP) … Subflow(TCP)
IP
MPTCP Option
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Kind LengthSub-type
(Subtype-specific data--------------------
------------------------------------------------- Variable length)
Symbol Name Subtype Value
MP_CAPABLE Multipath Capable 0x0
MP_JOIN Join Connection 0x1
DSSData Sequence Signal
0x2
… … …
Example Usage Scenario
Host A Host BA1 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
Kind LengthSub-type
Ver-sion
C (reserved) S
Sender’s Key(64 bits)
Receiver’s Key (64 bits)(if Length == 20)
Connection
Token (KeyA,KeyB)
Starting a New Subflow
• SYN/ACK Exchange w/ MP_JOIN optionHost A HostB
A1 A2 B1
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)
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 = 12Sub-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 = 12Sub-type
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
1 2 3 4 5 6 1 2 3 4 5 6
5 3 1
6 4 2
ACK: 1, 3, 5
ACK: 2, 4, 6
Lost PDU
• Problem– Cannot tell which subflows lost data
1 2 3 4 5 6 1 3 4 5 6
5 3 1
6 4 2
ACK: 1, 1, 1
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
1 2 3 4 5 6 1 2 3 4 5 6
3,5 2,3 1,1
3,6 2,4 1,2
ACK: 1, 2, 3
ACK: 1, 2, 3
Subflow sequence number
Data sequence number
Lost PDU
4,1
1 2 3 4 5 6 1 2 3 4 5 6
3,5 2,3 1,1
3,6 2,4 1,2
ACK: 1, 1, 1
ACK: 1, 2, 3, 4
Subflow sequence number
Data sequence number
2 3 4 5 6
ACK: 1, 2, 3
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
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