SlideShare a Scribd company logo
1 of 34
Download to read offline
A Quick look at QUIC
Geoff Huston, Joao Damas,
APNIC Labs
QUIC is…
HTTP
Multistream
TLS
Session Encryption
TCP
Data stream integrity
Congestion Control
HTTP
QUIC
Multistream
Encryption
Data stream integrity
Congestion Control
UDP
IP
HTTP/2 HTTP/3
QUIC is…
A transport level framing protocol that offers applications access to the
basic IP datagram services offered by IP through the use of UDP
All other transport services (data integrity, session control, congestion control) are
shifted towards the application
Support for multi-stream multiplexing that avoids head-of-line blocking
and exploits a shared congestion and encryption state
QUIC also places the transport control fields inside the encryption
envelope, so QUIC has minimal exposure to the network
What TCP needs to be for the Internet of 2022!
Looking for QUIC
• At APNIC we use Ads to perform large scale measurements of
network service capabilities as seen by users
• IPv6 deployment
• DNSSEC validation
• Fragmentation
• Can we use this measurement platform to see the level of use of
QUIC in today’s network?
Setting up QUIC
• Server:
• nginx v1.21.7 with QUIC functions included
• DNS:
• Set up an HTTPS record for each URL with value: alpn=“h3”
• Content:
• Alt-Svc: h3=“:443”
(This second method requires a subsequent query to allow the client to use the Alt-Svc
capability. We perform a 2-second delayed second query for this URL in the measurement
experiment approximately one fifth of the time. We keep the domain name constant and vary
the URL arguments to detect the second fetch.)
• Server:
• nginx v1.21.7 with QUIC functions included
• DNS:
• Set up an HTTPS record for each URL with value: alpn=“h3”
• Content:
• Alt-Svc: h3=“:443”
Setting up QUIC
First Fetch
Second Fetch
QUIC Use – June/July 2022
About 3.5% of
users use HTTP/3
for the second
fetch
About 1% of users
are seen to use
HTTP/3 on first
fetch
This result looks wrong!
• Some 90% of the browsers we “see” via the ad campaign identify
themselves as Chrome
• And Chrome has been supporting a switch to QUIC via the Alt-Svc
directive since 2020
This result looks wrong!
• Some 90% of the browsers we “see” via the ad campaign identify
themselves as Chrome
• And Chrome has been supporting a switch to QUIC via the Alt-Svc
directive since 2020
• So we should be seeing a far higher level of QUIC use than 3.5%
Hmm
• What do others see?
Cloudflare’s Numbers
Our QUIC use numbers are far lower than other published measures
Maybe 2 fetches is not enough?
• So we changed the experiment to fetch the same URL 7 times with a 2
second pause between each fetch
• Surely this would flush out QUIC use!
Nope!
• No change!
• The problem appears to be related to HTTP/2 and persistent
connections
• When the browser performs the followup fetch the connection is
likely still open and then the browser will prefer to use the open
connection over opening up a new QUIC connect
• So on the NGINX server let’s set the keepalive session parameter to 0
seconds
• Yes?
Still Nope!
• That was worse!
• We didn’t see any use of QUIC at all
• Nothing. Nada. Not even a little bit.
• Seems that if you set keepalive to zero then NGINX disables QUIC
completely!
• So we then set the session keepalive parameter to 1 second
• Better?
QUIC Use – June - August 2022
keepalive=0 keepalive=1
Change from 1 to 7 repeat fetches
Yes!
• We are seeing a 57% QUIC on the repeat fetches, corresponding to a
rate of 63% QUIC use of Chrome clients
Yes, and No
• We are seeing a 57% QUIC on the repeat fetches, corresponding to a
rate of 63% QUIC use of Chrome clients
• But at the same time the first fetch use dropped from 1% to minimal
levels
• Which appears to be an issue with Safari, and iOS (and MAC OS)
• Chrome and Firefox were also behaving erratically across the 7 repeat
fetches flipping between HTTP/2 and HTTP/3
QUIC Use – August 2022
QUIC Use – August 2022
QUIC Use – August 2022
Huh?
Yes, and No
• We are seeing a 57% QUIC on the repeat fetches, corresponding to a
rate of 63% QUIC use of Chrome clients
• But at the same time the first fetch use dropped from 1% to minimal
levels
• Which appears to be an issue with Safari, and iOS (and MAC OS)
• Interestingly, Safari technology preview (release 150, safari 16.0,
webkit 17614.1.22.1.1) does not show this behaviour within our test
rig
• So we were unsure what is going on here between Safari clients and
our NGINX-based QUIC server
Its all about Keepalive Timers
• After much searching under many rocks we are advised (many thanks
to Ryan Hamilton, Martin Thompson and Tommy Pauly for various
clues at this stage) that a server keepalive timer value of 1 is also a
Really Bad setting!
• The server is dropping the QUIC connection too aggressively and the
browser client drops back to HTTP/2
• The default value of 65 seconds for the server keepalive interval
seems to be too long
• And 1 second is too short
• So now let’s try a value of 20 seconds…
Quic Use – September 2022
Quic Use – September 2022
Change from 1 to 7 repeat fetches
keepalive=0
keepalive=1 keepalive=20
Some Questions:
1. Which clients are performing QUIC and why?
2. What are the QUIC MSS values?
3. What is the QUIC connection failure rate?
4. Is QUIC faster than HTTP/2 + TLS?
TCP/TLS QUIC on First Fetch QUIC on Second Fetch
iOS 5.5% 93.3% 16.1%
Mac OS 1.0% 2.8% 0.6%
Android 84.5% 1.7% 77.9%
Win 5.5% 1.4% 4.3%
Linux 0.4% 0.2% 0.2%
Others 3.1% 0.6% 0.9%
100.0% 100.0% 100.0%
1. OS Clients* performing QUIC
* Based on reported browser string
1. Browser Clients* performing QUIC
TCP/TLS QUIC on First Fetch QUIC on Second Fetch
Chrome 91.8% 4.1% 81.7%
Safari 4.3% 93.3% 16.1%
Firefox 0.8% 2.4% 1.0%
Edge 0.7% 0.0% 0.5%
Opera 0.2% 0.1% 0.6%
Others 2.2% 0.1% 0.1%
100.0% 100.0% 100.0%
* Based on reported browser string
1. Who does QUIC and why?
Apple Safari clients use a DNS HTTPS query and some of these
clients then follow up with a fetch over QUIC. The observed
DNS HTTPS query to QUIC fetch conversion rate was relatively
small.
Chrome clients use the Alt-Svc field as a QUIC trigger for most
clients. The observed QUIC conversion rate was high, but not
universal.
* Based on reported browser string
2. QUIC Packet Size distribution
Maximum Packet Sizes used in QUIC sessions:
1,200 octets – 46.6%
1,250 octets – 18.5%
1,252 octets – 16.4%
QUIC clients take a very
conservative approach to
maximum packet sizes to
avoid packet fragmentation
complications
3. QUIC Connection Loss
In this measurement framework we cannot measure client -> server
loss, but we can measure server-> client loss by looking for incomplete
QUIC initial connections that do not complete
(this form of connection loss could be due to the client filtering incoming UDP
port 443 packets)
Initial QUIC Connections: 19,211,357
Failed Connections: 46,645
Failure Rate: 0.24%
4. Is QUIC Faster?
Let’s compare the user-measured time to load an object using HTTP/2
and the same user’s measured time to load the same object using
HTTP/3
• There are a number of variables in the user time measurement, including
varying time penalties relating to the internal task scheduling within the
browser, but these individual factors should be cancelled out over a large
enough sample set
4. TCP/TLS vs QUIC speed
difference
Area where QUIC is faster
Non-QUIC Faster QUIC Faster
ms
4. Cumulative Distribution
HTTP/3 is faster to
perform object
retrieval in 2/3 of
the observed cases
Non-QUIC Faster QUIC Faster
ms
Some Answers:
1. Which clients are performing QUIC?
The recent change appears to relate predominately to iOS 15.x clients (iPhones and iPads) using
HTTPS queries and selectively performing an object retrieval over HTTP/3 at a rate of
approximately 1 in 5
2. What are the QUIC MSS values?
Most QUIC clients limit their total IP packet size to a max of either 1,250 or 1,252 octets. Largest
observed packet was 1,357 octets
3. What is the QUIC connection failure rate?
Extremely small at 0.24%. This falls within the bounds of experimental error in this experiment’s
framework.
4. Is QUIC faster than HTTP/2 + TLS?
Yes, more than 2/3 of the time QUIC will complete in less elapsed time than the equivalent HTTP/2
retrieval
Thanks!
Ongoing HTTP/3 Measurement Report at APNIC Labs:
https://stats.labs.apnic.net/quic

