multipath quic: design and evaluation
TRANSCRIPT
Multipath QUIC: Design and Evaluation
Quentin De Coninck, Olivier [email protected]
multipath-quic.org
2
QUIC = Quick UDP Internet Connection
● TCP/TLS1.3 atop UDP● Stream multiplexing → HTTP/2 use case● 0-RTT establishment (most of the time)
IPTCPTLS
HTTP/2
IPUDP
QUIC
HTTP/2 shim
3
QUIC Packet
Connection IDFlags Packet Number Encrypted Payload...
4
QUIC Packet
Connection IDFlags Packet Number Encrypted Payload...
Cleartext Public Header
5
QUIC Packet
Connection IDFlags Packet Number Encrypted Payload...
Cleartext Public Header
Does not depend on 4-tuple
6
QUIC Packet
Connection IDFlags Packet Number Encrypted Payload...
Cleartext Public Header
Does not depend on 4-tuple
Monotonically Increasing
7
QUIC Packet
Connection IDFlags Packet Number Encrypted Payload...
Cleartext Public Header
Does not depend on 4-tuple
Monotonically Increasing Contains control/data frames
8
QUIC Data Transfer
H2H1
9
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”H2H1
10
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”H2H1
Actual data
11
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”
CIDF PN=19 ACK(25) MAX_DATA(for stream=5): 1=24
H2H1
12
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”
CIDF PN=19 ACK(25) MAX_DATA(for stream=5): 1=24
H2H1
Control Frames
13
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”
CIDF PN=19 ACK(25) MAX_DATA(for stream=5): 1=24
CIDF PN=26 STREAM(id=5,of=26):”.” STREAM(id=7,of==):”Y” ACK(19)
H2H1
14
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”
CIDF PN=19 ACK(25) MAX_DATA(for stream=5): 1=24
CIDF PN=26 STREAM(id=5,of=26):”.” STREAM(id=7,of==):”Y” ACK(19)
H2H1
Multiplexing
15
QUIC Data Transfer
CIDF PN=25 STREAM(id=5,of==):”Some data in my long frame”
CIDF PN=19 ACK(25) MAX_DATA(for stream=5): 1=24
CIDF PN=2= ACK(26)
CIDF PN=26 STREAM(id=5,of=26):”.” STREAM(id=7,of==):”Y” ACK(19)
H2H1
16
Why Multipath QUIC?
● QUIC assumes a single-path foo
17
Why Multipath QUIC?
● QUIC assumes a single-path foo
18
Why Multipath QUIC?
● QUIC assumes a single-path foo
19
Why Multipath QUIC?
● QUIC assumes a single-path foo
● Multipath QUIC– Bandwidth aggregation– Seamless network handover
● Can try new WiFi while keeping using LTE
20
Design of Multipath QUIC
● Connection is composed of a set of paths
21
Design of Multipath QUIC
● Connection is composed of a set of paths
22
Design of Multipath QUIC
● Connection is composed of a set of paths
Pkt?
Performance monitoring?Loss detection?Path congestion control?
23
Design of Multipath QUIC
● Connection is composed of a set of paths
Pkt
24
Design of Multipath QUIC
● Connection is composed of a set of paths
Connection IDFlags Packet Number Encrypted Payload...Path ID
Pkt
Explicit path identifcation
25
Design of Multipath QUIC
● Connection is composed of a set of paths
Connection IDFlags Packet Number Encrypted Payload...Path ID
Pkt
Explicit path identifcation No path handshake
26
Design of Multipath QUIC
● Connection is composed of a set of paths
Connection IDFlags Packet Number Encrypted Payload...Path ID
Pkt
Explicit path identifcation
Per-path numbering space
No path handshake
27
Multipath QUIC Data Transfer
Server via WiFi
Server via LTE
Phone
Path 1: WiFi Path 2: LTE
28
Multipath QUIC Data Transfer
Server via WiFi
Server via LTE
PhoneCIDF PN=1 STR(id=5)1
Path 1: WiFi Path 2: LTE
29
Multipath QUIC Data Transfer
Server via WiFi
Server via LTE
PhoneCIDF PN=1 STR(id=5)1
CIDF PN=1 STR(id=7,of==)1 CIDF PN=1 STR(id=7,of=1=24)2
Path 1: WiFi Path 2: LTE
30
Multipath QUIC Data Transfer
Server via WiFi
Server via LTE
PhoneCIDF PN=1 STR(id=5)1
CIDF PN=1 STR(id=7,of==)1 CIDF PN=1 STR(id=7,of=1=24)2
CIDF PN=2 ACK(pid=1,1)1 ACK(pid=2,1)
Path 1: WiFi Path 2: LTE
31
Multipath QUIC Data Transfer
Server via WiFi
Server via LTE
PhoneCIDF PN=1 STR(id=5)1
CIDF PN=1 STR(id=7,of==)1 CIDF PN=1 STR(id=7,of=1=24)2
CIDF PN=2 ACK(pid=1,1)1 ACK(pid=2,1)
Path 1: WiFi Path 2: LTE
Multiple paths ackedon a single path
32
Multipath Mechanisms
● Path management IP1
IP2
IP3
IP4
33
Multipath Mechanisms
● Path management IP1
IP2
IP3
IP4
34
Multipath Mechanisms
● Path management
● Packet scheduling
IP1
IP2
IP3
IP4
10 ms RTT
2= ms RTT
35
Multipath Mechanisms
● Path management
● Packet scheduling
IP1
IP2
IP3
IP4
10 ms RTT
2= ms RTT
36
Multipath Mechanisms
● Path management
● Packet scheduling
IP1
IP2
IP3
IP4
10 ms RTT
2= ms RTT 2= ms RTT
?
37
Multipath Mechanisms
● Path management
● Packet scheduling
IP1
IP2
IP3
IP4
10 ms RTT
2= ms RTT 2= ms RTT
?Duplicate
38
Multipath Mechanisms
● Path management
● Packet scheduling
● Congestion control– Opportunistic Linked Increase Algorithm
IP1
IP2
IP3
IP4
10 ms RTT
2= ms RTT 2= ms RTT
?Duplicate
39
Evaluation of Multipath QUIC
● (Multipath) QUIC vs. (Multipath) TCP– Multipath QUIC: quic-go– Linux Multipath TCP v=.91 with default settings
● Mininet environment oith 2 paths
40
Evaluating Bandoith Aggregation
● Doonload of 20 MB fle– Over a single stream– Collect the transfer time
41
Evaluating Bandoith Aggregation
● Doonload of 20 MB fle– Over a single stream– Collect the transfer time
● For a loss-free scenario
2=ms RTT, 2= Mbps
4=ms RTT, 15 Mbps
42
Evaluating Bandoith Aggregation
● Doonload of 20 MB fle– Over a single stream– Collect the transfer time
● For a loss-free scenario– MPQUIC has 13% speedup compared to MPTCP
2=ms RTT, 2= Mbps
4=ms RTT, 15 Mbps
43
Evaluating Bandoith Aggregation
● Doonload of 20 MB fle– Over a single stream– Collect the transfer time
● For a loss-free scenario– MPQUIC has 13% speedup compared to MPTCP
● But ohat about other topologies?
2=ms RTT, 2= Mbps
4=ms RTT, 15 Mbps
44
Evaluating Bandoidth Aggregation
● Experimental design, WSP algorithm● 2x253 netoork scenarios
– Vary the initial path● Median over 15 runs
Factor Minimum Maximum
Capacity [Mbps] 0.1 100
Round-Trip-Time [ms] 0 50
Queuing Delay [ms] 0 100
Random Loss [%] 0 2.5
45
Large File Doonload – No Loss
QUIC betterTCP better
46
Large File Doonload – No Loss
QUIC betterTCP better
Single-path
47
Large File Doonload – No Loss
48
Large File Doonload – No Loss
MPQUIC better in 85% of cases
49
Large File Doonload – No Loss
MPQUIC better in 85% of cases
Our extracted scenario
50
Large File Doonload – No Loss
MPQUIC better in 85% of cases
Our extracted scenario
Path 1: 49.4 ms RTT, 18.9= Mbps, 82 ms queing delayPath 2: 1=.6 ms RTT, =.43 Mbps, 11 ms queuing delay
Path 1: 27.2 ms RTT, =.14 Mbps, 34 ms queuing delayPath 2: 46.4 ms RTT, 49.72 Mbps, 47 ms queuing delay
51
Large File Doonload – Losses
52
Large File Doonload – Losses
QUIC copes better with
losses
53
Additional Results (see paper)
● QUIC benefts more of Multipath than TCP● Bandoidth aggregation in high BDP
– MPQUIC still better performs than MPTCP● Short fle transfers
– (MP)QUIC better thanks to its low latency handshake● Netoork handover
– MPQUIC can be very efcient– New frame to communicate path state
54
Conclusion
● Multipath should be part of any transport protocol– Most devices are multihomed
● Designed and implemented Multipath QUIC– Source code + artifacts + IETF draft available– See multipath-quic.org
● Multipath more promising oith QUIC than TCP
55
What’s Next?
● Perform tests in actual netoorks– Does (MP)QUIC work in your networks?– Does MPQUIC provides better performances?– Application running on iOS11
● https://itunes.apple.com/fr/app/quictester/id1322=19644?mt=8
– Feel free to provide feedback :-)
QUICTester
56
Thanks!
multipath-quic.org