Presentazione prelaurea magistrale Alessandro Nuzzi

1. Performance assessment of the MASQUE extension for
proxying scenarios in the QUIC transport protocol
Anno accademico 2022-2023
DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA
Corso di Laurea in Ingegneria Elettronica e Informatica
Curriculum Reti & IoT
Laureando
Alessandro Nuzzi
Relatori
Prof. Alberto Bartoli
Prof. Martino Trevisan

2. Context
• The web relies on many protocols to enable communication and
information sharing across the Internet
• HTTP and TCP are the predominant protocols driving today's web
infrastructure
• The new QUIC (Quick UDP Internet Connections) transport protocol is
on the rise across the world for many applications

3. QUIC vs TCP
• Reduced connection establishment
latency
• Connection migration support
• Header encryption
• No head-of-line blocking

4. QUIC: Usage
• More than 40% of traffic for big
applications requiring high efficiency
• Facebook, Netflix, YouTube, Instagram
• High traffic around the world
• 46% in Latin America, 42% in Europe and
32% in the United States
• Widely supported by providers
• Akamai, Cloudflare, Fastly

5. Proxies
• Act as intermediaries between clients and servers
• Provide several features
• Network optimization
• Privacy enhancement
• Content filtering

6. Problem introduction
• QUIC encrypts almost all of its packet header fields
• Difficult for proxies to inspect traffic and apply policy rules
• Proxies might treat QUIC traffic as malicious or unknown
• Traffic delayed or dropped
• Need for new proxying technologies that allow HTTP to create tunnels
for proxying any non-TCP-based protocols, such as QUIC

7. MASQUE
Multiplexed Application Substrate over QUIC Encryption
• IETF working group formed in June 2020
• Supports proxying UDP and IP over HTTP
• Using QUIC DATAGRAMS with HTTP/3 (RFC 9297)
• CONNECT-UDP (RFC 9298)
• Provides privacy guarantees
• Hiding client IP address from the target server
• Obfuscating traffic destination from client network provider
• Can perform network translation or DNS resolution

8. CONNECT-UDP
• Uses new DATAGRAM frame
• Unreliable
• Congestion-controlled
• ACK-eliciting, not retransmitted
• Creates and connects a UDP
socket to a target server
• Creates an end-to-end flow of
unreliable messages between
client and server

9. Thesis objectives
• Evaluate the performance of the MASQUE proposal in proxying
scenarios
• Several network conditions
• Comparison with traditional HTTP/TCP proxies
• Scenarios in which MASQUE usage could be beneficial

10. Tools used
Hard to find stable implementations of MASQUE and QUIC
• Cloudflare QUIC server
• Google QUIC client
• Google MASQUE client and MASQUE proxy
• curl command-line tool
• Squid proxy
• Twisted HTTPS server

11. Testing environment
• Docker-based emulation
• Client, server and proxy containers
• Traffic control and network conditions with tc
• Additional delay, bandwidth limit, packet loss
• Automation with Bash scripts
• Execution of repetitive or complex operations

12. Methodology
• Client requesting a constant-sized file via HTTP GET
• File requested to target server, either through proxy or not
• Transfer time measured
• Different file sizes
• Four categories
• Without proxy: TCP with TLS and QUIC
• With proxy: TCP with TLS and MASQUE
• Simulated network conditions
• Bandwidth limit, additional delay, packet loss

13. Network conditions
• Additional delay
• Results in additional RTT
• Without proxy: doubled delay applied to client interface
• With proxy: single delays applied to client and server interfaces
• Packet loss
• Without proxy: loss divided by two on all interfaces
• With proxy: loss divided by four on all interfaces
• Bandwidth limit
• Limit applied to client and server interfaces

14. Experiments
• A full test is made of four experiments, one for each category
• MASQUE, TCP+TLS with proxy, QUIC, TCP+TLS without proxy
• Each experiment is made of 21 measurements
• Delay increased in every new measurement, from 0ms to 200ms
• Each measurement is made of 100 iterations
• Each iteration is a file request
• Fixed network conditions: delay, bandwidth, packet loss
• Data summary based on the iterations measured times