More Related Content

Similar to A Quick Look at QUIC, presentation for RIPE 85 by Geoff Huston.pdf

Similar to A Quick Look at QUIC, presentation for RIPE 85 by Geoff Huston.pdf (20)

BWE in Janus
BWE in JanusBWE in Janus
BWE in Janus
 
Network
NetworkNetwork
Network
 
Introduction to QUIC
Introduction to QUICIntroduction to QUIC
Introduction to QUIC
 
Quick QUIC Technical Update (2017)
Quick QUIC Technical Update (2017)Quick QUIC Technical Update (2017)
Quick QUIC Technical Update (2017)
 
Best practices of building data streaming API
Best practices of building data streaming APIBest practices of building data streaming API
Best practices of building data streaming API
 
.NET Conf 2022 - Networking in .NET 7
.NET Conf 2022 - Networking in .NET 7.NET Conf 2022 - Networking in .NET 7
.NET Conf 2022 - Networking in .NET 7
 
Networking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOGNetworking in the Penumbra presented by Geoff Huston at NZNOG
Networking in the Penumbra presented by Geoff Huston at NZNOG
 
Building real time applications with Symfony2
Building real time applications with Symfony2Building real time applications with Symfony2
Building real time applications with Symfony2
 
WebRTC Seminar Report
WebRTC  Seminar ReportWebRTC  Seminar Report
WebRTC Seminar Report
 
