A Performance Perspective on Web Optimized Protocol Stacks: - - PowerPoint PPT Presentation

▶
a performance perspective on web optimized protocol
SMART_READER_LITE
LIVE PREVIEW

A Performance Perspective on Web Optimized Protocol Stacks: - - PowerPoint PPT Presentation

Jun 04, 2023 26 likes •234 views

A Performance Perspective on Web Optimized Protocol Stacks: TCP+TLS+HTTP/2 vs. QUIC Konrad Wolsing, Jan Rth, Klaus Wehrle, Oliver Hohlfeld https://comsys.rwth-aachen.de/ Aachen, 2019-07-22 Evolution of Web-stacks Multiplexing 2 0-RTT

slide-1
SLIDE 1

A Performance Perspective on Web Optimized Protocol Stacks: TCP+TLS+HTTP/2 vs. QUIC

Konrad Wolsing, Jan Rüth, Klaus Wehrle, Oliver Hohlfeld

https://comsys.rwth-aachen.de/ Aachen, 2019-07-22

slide-2
SLIDE 2

Evolution of Web-stacks

H2 over gQUIC

gQUIC UDP HTTP/2 TLS TCP IP Internet

Congestion Control Loss Recovery Encryption Multiplexing Congestion Control Loss Recovery Encryption Multiplexing

Evolvability over time (no ossifjcation) No head-of-line blocking 0-RTT connection establishment

2

Konrad Wolsing

slide-3
SLIDE 3

Related Work (QUIC vs. TCP)

3

Konrad Wolsing

slide-4
SLIDE 4

Related Work (QUIC vs. TCP)

  • Unoptimized TCP stacks

◮ QUIC is optimized for web performance ◮ TCP can be tuned too ◮ Related work does not tune TCP

  • Connection establishment

◮ QUIC requires 0–1 RTT ◮ TCP+TLS usually 2 RTT

  • User-centered metrics

◮ research focuses on PLT ◮ PLT is not suited for user perception

Our Goal Reproducible, user-centered performance evaluation on eye-to-eye level between TCP+TLS+HTTP/2 and QUIC.

4

Konrad Wolsing

slide-5
SLIDE 5

Achieving comparability

  • TCP + TLS + HTTP

Initial window 32 Packet pacing 1-RTT handshake Use TLS1.3 without 0-RTT Use only HTTP/2 Head-of-line blocking

  • QUIC

Initial window 32 Packet pacing no 0-RTT connection setup No encryption overhead HTTP/2 No head-of-line blocking

  • Protocol settings

TCP Stock TCP (Linux 4.18): IW10, Cubic TCP+ IW 32, Pacing, tuned network bufgers, no slow start after idle, Cubic TCP+BBR TCP+, but with BBR as congestion control QUIC Google QUIC Version 43: IW32, Pacing, Cubic QUIC+BBR QUIC, but with BBR as congestion control 5

Konrad Wolsing

slide-6
SLIDE 6

Testbed

MahiMahi

6.3.24.5 9.3.4.12 2.3.31.2 4.7.6.23

Delay Bandwidth Loss

DNS statistics

  • Server speed test

100 200 300 400 500

Download time [ms]

NGINX 2B QUIC 2B NGINX 10KB QUIC 10KB NGINX 1MB QUIC 1MB NGINX 10MB QUIC 10MB

  • Network confjguration

DSL[2] LTE[2] 3G[1] DA2GC[7] MSS[7] Uplink 5 Mbps 2.8 Mbps 3.54 Mbps .468Mbps 1.89Mbps Downlink 25 Mbps 10.5 Mbps 3.54 Mbps .468Mbps 1.89Mbps RTT 24ms 74ms 94ms 262ms 761ms Loss 0.0% 0.0% .048% 3.3% 6.0% Queue size 12ms 200ms 200ms 200ms 200ms

6

Konrad Wolsing

slide-7
SLIDE 7

Measurement

  • Replayed Websites

telegraph.com wikipedia.org gnu.org wordpress.com phpbb.com w3.org ed.gov gravatar.com

  • pera.com

google.com gov.uk statcounter.com apache.org msn.com joomla.com spotify.com sciencedirect.com bit.ly imgur.com dotdash.com etsy.com researchgate.net nature.com academia.edu imdb.com pinterest.com youtube.com intel.com demorgen.be harvard.edu facebook.com reddit.com sciencemag.org canvas.be github.com columbia.edu vtm.be nytimes.com

