Transcript Symbol Name Subtype Value

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
3G Celltower
Mobile Client
Server
Scenario: Mobile Client (2)
Mobile Client
Server
Wifi
Wifi
Scenario: Mobile Client (3)
Server
Mobile Client
Wifi
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 2 3 4 5 6 7
8 9 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
0x0
0x1
DSS
Data Sequence
Signal
0x2
…
…
…
Example Usage Scenario
Host A
A1
A2
Host B
B1
Initial Connection Setup
Additional Subflow Setup
B2
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
SubVertruncation
of
hash
Kind
Length of the key)
C (reserved) S
type
sion
– Used in the first subflow of a connection
Sender’s Key
Token
(KeyA,KeyB)
(64 bits)
Receiver’s Key (64 bits)
(if Length == 20)
Starting a New Subflow
Host A
HostB
• SYN/ACK
Exchange
w/ MP_JOIN option
A1
A2
B1
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 (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
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
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
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
the80,
subflow
on
A segment
with DSN
and
length 11, with DATA FIN set,
which it is sent
would
be
acked
with
a
DATA
ACK
• DATA FIN
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