Altitude San Francisco 2018: HTTP/2 Tales: Discovery and Woe
Altitude San Francisco 2018: HTTP/2 Tales: Discovery and WoeAltitude San Francisco 2018: HTTP/2 Tales: Discovery and Woe
Altitude San Francisco 2018: HTTP/2 Tales: Discovery and Woe
 
PAC 2019 virtual Bruno Audoux
PAC 2019 virtual Bruno Audoux PAC 2019 virtual Bruno Audoux
PAC 2019 virtual Bruno Audoux
 
Presentazione Laurea Nuzzi Alessandro.pptx
Presentazione Laurea Nuzzi Alessandro.pptxPresentazione Laurea Nuzzi Alessandro.pptx
Presentazione Laurea Nuzzi Alessandro.pptx
 
Windows Communication Foundation (WCF)
Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)
Windows Communication Foundation (WCF)
 
IRJET- An Overview of Web Sockets: The Future of Real-Time Communication
IRJET- An Overview of Web Sockets: The Future of Real-Time CommunicationIRJET- An Overview of Web Sockets: The Future of Real-Time Communication
IRJET- An Overview of Web Sockets: The Future of Real-Time Communication
 
Building Modern Digital Services on Scalable Private Government Infrastructur...
Building Modern Digital Services on Scalable Private Government Infrastructur...Building Modern Digital Services on Scalable Private Government Infrastructur...
Building Modern Digital Services on Scalable Private Government Infrastructur...
 
SenchaCon 2016: How to Give your Sencha App Real-time Web Performance - James...
SenchaCon 2016: How to Give your Sencha App Real-time Web Performance - James...SenchaCon 2016: How to Give your Sencha App Real-time Web Performance - James...
SenchaCon 2016: How to Give your Sencha App Real-time Web Performance - James...
 
whats-new_Fireware_v11-10
whats-new_Fireware_v11-10whats-new_Fireware_v11-10
whats-new_Fireware_v11-10
 
Architecting Low Latency Applications Alberto Gonzalez
Architecting Low Latency Applications Alberto GonzalezArchitecting Low Latency Applications Alberto Gonzalez
Architecting Low Latency Applications Alberto Gonzalez
 
WebRTC Standards & Implementation Q&A - WebRTC Standards Feature Complete 
No...
WebRTC Standards & Implementation Q&A - WebRTC Standards Feature Complete 
No...WebRTC Standards & Implementation Q&A - WebRTC Standards Feature Complete 
No...
WebRTC Standards & Implementation Q&A - WebRTC Standards Feature Complete 
No...
 