2 4 6

Size [MB]

10 20 30

IPs [#]

◮ 38 websites [8] from Alexa and Moz lists

  • Visual Metrics

FVC SI VC85 PLT LVC

1 2 3 4 5 6

Time in s

100

Visual Completeness in % FVC SI VC85 PLT LVC

◮ Only PLT not above-the-fold

performance gainTCP

QUIC = XQUIC − XTCP

XTCP 0.5sQUIC − 0.75sTCP 0.75sTCP = -0.333

7

Konrad Wolsing

slide-8
SLIDE 8

Performance gain DSL

−0.5 0.0 0.0 0.5 1.0

CDF FVC

−0.5 0.0

SI

−0.5 0.0

VC85

−0.5 0.0

LVC

−0.5 0.0

PLT

Network DSL

(Downlink 25Mbps, Uplink 5 Mbps, RTT 24ms, Loss 0.0%, [2])

  • Tuning ⇒ increased performance
  • QUIC outperforms even tuned TCP
  • Steep curves: website size/structure has low impact

8

Konrad Wolsing

slide-9
SLIDE 9

Performance gain LTE

−0.5 0.0 0.0 0.5 1.0

CDF FVC

−0.5 0.0

SI

−0.5 0.0

VC85

−0.5 0.0

LVC

−0.5 0.0

PLT

Network LTE

(Downlink 10.5Mbps, Uplink 2.8 Mbps, RTT 74ms, Loss 0.0%, [2])

  • Results similar to DSL
  • But difgerences are slightly larger

9

Konrad Wolsing

slide-10
SLIDE 10

Performance gain 3G

−0.5 0.0 0.0 0.5 1.0

CDF FVC

−0.5 0.0

SI

−0.5 0.0

VC85

−0.5 0.0

LVC

−0.5 0.0

PLT

Network 3G

(Downlink 3.54Mbps, Uplink 3.54 Mbps, RTT 94ms, Loss .048%, [1])

  • Tuning impact reduced
  • Variability rises

10

Konrad Wolsing

slide-11
SLIDE 11

Performance gain DA2GC

−0.5 0.0 0.0 0.5 1.0

CDF FVC

−0.5 0.0

SI

−0.5 0.0

VC85

−0.5 0.0

LVC

−0.5 0.0

PLT

Network DA2GC

(Downlink .468Mbps, Uplink .468 Mbps, RTT 262ms, Loss 3.3%, [7])

  • Tuning becomes a coin toss
  • QUIC performs still good

◮ No head-of-line blocking ◮ Larger SACK ranges 11

Konrad Wolsing

slide-12
SLIDE 12

Performance gain MSS

−0.5 0.0 0.0 0.5 1.0

CDF FVC

−0.5 0.0

SI

−0.5 0.0

VC85

−0.5 0.0

LVC

−0.5 0.0

PLT

Network MSS

(Downlink 1.89Mbps, Uplink 1.89 Mbps, RTT 761ms, Loss 6.0%, [7])

  • Congestion control impacts performance
  • BBR outperforms CUBIC
  • QUIC with CUBIC still faster than TCP with CUBIC

12

Konrad Wolsing

slide-13
SLIDE 13

Mean Performance Gain

13

Konrad Wolsing

slide-14
SLIDE 14

Infmuence of Resources

−5

difference [s]

telegraph.com wikipedia.org google.com gnu.org wordpress.com bit.ly sciencedirect.com gov.uk

  • pera.com

joomla.com apache.org w3.org pinterest.com dotdash.com gravatar.com ed.gov imgur.com spotify.com statcounter.com phpbb.com etsy.com intel.com github.com harvard.edu nature.com facebook.com academia.edu youtube.com researchgate.net msn.com columbia.edu imdb.com nytimes.com canvas.be reddit.com vtm.be sciencemag.org demorgen.be

3G (QUIC - TCP+)

FVC SI VC85 −25 25 50

difference [s] DA2GC (QUIC+BBR - TCP+BBR)

−10 10

difference [s] MSS (QUIC+BBR - TCP+BBR)

14

Konrad Wolsing

slide-15
SLIDE 15

Discussing Metrics

15

Konrad Wolsing

slide-16
SLIDE 16

Subtracting Design Difgerences wikipedia.org gnu.org statcounter.com etsy.com w3.org phpbb.com telegraph.com gov.uk facebook.com nature.com github.com google.com msn.com columbia.edu ed.gov apache.org bit.ly joomla.com wordpress.com gravatar.com imdb.com reddit.com pinterest.com youtube.com researchgate.net

  • pera.com

sciencedirect.com harvard.edu imgur.com dotdash.com intel.com vtm.be academia.edu canvas.be spotify.com sciencemag.org demorgen.be nytimes.com 20 # of ips

16

Konrad Wolsing

slide-17
SLIDE 17

Subtracting Design Difgerences

Mean difgerence under PLT with one subtracted RTT QUIC − (TCP+ − 1 · RTT)

Net Website [ms] [RTT] DSL gnu.org 1.6 0.066 DSL wikipedia.org

  • 3.1
  • 0.128

LTE gnu.org

  • 30
  • 0.412

LTE wikipedia.org

  • 13
  • 0.175

3G gnu.org

  • 32
  • 0.344

3G wikipedia.org

  • 54
  • 0.570

DA2GC gnu.org 39 0.150 DA2GC wikipedia.org

  • 1005
  • 3.834

Net Website [ms] [RTT] MSS gnu.org

  • 1100
  • 1.447

MSS wikipedia.org

  • 529
  • 0.696

Congestion Control: BBR Net Website [ms] [RTT] MSS gnu.org

  • 477
  • 0.628

MSS wikipedia.org 451 0.593

16

Konrad Wolsing

slide-18
SLIDE 18

Conclusion

  • Results

◮ TCP tuning is not negligible ◮ Still QUIC outperforms TCP, but the gap gets narrower ◮ QUIC mostly faster due to the RTT reduced connection establishment ◮ Congestion control sometimes matters more than protocol choice

  • Discussion

◮ QUIC is not build to primarily improve performance ◮ QUIC enables an evolvable stack especially on transport layer ◮ Open question: Do users perceive QUIC as faster?

Thank you for your attention.

17

Konrad Wolsing

slide-19
SLIDE 19

Literature I

  • P. Biswal and O. Gnawali.

Does quic make the web faster? In Global Communications Conference (GLOBECOM), pages 1–6. IEEE, 2016. Breitbandmessung. Breitbandmessung Ergebnisse als interaktive Darstellung. https://web.archive.org/web/20181115105855/https://breitbandmessung.de/interaktive-darstellung. Accessed: 2018-11-15.

  • G. Carlucci, L. De Cicco, and S. Mascolo.

HTTP over UDP: an Experimental Investigation of QUIC. In Proceedings of the 30th Annual ACM Symposium on Applied Computing, pages 609–614. ACM, 2015.

  • S. Cook, B. Mathieu, P. Truong, and I. Hamchaoui.

QUIC: Better for what and for whom? In International Conference on Communications (ICC), pages 1–6. IEEE, May 2017.

  • A. M. Kakhki, S. Jero, D. Chofgnes, C. Nita-Rotaru, and A. Mislove.

Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of Rapidly Evolving Transport Protocols. In Proceedings of the Internet Measurement Conference (IMC), pages 290–303. ACM, 2017.

18

Konrad Wolsing

slide-20
SLIDE 20

Literature II

  • P. Megyesi, Z. Krämer, and S. Molnár.

How quick is QUIC? In 2016 IEEE International Conference on Communications (ICC), pages 1–6. IEEE, 2016.

  • J. P. Rula, J. Newman, F. E. Bustamante, A. M. Kakhki, and D. Chofgnes.

Mile High WiFi: A First Look At In-Flight Internet Connectivity. In Proceedings of the World Wide Web Conference on World Wide Web (WWW), pages 1449–1458, 2018.

  • M. Wijnants, R. Marx, P. Quax, and W. Lamotte.

HTTP/2 Prioritization and its Impact on Web Performance. In Proceedings of the World Wide Web Conference (WWW), pages 1755–1764. ACM, 2018.

  • Y. Yu, M. Xu, and Y. Yang.

When QUIC meets TCP: An experimental study. In 36th International Performance Computing and Communications Conference (IPCCC), pages 1–8. IEEE, Dec 2017.

  • Y. Zheng, Y. Wang, M. Rui, A. Palade, S. Sheehan, and E. O’Nuallain.

Performance Evaluation of HTTP/2 over TLS+ TCP and HTTP/2 over QUIC in a Mobile Network. Journal of Information Sciences and Computing Technologies, 7(1):673–682, 2018.

19

Konrad Wolsing