multipath quic: design and evaluation

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


Cleartext Public Header

5

QUIC Packet



Does not depend on 4-tuple

6

QUIC Packet




Monotonically Increasing

7

QUIC Packet




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



H2H1

Control Frames

13

QUIC Data Transfer



CIDF PN=26 STREAM(id=5,of=26):”.” STREAM(id=7,of==):”Y” ACK(19)

H2H1

14

QUIC Data Transfer




H2H1

Multiplexing

15

QUIC Data Transfer



CIDF PN=2= ACK(26)


H2H1

16

Why Multipath QUIC?

● QUIC assumes a single-path foo

17

Why Multipath QUIC?


18

Why Multipath QUIC?


19

Why Multipath QUIC?


● 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



22



Pkt?

Performance monitoring?Loss detection?Path congestion control?

23



Pkt

24



Connection IDFlags Packet Number Encrypted Payload...Path ID

Pkt

Explicit path identifcation

25




Pkt

Explicit path identifcation No path handshake

26




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


Server via WiFi

Server via LTE

PhoneCIDF PN=1 STR(id=5)1


29


Server via WiFi

Server via LTE


CIDF PN=1 STR(id=7,of==)1 CIDF PN=1 STR(id=7,of=1=24)2


30


Server via WiFi

Server via LTE



CIDF PN=2 ACK(pid=1,1)1 ACK(pid=2,1)


31


Server via WiFi

Server via LTE



CIDF PN=2 ACK(pid=1,1)1 ACK(pid=2,1)


Multiple paths ackedon a single path

32

Multipath Mechanisms

● Path management IP1

IP2

IP3

IP4

33


● Path management IP1

IP2

IP3

IP4

34


● Path management

● Packet scheduling

IP1

IP2

IP3

IP4

10 ms RTT

2= ms RTT

35


● Path management


IP1

IP2

IP3

IP4

10 ms RTT

2= ms RTT

36


● Path management


IP1

IP2

IP3

IP4

10 ms RTT

2= ms RTT 2= ms RTT

?

37


● Path management


IP1

IP2

IP3

IP4

10 ms RTT

2= ms RTT 2= ms RTT

?Duplicate

38


● Path management


● 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



● For a loss-free scenario

2=ms RTT, 2= Mbps

4=ms RTT, 15 Mbps

42



● For a loss-free scenario– MPQUIC has 13% speedup compared to MPTCP

2=ms RTT, 2= Mbps

4=ms RTT, 15 Mbps

43



● 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


QUIC betterTCP better

Single-path

47


48


MPQUIC better in 85% of cases

49



Our extracted scenario

50



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

multipath quic: design and evaluation

Documents