Architecting your WebRTC application for scalability, Arin Sime
Architecting your WebRTC application for scalability, Arin SimeArchitecting your WebRTC application for scalability, Arin Sime
Architecting your WebRTC application for scalability, Arin Sime
 

More from APNIC

More from APNIC (20)

APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53APNIC Updates presented by Paul Wilson at ARIN 53
APNIC Updates presented by Paul Wilson at ARIN 53
 
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
 
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
'Future Evolution of the Internet' delivered by Geoff Huston at Everything Op...
 
On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024On Starlink, presented by Geoff Huston at NZNOG 2024
On Starlink, presented by Geoff Huston at NZNOG 2024
 
IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119
 
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119draft-harrison-sidrops-manifest-number-01, presented at IETF 119
draft-harrison-sidrops-manifest-number-01, presented at IETF 119
 
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
Making an RFC in Today's IETF, presented by Geoff Huston at IETF 119
 
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
IPv6 Operational Issues (with DNS), presented by Geoff Huston at IETF 119
 
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
Is DNS ready for IPv6, presented by Geoff Huston at IETF 119
 
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
Benefits of doing Internet peering and running an Internet Exchange (IX) pres...
 
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
APNIC Update and RIR Policies for ccTLDs, presented at APTLD 85
 
NANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff HustonNANOG 90: 'BGP in 2023' presented by Geoff Huston
NANOG 90: 'BGP in 2023' presented by Geoff Huston
 
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff HustonDNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
DNS-OARC 42: Is the DNS ready for IPv6? presentation by Geoff Huston
 
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, ThailandAPAN 57: APNIC Report at APAN 57, Bangkok, Thailand
APAN 57: APNIC Report at APAN 57, Bangkok, Thailand
 
Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6Lao Digital Week 2024: It's time to deploy IPv6
Lao Digital Week 2024: It's time to deploy IPv6
 
AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!AINTEC 2023: Networking in the Penumbra!
AINTEC 2023: Networking in the Penumbra!
 
CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023CNIRC 2023: Global and Regional IPv6 Deployment 2023
CNIRC 2023: Global and Regional IPv6 Deployment 2023
 
AFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet developmentAFSIG 2023: APNIC Foundation and support for Internet development
AFSIG 2023: APNIC Foundation and support for Internet development
 
AFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment StatusAFNOG 1: Afghanistan IP Deployment Status
AFNOG 1: Afghanistan IP Deployment Status
 
AFSIG 2023: Internet routing and addressing
AFSIG 2023: Internet routing and addressingAFSIG 2023: Internet routing and addressing
AFSIG 2023: Internet routing and addressing
 

Recently uploaded

Lucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRL
Lucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRLLucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRL
Lucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRL
imonikaupta
 
₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...
₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...
₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...
Diya Sharma
 
6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...
6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...
6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...
@Chandigarh #call #Girls 9053900678 @Call #Girls in @Punjab 9053900678
 
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
Chandigarh Call girls 9053900678 Call girls in Chandigarh
 
valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
Call Girls In Delhi Whatsup 9873940964 Enjoy Unlimited Pleasure
 
Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝
soniya singh
 
Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...
Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...
Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...
Sheetaleventcompany
 
AWS Community DAY Albertini-Ellan Cloud Security (1).pptx
AWS Community DAY Albertini-Ellan Cloud Security (1).pptxAWS Community DAY Albertini-Ellan Cloud Security (1).pptx
AWS Community DAY Albertini-Ellan Cloud Security (1).pptx
ellan12
 

Recently uploaded (20)

Call Now ☎ 8264348440 !! Call Girls in Sarai Rohilla Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Sarai Rohilla Escort Service Delhi N.C.R.Call Now ☎ 8264348440 !! Call Girls in Sarai Rohilla Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Sarai Rohilla Escort Service Delhi N.C.R.
 
Moving Beyond Twitter/X and Facebook - Social Media for local news providers
Moving Beyond Twitter/X and Facebook - Social Media for local news providersMoving Beyond Twitter/X and Facebook - Social Media for local news providers
Moving Beyond Twitter/X and Facebook - Social Media for local news providers
 