15. Data
• Collected data for each request
• Real time: elapsed time from client command start to finish
• CPU time: processing time used by client command on user and kernel mode
• Data summary for each measurement
• Collected real times used to calculate measurement summary
• Mean, standard deviation, median, quartiles...
• In case of error, time is discarded and error is logged

16. Experimental campaigns
• Three scenarios
• Low bandwidth: 10Mbps, no packet loss, variable delay
• Medium bandwidth: 100Mbps, no packet loss, variable delay
• High bandwidth: 1Gbps, no packet loss, variable delay
• In each scenario, 1MB and 10MB download
• Other scenarios
• Medium bandwidth, 1MB file download, 10ms delay, 0%, 1%, 2%, 5% packet loss

17. Low bandwidth
1MB file
• TCP+TLS with proxy has best
performance
• Gap between QUIC, MASQUE
and TCP+TLS at the beginning
• QUIC similar to TCP+TLS
without proxy
• QUIC has worst performance
between 140ms and 170ms
• QUIC outperforms MASQUE and
TCP+TLS without proxy after
• Internal tuning mechanisms

18. Medium bandwidth
1MB file
• Same considerations about
TCP+TLS without proxy and
performance gap
• QUIC performs better than
MASQUE, except at 30ms
• QUIC outperforms TCP+TLS
without proxy starting from
80ms, MASQUE from 190ms
• QUIC and MASQUE less
variable than TCP+TLS

19. High bandwidth
1MB file
• Similar as previous scenario
• QUIC and MASQUE start
performing better than
TCP+TLS without proxy earlier,
at 40ms and 140ms

20. All bandwidth
10MB file
• Same considerations about
TCP+TLS without proxy and
performance gap
• MASQUE and QUIC never reach
TCP+TLS
• MASQUE perform worse than
QUIC before a certain time,
better after

21. Medium bandwidth,
1MB, 10ms, loss
• Measured time of each box
increases as loss increases
• MASQUE performs the worst
• QUIC keeps its median below
the TCP+TLS counterpart when
the loss is the highest

22. CPU time VS Real
time
• QUIC has equal CPU time and
Real time
• The process actively executes
instructions on the CPU
• TCP+TLS cases have constant
CPU time
• Waiting time is not considered in
the CPU time
• MASQUE has almost constant
CPU time, except at the
beginning
Lines overlap!

23. Results
• TCP+TLS with proxy has the best performance
• In presence of a proxy, TCP+TLS uses two end-to-end independent
connections
• Retransmissions happen independently in the two connections
• Higher throughput
• In MASQUE, only one connection is established
• End-to-end retransmissions
• Using a proxy does not provide advantages

24. Results (II)
• Small files: MASQUE performs similarly or worse than QUIC
• Bigger files: MASQUE outperforms QUIC in medium and high bandwidth
and high latency links
• Low bandwidth and high latency: QUIC has very good performance
• Lossy links: QUIC has better performance than equivalent TCP+TLS and
than MASQUE
• QUIC and MASQUE have different retransmission mechanism

25. Results (III)
• Higher bandwidth is beneficial for QUIC and MASQUE with small files
• The higher the bandwidth, the sooner QUIC and MASQUE outperform TCP+TLS
without proxy
• With little to no added delay, QUIC better than MASQUE and TCP+TLS
better than QUIC
• After this time interval, QUIC and MASQUE have small difference

26. Limitations and future work
• MASQUE early development stage
• Existing implementations are not yet stable
• Need for analysing new or enhanced MASQUE implementations
• Experiments only with single HTTP requests
• Need to evaluate performance of complex web pages
• And other applications: video streaming, mail, etc.
• Need for finding root causes reason of the performance gaps
• Possibility of using more sophisticated network conditions
• Correlated packet loss
• Unevenly distributed delay

27. Conclusions
• Overall modest performance cost associated with the employment of MASQUE
in proxying scenarios that already use QUIC
• Adopting MASQUE to achieve its privacy guarantees comes at a reasonable
performance expense
• MASQUE can be a good choice in several contexts
• IoT devices
• Companies handling sensitive data
• Developing protocols with encryption and privacy promises involves a
performance trade-off

28. Thank you for your
attention