Call Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service Available
Call Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service AvailableCall Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service Available
Call Girls Ludhiana Just Call 98765-12871 Top Class Call Girl Service Available
 
Lucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRL
Lucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRLLucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRL
Lucknow ❤CALL GIRL 88759*99948 ❤CALL GIRLS IN Lucknow ESCORT SERVICE❤CALL GIRL
 
All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445
All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445
All Time Service Available Call Girls Mg Road 👌 ⏭️ 6378878445
 
Russian Call Girls Pune (Adult Only) 8005736733 Escort Service 24x7 Cash Pay...
Russian Call Girls Pune  (Adult Only) 8005736733 Escort Service 24x7 Cash Pay...Russian Call Girls Pune  (Adult Only) 8005736733 Escort Service 24x7 Cash Pay...
Russian Call Girls Pune (Adult Only) 8005736733 Escort Service 24x7 Cash Pay...
 
Top Rated Pune Call Girls Daund ⟟ 6297143586 ⟟ Call Me For Genuine Sex Servi...
Top Rated  Pune Call Girls Daund ⟟ 6297143586 ⟟ Call Me For Genuine Sex Servi...Top Rated  Pune Call Girls Daund ⟟ 6297143586 ⟟ Call Me For Genuine Sex Servi...
Top Rated Pune Call Girls Daund ⟟ 6297143586 ⟟ Call Me For Genuine Sex Servi...
 
₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...
₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...
₹5.5k {Cash Payment}New Friends Colony Call Girls In [Delhi NIHARIKA] 🔝|97111...
 
VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...
VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...
VVVIP Call Girls In Connaught Place ➡️ Delhi ➡️ 9999965857 🚀 No Advance 24HRS...
 
𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...
𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...
𓀤Call On 7877925207 𓀤 Ahmedguda Call Girls Hot Model With Sexy Bhabi Ready Fo...
 
6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...
6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...
6.High Profile Call Girls In Punjab +919053900678 Punjab Call GirlHigh Profil...
 
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
Low Sexy Call Girls In Mohali 9053900678 🥵Have Save And Good Place 🥵
 
Real Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirtReal Men Wear Diapers T Shirts sweatshirt
Real Men Wear Diapers T Shirts sweatshirt
 
valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
valsad Escorts Service ☎️ 6378878445 ( Sakshi Sinha ) High Profile Call Girls...
 
(+971568250507 ))# Young Call Girls in Ajman By Pakistani Call Girls in ...
(+971568250507  ))#  Young Call Girls  in Ajman  By Pakistani Call Girls  in ...(+971568250507  ))#  Young Call Girls  in Ajman  By Pakistani Call Girls  in ...
(+971568250507 ))# Young Call Girls in Ajman By Pakistani Call Girls in ...
 
Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝
Call Girls In Model Towh Delhi 💯Call Us 🔝8264348440🔝
 
Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Green Park Escort Service Delhi N.C.R.
 
Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...
Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...
Call Girls Service Chandigarh Lucky ❤️ 7710465962 Independent Call Girls In C...
 
AWS Community DAY Albertini-Ellan Cloud Security (1).pptx
AWS Community DAY Albertini-Ellan Cloud Security (1).pptxAWS Community DAY Albertini-Ellan Cloud Security (1).pptx
AWS Community DAY Albertini-Ellan Cloud Security (1).pptx
 
Call Now ☎ 8264348440 !! Call Girls in Rani Bagh Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Rani Bagh Escort Service Delhi N.C.R.Call Now ☎ 8264348440 !! Call Girls in Rani Bagh Escort Service Delhi N.C.R.
Call Now ☎ 8264348440 !! Call Girls in Rani Bagh Escort Service Delhi N.C.R.
 

A Quick Look at QUIC, presentation for RIPE 85 by Geoff Huston.pdf

  • 1. A Quick look at QUIC Geoff Huston, Joao Damas, APNIC Labs
  • 2. QUIC is… HTTP Multistream TLS Session Encryption TCP Data stream integrity Congestion Control HTTP QUIC Multistream Encryption Data stream integrity Congestion Control UDP IP HTTP/2 HTTP/3
  • 3. QUIC is… A transport level framing protocol that offers applications access to the basic IP datagram services offered by IP through the use of UDP All other transport services (data integrity, session control, congestion control) are shifted towards the application Support for multi-stream multiplexing that avoids head-of-line blocking and exploits a shared congestion and encryption state QUIC also places the transport control fields inside the encryption envelope, so QUIC has minimal exposure to the network What TCP needs to be for the Internet of 2022!
  • 4. Looking for QUIC • At APNIC we use Ads to perform large scale measurements of network service capabilities as seen by users • IPv6 deployment • DNSSEC validation • Fragmentation • Can we use this measurement platform to see the level of use of QUIC in today’s network?
  • 5. Setting up QUIC • Server: • nginx v1.21.7 with QUIC functions included • DNS: • Set up an HTTPS record for each URL with value: alpn=“h3” • Content: • Alt-Svc: h3=“:443” (This second method requires a subsequent query to allow the client to use the Alt-Svc capability. We perform a 2-second delayed second query for this URL in the measurement experiment approximately one fifth of the time. We keep the domain name constant and vary the URL arguments to detect the second fetch.)
  • 6. • Server: • nginx v1.21.7 with QUIC functions included • DNS: • Set up an HTTPS record for each URL with value: alpn=“h3” • Content: • Alt-Svc: h3=“:443” Setting up QUIC First Fetch Second Fetch
  • 7. QUIC Use – June/July 2022 About 3.5% of users use HTTP/3 for the second fetch About 1% of users are seen to use HTTP/3 on first fetch
  • 8. This result looks wrong! • Some 90% of the browsers we “see” via the ad campaign identify themselves as Chrome • And Chrome has been supporting a switch to QUIC via the Alt-Svc directive since 2020
  • 9. This result looks wrong! • Some 90% of the browsers we “see” via the ad campaign identify themselves as Chrome • And Chrome has been supporting a switch to QUIC via the Alt-Svc directive since 2020 • So we should be seeing a far higher level of QUIC use than 3.5% Hmm • What do others see?
  • 10. Cloudflare’s Numbers Our QUIC use numbers are far lower than other published measures
  • 11. Maybe 2 fetches is not enough? • So we changed the experiment to fetch the same URL 7 times with a 2 second pause between each fetch • Surely this would flush out QUIC use!
  • 12. Nope! • No change! • The problem appears to be related to HTTP/2 and persistent connections • When the browser performs the followup fetch the connection is likely still open and then the browser will prefer to use the open connection over opening up a new QUIC connect • So on the NGINX server let’s set the keepalive session parameter to 0 seconds • Yes?
  • 13. Still Nope! • That was worse! • We didn’t see any use of QUIC at all • Nothing. Nada. Not even a little bit. • Seems that if you set keepalive to zero then NGINX disables QUIC completely! • So we then set the session keepalive parameter to 1 second • Better?
  • 14. QUIC Use – June - August 2022 keepalive=0 keepalive=1 Change from 1 to 7 repeat fetches
  • 15. Yes! • We are seeing a 57% QUIC on the repeat fetches, corresponding to a rate of 63% QUIC use of Chrome clients
  • 16. Yes, and No • We are seeing a 57% QUIC on the repeat fetches, corresponding to a rate of 63% QUIC use of Chrome clients • But at the same time the first fetch use dropped from 1% to minimal levels • Which appears to be an issue with Safari, and iOS (and MAC OS) • Chrome and Firefox were also behaving erratically across the 7 repeat fetches flipping between HTTP/2 and HTTP/3
  • 17. QUIC Use – August 2022
  • 18. QUIC Use – August 2022
  • 19. QUIC Use – August 2022 Huh?
  • 20. Yes, and No • We are seeing a 57% QUIC on the repeat fetches, corresponding to a rate of 63% QUIC use of Chrome clients • But at the same time the first fetch use dropped from 1% to minimal levels • Which appears to be an issue with Safari, and iOS (and MAC OS) • Interestingly, Safari technology preview (release 150, safari 16.0, webkit 17614.1.22.1.1) does not show this behaviour within our test rig • So we were unsure what is going on here between Safari clients and our NGINX-based QUIC server
  • 21. Its all about Keepalive Timers • After much searching under many rocks we are advised (many thanks to Ryan Hamilton, Martin Thompson and Tommy Pauly for various clues at this stage) that a server keepalive timer value of 1 is also a Really Bad setting! • The server is dropping the QUIC connection too aggressively and the browser client drops back to HTTP/2 • The default value of 65 seconds for the server keepalive interval seems to be too long • And 1 second is too short • So now let’s try a value of 20 seconds…
  • 22. Quic Use – September 2022
  • 23. Quic Use – September 2022 Change from 1 to 7 repeat fetches keepalive=0 keepalive=1 keepalive=20
  • 24. Some Questions: 1. Which clients are performing QUIC and why? 2. What are the QUIC MSS values? 3. What is the QUIC connection failure rate? 4. Is QUIC faster than HTTP/2 + TLS?
  • 25. TCP/TLS QUIC on First Fetch QUIC on Second Fetch iOS 5.5% 93.3% 16.1% Mac OS 1.0% 2.8% 0.6% Android 84.5% 1.7% 77.9% Win 5.5% 1.4% 4.3% Linux 0.4% 0.2% 0.2% Others 3.1% 0.6% 0.9% 100.0% 100.0% 100.0% 1. OS Clients* performing QUIC * Based on reported browser string
  • 26. 1. Browser Clients* performing QUIC TCP/TLS QUIC on First Fetch QUIC on Second Fetch Chrome 91.8% 4.1% 81.7% Safari 4.3% 93.3% 16.1% Firefox 0.8% 2.4% 1.0% Edge 0.7% 0.0% 0.5% Opera 0.2% 0.1% 0.6% Others 2.2% 0.1% 0.1% 100.0% 100.0% 100.0% * Based on reported browser string
  • 27. 1. Who does QUIC and why? Apple Safari clients use a DNS HTTPS query and some of these clients then follow up with a fetch over QUIC. The observed DNS HTTPS query to QUIC fetch conversion rate was relatively small. Chrome clients use the Alt-Svc field as a QUIC trigger for most clients. The observed QUIC conversion rate was high, but not universal. * Based on reported browser string
  • 28. 2. QUIC Packet Size distribution Maximum Packet Sizes used in QUIC sessions: 1,200 octets – 46.6% 1,250 octets – 18.5% 1,252 octets – 16.4% QUIC clients take a very conservative approach to maximum packet sizes to avoid packet fragmentation complications
  • 29. 3. QUIC Connection Loss In this measurement framework we cannot measure client -> server loss, but we can measure server-> client loss by looking for incomplete QUIC initial connections that do not complete (this form of connection loss could be due to the client filtering incoming UDP port 443 packets) Initial QUIC Connections: 19,211,357 Failed Connections: 46,645 Failure Rate: 0.24%
  • 30. 4. Is QUIC Faster? Let’s compare the user-measured time to load an object using HTTP/2 and the same user’s measured time to load the same object using HTTP/3 • There are a number of variables in the user time measurement, including varying time penalties relating to the internal task scheduling within the browser, but these individual factors should be cancelled out over a large enough sample set
  • 31. 4. TCP/TLS vs QUIC speed difference Area where QUIC is faster Non-QUIC Faster QUIC Faster ms
  • 32. 4. Cumulative Distribution HTTP/3 is faster to perform object retrieval in 2/3 of the observed cases Non-QUIC Faster QUIC Faster ms
  • 33. Some Answers: 1. Which clients are performing QUIC? The recent change appears to relate predominately to iOS 15.x clients (iPhones and iPads) using HTTPS queries and selectively performing an object retrieval over HTTP/3 at a rate of approximately 1 in 5 2. What are the QUIC MSS values? Most QUIC clients limit their total IP packet size to a max of either 1,250 or 1,252 octets. Largest observed packet was 1,357 octets 3. What is the QUIC connection failure rate? Extremely small at 0.24%. This falls within the bounds of experimental error in this experiment’s framework. 4. Is QUIC faster than HTTP/2 + TLS? Yes, more than 2/3 of the time QUIC will complete in less elapsed time than the equivalent HTTP/2 retrieval
  • 34. Thanks! Ongoing HTTP/3 Measurement Report at APNIC Labs: https://stats.labs.apnic.net/quic