Computer Science 1812415 AM6-Proposed RD

Congestion control for QUIC
Project by:
Emmanuel Jeremie Daniel (1812415)
Submitted in Partial Fulfillment for the Degree of

BSc(Hons) Computer Science
UNIVERSITY OF MAURITIUS
FACULTY OF INFORMATION, COMMUNICATION AND
DIGITAL TECHNOLOGIES (FoICDT)
Department of Information and Communication

Technologies(ICT)
Supervised by:
DR. Avinash Utam Mungur
June 2021
Dissertation Declaration Form
On submission of my dissertation to the UoM, I solemnly declare that:
a. I have read and understood the sections on “Plagiarism and Fabrication

and Falsification of Results” found in the University’s Regulations
Handbook (2020/2021) and certify that the dissertation embodies the
results of my own work.
b. I have submitted a soft copy of my dissertation through the Turnitin
Platform.
c. I have adhered to the “Harvard system of referencing” or a system
acceptable as per “The University of Mauritius Referencing Guide” for
referencing, quotations and citations in my dissertation. Each
contribution to, and quotation in my dissertation from the work of other
people has been attributed, and has been cited and referenced.
d. I have not allowed and will not allow anyone to copy my work with the
intention of passing it off as his/her own work.
e. I am aware that I may have to forfeit the certificate/ diploma/ degree in
the event that plagiarism has been detected after the award.
f. Notwithstanding the supervision provided to me by the University of
Mauritius, I warrant that any alleged act(s) of plagiarism during my stay
as a registered student of the University of Mauritius is entirely my own
responsibility and the University of Mauritius and/or its employees shall
under no circumstances whatsoever be under any liability of any kind in
respect of the aforesaid act(s) of plagiarism.
Emmanuel Jeremie Daniel
28/06/21
Turnitin Digital Receipt
Dissertation Supervisor Statement
Table of Contents
Acknowledgement vi
Abstract vii
List of Figures viii
List of Tables x
List of Abbreviations xi
Preface xii
1 INTRODUCTION 1
1.1 Problem Statement 1
1.2 Aims and Objectives 1
1.3 Project Scope 2
1.4 Methodology 2
1.5 Project Timeline 3
2 BACKGROUND STUDY 3
2.1 Research on Existing Systems with a Critical View 4
Research paper 2.2.1: QUIC and TCP: A Performance Evaluation 4
Research paper 2.2.2: A First Look at QUIC in the Wild 6
Research paper 2.2.3: Perceiving QUIC: do users notice or even care? 7
Research paper 2.2.4: How quick is QUIC? 9
Research paper 2.2.5: A QUICK Implementation for ns-3 10
Research paper 2.2.6: 0-RTT Attack and Defense of QUIC Protocol 11
Research paper 2.2.7: QUIC Protocol Performance in Wireless Networks 12
Research paper 2.2.8: The QUIC Transport Protocol: Design and Internet-Scale
Deployment 14
1
Research paper 2.2.9: Game of Protocols: Is QUIC Ready for Prime Time
Streaming? 15
Research paper 2.2.10: Assessing the Impact of QUIC on Network Fairness 17
Research paper 2.2.11: Observing the Evolution of QUIC Implementations 18
Research paper 2.2.12: QUIC: Better for what and for whom? 19
Research paper 2.2.13: Implementation and Performance Evaluation of the

QUIC Protocol in Linux Kernel 21
Research paper 2.2.14: How Good Is QUIC Actually? 23
2.2 Systematic Review 24
2.2.1 Background-Qualitative Evaluation 25
3 ANALYSIS 29
3.1 Description of System 29
3.2 Functional Requirements and Non-Function Requirements 29
3.2.1 Functional Requirements 30
3.2.2 Non-Functional Requirements 30
3.3 Proposed Solution 31
3.4 Evaluation of Tools/Approaches-Pros and Cons 32
3.4.1 Programming Language 32
3.4.2 Integrated Development Environment (IDE) 34
3.5 Choice of Final Tools Approached with Justifications 36
3.5.1 Programming Language 36
3.5.2 Integrated Development Environment (IDE) 36
3.5.3 Tools 36
3.6 Software Modelling: Use Case Diagram 37
4 DESIGN 39
4.1 Design Issues 39
4.1.1 Portability 39
2
4.1.2 Security 39
4.1.3 Performance 40
4.1.4 Robustness 40
4.1.5 Flexibility 40
4.1.6 Quality of Service 40
4.2 Architectural Design 40
4.2.1 QUIC Layers of OSI Model 41
4.2.2 QUIC Structure 41
4.2.3 QUIC Layers 43
4.2.4 QUIC and TLS interactions 43
4.3 System Modelling 44
4.3.1 Authentication Flowchart Diagram 45
4.3.2 Sequence Diagram 46
4.3.3 State Transition Diagram 48
5 IMPLEMENTATION 51
5.1 Developments Tools and Environment Used 51
5.1.1 Hardware Specifications 51
5.1.2 Software Specifications 52
5.2 Standards and Conventions 52
5.2.1 Naming Conventions 52
5.2.2 Coding Conventions 53
5.3 Implementation of Different Modules 53
5.3.1 Certificate Compression Module 53
5.3.2 Key Update Module 58
5.3.3 Speed up Handshake Module 61
5.4 Difficulties Faced and How They Were Addressed 63
5.5 Implementation Issues 64
3
5.6 Building Issue with quiche 64
6 TESTING 67
6.1 Unit Test 67
6.1.1 White Box Testing 67
6.1.2 Black Box Testing 67
6.2 Test Cases 67
6.2.1 Running Client Against a Local Server 68
6.2.2 Taking Data from Wireshark 70
6.2.3 Certificate Compression 72
6.2.4 Key Update 73
6.2.5 Speed up Handshake 73
6.2.6 Loss Recovery Failures 74
7 EVALUATION 75
7.1 Quantitative Evaluation 75
7.1.1 Original Traffic 75
7.1.2 Certificate Compression Traffic 77
7.1.3 Key Update Traffic 79
7.1.4 Speed up Handshake Traffic 81
7.1.5 Difference Between Each Test Case 83
7.2 Qualitative Evaluation 84
7.2.1 Evaluating Functional Requirements 84
7.2.2 Evaluating Non-Functional Requirements 85
7.2.3 Discussion About Each Non-Functional Requirements 86
7.2.4 Qualitative Evaluation of Identified Criteria 87
7.2.5 Loss Recovery Failure 89
7.3 Issues Faced during Evaluation 90
7.4 Critical Analysis 91
4
7.4.1 Strengths 92
7.4.2 Weaknesses 92
7.5 Domain Recommendation 92
8 CONCLUSION 95
8.1 Achievements 95
8.2 Difficulties 95
8.3 Future Works 96
LIST OF REFERENCES 98
5
Acknowledgement
I really wish to thank my supervisor Dr. Avinash Utam Mungur for letting
me propose this title as Final Year Assignment and accepted to supervise this
project. I would like to extend my sincere gratitude to him for the continuous
support and assessment for every step taken during this project’s timeline.
Secondly, I would like to express my special thanks to Mr. Loganaden

Velvindron who vouched for me when proposing this project title and he
helped me get into QUIC protocol, get into IETF and mostly get into the world
surrounding Linux. Without him, I would never be doing this project or being a
Computer Science Student. He acted like a surrogate father to me, helping me
get through the adult world as well as the IT world.
Afterwards, I would like to thank the members of my family who have

encouraged me to continue doing a great job in every of my task/project. Their
support meant a lot to me, especially my mom who paid for my studies and
helped me become who I am even if she is retired.
A special thanks to my girlfriend who was here to encourage me and

help me stay focus.
I would also like Alessandro Ghedini, who is a System Engineer at

Cloudflare, to give me the opportunity to work on quiche.
A special thanks to my friends who encouraged me and stayed by me

side while working on this project.
Thanks to ISOC for supporting me during the AIS hackathon.
6
Abstract
In this project, QUIC will be described and how it may play a better role than
TCP in the future. An implementation of QUIC, named quiche, will be used to
implement three new modules and an experiment will be provided to show
how it affects quiche. The new modules will provide a better performance in
speed and keeping the security aspect of the quiche untouched. However, by
using TLS 1.3 in this project, it will provide the security aspect of TLS 1.3 in
quiche. The three modules implemented are Certificate Compression, Key
Update Mechanism and Speed up Handshake Mechanism. These modules
will greatly help quiche for a better performance in time. During this project,
after implementing the three modules, an experiment will be done to test
whether the goals of this project was achieved.
After the experiment was done, the result obtained shows that the goals were
achieved. Afterwards, an explanation about each module and how they
affected the functional and non-functional requirements was provided.
Moreover, a domain recommendation was given so that other implementation
of QUIC could use the modules implemented. Following the evaluation,
achievement and difficulties of the project was discussed and the future works
that may provide quiche a better performance is discussed.
7
● List of Figures
Fig 1. 1: Project Timeline 3

Fig 2. 1: Experiment Factors 5
Fig 2. 2: Research Paper Names - Key 25
Fig 2. 3: Research Paper Evaluation Metrics - Key 25
Fig 3. 1: Use Case Diagram interactions of the User with the system 38
Fig 4. 1: QUIC protocol architecture (CC = Congestion Control) 41
Fig 4. 2: QUIC Structure 42
Fig 4. 3: QUIC layers 43
Fig 4. 4: QUIC and TLS interactions 44
Fig 4. 5: server and client session 45
Fig 4. 6: 1-RTT 46
Fig 4. 7: 0-RTT 47
Fig 4. 8: TLS client handshake 49
Fig 4. 9: TLS server handshake 50
Fig 5. 1: Compilation of quiche 65
Fig 5. 2: Error when compiling 65
Fig 5. 3: Fix for compiling quiche 66
Fig 6. 1: index.html in the server root 68
Fig 6. 2: Server works text in index.html 68
Fig 6. 3: Server running 69
Fig 6. 4: Testing 1st method if the server is running 69
Fig 6. 5: Testing 2nd method if the server is running 70
Fig 6. 6: Loopback filter 70
Fig 6. 7: QUIC Packets recorded 71
Fig 6. 8: QUIC Packet Timestamps 72
Fig 7. 1: Original Traffic 76

Fig 7. 2: Certificate Compression Traffic 78
8
Fig 7. 3: Key Update Traffic 80
Fig 7. 4: Speed up Handshake Traffic 82
Fig 7. 5: Chart representing the difference between each test case and the
original traffic 83
Fig 7. 6: L1 89
Fig 7. 7: C1 89
●
●
9
● List of Tables
Table 2. 1: Systematic review 26

Table 3. 1: Functional Requirements 30
Table 3. 2: Non-Functional Requirements 31
Table 3. 3: Programming languages 34
Table 3. 4: Integrated Development Environment 36
Table 5. 1: Laptop Specifications 51
Table 5. 2: Software Specifications 52
Table 6. 1: Test Case 1 72
Table 7. 1: Original Traffic 75
Table 7. 2: Certificate Compression Traffic 77
Table 7. 3: Key Update Traffic 79
Table 7. 4: Speed up Handshake Traffic 81
Table 7. 5: Evaluating Functional Requirements 84
Table 7. 6: Evaluating Non-Functional Requirements 85
Table 7. 7: Domain Recommendation 93
10
List of Abbreviations
Abbreviation Description
BBR Bottleneck Bandwidth and Round-trip propagation

time
CC Congestion Control
FEC Forwarding Error Correction
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IDE Integrated Development Environment
IETF Internet Engineering Task Force
IP Internet Protocol
IXP Internet Exchange Point
LAN Local Area Network
PLT Page Load Time
PSK Pre-Shared Key
PTO Probe TimeOut
QUIC QUIC UDP Internet Connections
RFC Request for Comments
RTT Round-Trip Time
TCP Transmission Control Protocol
TLS Transport Layer Security
UDP User Datagram Protocol
11
Preface
This project is divided into eight main phases.
Phase 1: Introduction
This phase gives an overview of the project issues that are tackled. It also
includes the aims and objectives, the scope of this project and the project
timeline.
Phase 2: Background Study
This phase consists of the research made on QUIC and the criteria obtained
will be put in table of criteria.
Phase 3: Analysis
This phase consists of the functional and non-functional requirements of the

project as well as the appropriate tools to be used. The description of the
system will be provided and the proposed solution will be explained as well.
Phase 4: Design
This phase consists of the design issues and the architecture of the system.
The structure, architecture and other architectural design will be explained.
Phase 5: Implementation
This phase will provide the hardware and software specification and the
standard and convention used will be discussed. The modules implemented
will be provided as well as an explained.
Phase 6: Testing
This phase consists of the tests to be carried out on the modules implemented
and how the tests were done.
Phase 7: Evaluation
12
This phase consists of the results that were obtained after the testing process
and the results will be explained. The results obtained will be used to compare
the functional and non-functional requirements, written in phase 3. Moreover,
the criteria gotten in the phase 2 will be assessed against the new
implemented modules. The strengths and weaknesses will also be discussed.
The domain recommendation will be given at the end of this phase.
Phase 8: Conclusion
This phase consists on the achievements and difficulties of the project and
how the project concluded with the results obtained. Afterwards, the future
works for improving quiche will be discussed.
13
1 INTRODUCTION
QUIC is a new transport layer network protocol that is designed and
implemented by Google and IETF and each has a different version of QUIC.
QUIC was designed to improve the performance and outperforms TCP in
connection establishment and with web apps. In this chapter, the problem
having with the currently used transport protocol, namely TCP, will be
explained and how QUIC will replace it. The aims and Objectives of this
project and how it will be managed to accomplish the objectives will be
discussed. Also, a project timeline will be given at the end of this chapter.
1.1 Problem Statement
For the past years, QUIC was designed to be faster than TCP and is
somewhat statically true as nearly all the research paper reviewed in chapter
2(Background Study). QUIC is a new transport layer network protocol that
takes TCP, adds the latest TLS 1.3 encryption and establish a better, more
secure and faster connection. QUIC was originally created to replace TCP/IP
as it has several advantages over TCP/IP. QUIC’s connection establishment is
faster and most of the time will not require any acknowledgement from the
server if a connection has already been established before. Even if QUIC is
mostly faster than TCP, QUIC is being worked on to be faster than ever
without reducing the security properties of QUIC. Nowadays, webpages are
becoming heavier and heavier with all the items it contains meaning a longer
wait time to open a webpage. Our solution, to this problem or future problems
with waiting time, is QUIC and implement new extensions to QUIC making it
quicker.
1.2 Aims and Objectives
1
Aims
The aim of this project is to provide quiche with the missing functions to make
QUIC send and receive packets at a faster rate and to implement them so that
they are reliable and efficient to the system.
Objectives
1. Implement the Certificate Compression for QUIC.

2. Implement the key update mechanism.
3. Implement the mechanism to speed up handshake completion.
4. Investigate loss recovery failures during the handshake.
1.3 Project Scope
This project’s scope is to implement at least 4 extensions into quiche, which is

the implementation of Cloudflare's QUIC implementation. Most of the
implementation will be done in the “tls.rs'' file. This project consists of making
the first 3 extensions to make QUIC faster keeping its security aspects and
analyses any loss recovery failures during the handshake.
1.4 Methodology

Write the functions for compression and decompression in the file
“tls.rs” found in “quiche/src/”. The documentation for the codes is found
in the RFC 8879 which helps with the compression algorithm. Some of
the functions already defined in Boringssl.

After the handshake is confirmed, an endpoint may initiate a key
update. The function for the key update will be written in the “tls.rs” file
same as Cert Compression. This function is not found in Boringssl but
2
can be written using TLS’s KDF function (used to update write keys with
TLS 1.3).

The function for the speed up handshake completion is also written in
the “tls.rs” file. A function that will send a packet that contains all
unacknowledged CRYPTO data earlier than the PTO (Probe Timeout)
expiry. This function will need to be written from scrap using the
CRYPTO library.

Look into the loss recovery failures during handshakes. It was found out
that quiche fails the “L1” and “C1” test in this link:
https://interop.seemann.io/. Test for “L1” and “C1” have to be done
again then provide the fixes and improvement to the loss recovery code
if it turns out to be quiche’s fault.
1.5 Project Timeline
For a project to succeed properly, the project manager has to schedule all the
steps from start to finish. Below is a detailed timeline for the project’s schedule
that was set up so that the project could move along at a constant speed.
Fig 1. 1: Project Timeline
3
4
2 BACKGROUND STUDY
This is the section where all the research works will be discussed and
emphasis on all the research works done on QUIC will be done and the
breaking down and studying of the 14 research papers is done below and for
each research paper, a critical analysis is provided. This will help us
understand the project better and help us to evaluate the implementation later
on.
2.1 Research on Existing Systems with a Critical

View
In this part, several research papers, which are expanded essays that consists
of explanation, analysis and argument on the topic named QUIC, will be
summarised. The methodology used, the results gained and critical analysis
will be provided in a summarized form.
Research paper 2.2.1: QUIC and TCP: A

Performance Evaluation
Identification Process
In this research paper, Nepomuceno et al. write about how TCP differs from QUIC
and tested both protocols by comparing the page load time from several websites.
From this experiment, they also observed if the new protocols meet the demand of
the internet at that time and if it works as designed originally.
They have taken a set of popular websites from Alexa top sites and run several
combinations to test the different configurations such as testing packet loss ratio
between 0% and 2% or testing RTT values between 20ms and 200ms. Then they
observed the HTTP archive record information to get what actions were performed in
the loading of the pages. The disk cache was also turned on and off for the testing.
5
For an average result, each combination was done 30 times for every single
page(Nepomuceno et al., 2018). Table 1 shows all the configurations used for the
experiment.
Fig 2. 1: Experiment Factors
Significance of Results and Critical Analysis
The results obtained from the experiment are given and discussed by Nepomuceno
et al. The main goal was to observe the difference between the QUIC and TCP
protocols, so they plotted a graph with the different combinations. They derived an
equation from y =mx +c to plot the graph. They draw 2 graphs with the combination of
the event onLoad with and without cache and 2 more graphs with the combination of
the event onContentLoad with and without cache. As they observed from the 4
graphs, TCP performed better on at least 60% but QUIC had also better page load
time than TCP. They observed that the configurations used have a great impact on
the results gained. For some pages, with varying cache and for onContentLoad
events, they observed that QUIC was performing better than TCP. They made a
boxplot from the results using the metric onLoad event without cache. From the
boxplot, they saw that the RTT variation has a significant impact on the page load
time metric. They used the factors of RTT and packet loss ratio to observe the
difference. By fixing the packet loss ratio and varying the RTT in 20ms, 100ms and
200ms, they made an observation that the page load time is faster but when we ﬁx
the RTT and vary the packet loss to 0%, 0.5%, 1%, and 2%, the results were nearly
the same. Meaning that RTT has a great impact on the page load time while the
packet loss ratio is nearly meaningless(Nepomuceno et al., 2018).
Critical Analysis
This study has compared the performance of QUIC vs TCP to note the better one.
The most accessed pages were used under several configurations to evaluate the
6
performance of the protocols. QUIC has the worst performance under onLoad and
onContentLoad events for several scenarios. As discussed above, varying the RTT
values has a great influence on the experiment for QUIC while varying the packet
loss ratio value was nearly not noticeable. Despite the fact that QUIC is already being
used in part of the internet, there are still some improvements needed. Still, QUIC is
faster when creating connections to the server while TCP is time-consuming but
QUIC loses time when reading the server’s answer. Also, the reason why TCP overall
results were better than QUIC is that the accessed pages in this experiment were not
structured in a way that could be better for QUIC to perform. Most pages are not
necessarily optimized for QUIC yet and QUIC is still adapting.
Research paper 2.2.2: A First Look at QUIC in

the Wild
In this research paper, Rüth et al. talk about how it has been hard to update the
internet transport layer protocol and that optimizing latency and providing encryption
has been very hard to update. They also talk about how Google’s Quick UDP Internet
Connections (QUIC) protocol is similar to TCP but yet it still has other features better
than TCP such as stream multiplexing over a single connection. Also, QUIC will fully
encrypt at the transport layer level, providing security and excluding middlebox
optimizations. Yet there are still a limited number of tools supporting the analysis of
QUIC. Rüth et al. carry out an experiment about the QUIC deployment and its traffic
share. In this experiment, they identified QUIC hosts that are QUIC capable IPs
meaning that a valid version negotiation packet or a QUIC public reset packet is
received. QUIC hosts also can support multiple versions. They developed a tool that
finishes the handshake and enables to further classify hosts and infrastructures. After
that, they studied how QUIC support reflects on actual traffic shares. First, they have
analyzed 3 traces that represent different vantage points and choose 3 different
factors to observe the traffic shares namely HTTPS, HTTP and QUIC. Then they
observed Netflow traces from European Tier-1 ISP for the different factors on Google,
Akamai and other servers. They also gained information on a large European IXP
7
with the same factors. Lastly, They have published tools that Enumerate QUIC hosts
and grab and decode QUIC protocol parameters(Rüth et al., 2018).
The result for the analysis for the deployment of QUIC is that there are a small
number of providers using and experimenting on QUIC, there is not a big number of
domains that QUIC capable and a lower number of domains returns valid certificates.
Even so, there is an increasing number of domains having QUIC support. Then they
have searched for QUIC support on the IPv4 space which resulted in a growing
adoption on a large number of IPs supporting QUIC since October 2017. They also
searched on different domains as well as Alexa top sites. Then for the result for the
view on traffic shares from 3 different vantage points for QUIC, they found that within
nine months after QUIC was activated by Google, QUIC traffic share was increasing
slowly. QUIC traffic shares do not yet reflect server support. QUIC traffic is mostly
served by Google servers(Rüth et al., 2018).
Critical Analysis
As explained above, after nine months that QUIC was deployed by google, QUIC was
getting used and experimented with. When they searched the entire IPv4 address
space, they found out that there was an increasing number of QUIC-enabled IPs and
this kept on increasing. It can also be deduced that this growth was driven by Google
and Akamai servers. Google accounts more on traffic share for QUIC than Akamai
despite having a large number of QUIC-capable users. It can be deduced that QUIC
traffic share will obviously increase in the future as shown in this research paper.
QUIC is still under development but it can be observed that it is increasing in
popularity.
Research paper 2.2.3: Perceiving QUIC: do

users notice or even care?
8
In this research paper, Rüth et al. talks about how QUIC was made to be better in
performance, security and how it progresses more than TCP. They also talk about
Chromium’s Google QUIC uses packet pacing and an initial congestion window of 32
segments. They also say that QUIC gives new levels of protocol customization and
progress. So they ask themselves if QUIC impacts the Quality of Experience and if
changing from TCP to QUIC is noticeable for humans. In this paper, they will answer
these questions in two user studies. First, they modified the Mahimahi framework to
have control on network parameters. Then they used their testbed using Chromium
browser with an empty cache. They took sites from Alexa top sites, chose four
different network settings namely DSL, LTE, DA2GC and MSS, and they recorded
videos of their test at least 31 times to replay them and derive technical and visual
metrics for their experiment. For the first study, they ask if the user notices the
protocol switch, so they recorded two videos of loading of the same website with
different protocol configurations to some contestants. For the second study, they ask
if users still care about the quality of the loading process of a webpage, so they let the
contestants rate the recorded video to see if they are satisfied with the loading speed
and the quality of the loading process(Rüth et al., 2019).
When they used Chromium browser with an empty cache, there was no support for
TLS1.3 in Chromium which is a 0-RTT connection establishment but had a 1-RTT
connection which is an advantage for QUIC. This advantage is a primary factor that
outperforms the traditional Web stack which is faster than TCP. So, to answer the first
study’s question, most contestants do not see a difference between QUIC and TCP
for DSL setting and for LTE also. For DA2GC, QUIC was faster. So, they concluded
that people saw a difference and QUIC was faster than TCP. For the second study’s
question, they saw only little variance between the protocols but observed that
QUIC+BBR is more satisfying than TCP+BBR. They also specify that QUIC without
BBR is generally faster than TCP. Afterwards, they talk about the studies saying that
the participants did not care about the protocol even if QUIC was the preferred
protocol for some(Rüth et al., 2019).
Critical Analysis
9
After reading this research paper, it can be seen that QUIC was the preferred
protocol even for a little percentage of participants. For the first study, QUIC
outperformed TCP, meaning that the participants have eventually seen the difference
in speed and performance. For the second study, they observed that the difference is
negligible and that users do not distinguish which protocol is faster. Still, some people
prefer QUIC. Even though if QUIC evolves, user satisfaction will not radically
increase. QUIC is not only for speed but for enhanced security and future proof
design that will perform better in the future.
Research paper 2.2.4: How quick is QUIC?

In this research paper, Megyesi, Krämer and Molnár explain how nowadays the
Internet is widely used and that we service providers are working hard to provide
better web page transfers. Newer technologies are created from HTTP 1.1 to HTTP/2
and now QUIC which uses UDP in the transport layer. The goal of this research paper
is to find out the performance of QUIC compared to HTTP 1.1 and SPDY. They
explain the limitations of HTTP 1.1 with example and also talk about the studies they
made on SPDY performance vs HTTP and QUIC vs HTTP and finally QUIC vs SPDY.
Afterwards, they explain the limitations and how TCP outperforms in certain areas.
Then, they talk about an important goal that QUIC needs, which is reducing the
latency of web traffic. QUIC uses a new encryption mechanism that supports the
round trips between client and server during connection establishment and replaces
SSL or TLS without any loss of security measures. QUIC can make the client achieve
0-RTT when a connection with the server was made before. Meaning that the extra
round trip that TLS takes is not required, and QUIC implements the new encryption
that resembles DTLS. For congestion control, QUIC presented a new feature called
packet pacing and shows that it can reduce congestion and can hinder performance
in a low-loss network environment(Megyesi, Krämer and Molnár, 2016).
After the experiment of QUIC against SPDY and HTTP, they shared the result
regarding the speed of downloading installed pages from the Google Sites server.
10
They shared some scenarios with the best results that captured the pros and cons of
the three protocols named. There were 6 different cases, where bandwidth, packet
loss RTT and object number values were varied, to test the page load time for QUIC,
SPDY, and HTTP, and this data was plotted in a graph. For a smaller number of large
objects and for a high number of small objects, it is shown that the three protocols
were comparable. For large websites and with high bandwidth it be can clearly shown
that QUIC performs worse than SPDY and HTTP. With a higher percentage for
packet loss, SPDY performs worse than the two others. Afterwards, they shared the
results with the settings that QUIC outperforms both SPDY and HTTP. The common
settings used for the three cases were high RTT and a high number of small
objects(Megyesi, Krämer and Molnár, 2016).
Critical Analysis
For low numbers of large objects and high numbers of small objects, the three
protocols give similar results. For higher bandwidth, QUIC performed badly because
of the packet pacing mechanism. QUIC performs badly when facing very high-speed
links and large amounts of download data. But when there are a high number of small
objects and a high RTT, QUIC performs the best and is the fastest protocol being
roughly 25-30% faster than SPDY and 35-40% faster than HTTP. It can also be said
that QUIC works best with low bandwidth.
Research paper 2.2.5: A QUICK Implementation

for ns-3
In this research paper, Alvise De Biasio et al. talks about how QUIC addresses some
issues that the TCP protocol had. As shown in other research papers, QUIC is said to
use UDP to avoid issues regarding middleboxes in the network. They also mention
that QUIC is not integrated in the OS, so the user does not have to update the OS
several times, QUIC is actually into the userspace. Another advantage that was
mentioned in other research papers is that it reduces the initial handshake delay. The
main goal of this research paper is to implement QUIC for ns-3 and to show how it is
11
easy to use and how it can be compared different congestion control designs of
different protocols. They also describe some of the main features in QUIC such as it
is designed to support multiplexing so several data streams over a single connection,
therefore meaning that the packet will certainly be delivered if any of the streams are
affected by packet loss. QUIC also uses the functionalities of TLS 1.3. Additionally,
they tell us about the main features of QUIC that will be supported in ns-3, after that
they describe the code used to implement QUIC in ns-3 and define any classes and
functions they wrote. For QUIC Headers, Packets and Frames, they already made the
necessary class and used some built-in functions. For Congestion Control, they made
use of TCP Congestion functionalities. Before testing, since some features for QUIC
are not yet available, they decided not to implement any missing features that are in
the QUIC internet drafts(Alvise De Biasio et al., 2019).
They then tested the simulation with QUIC implemented. They check the correctness
of the behavior of the socket and stream transmission buffers. There were some
problems with the insertion of events from the buffer. Another test made, they
observed the performance of addition and removal of operations on the reception
buffers of the socket and stream. Lastly, the third test made was to observe the
correctness of the QUIC header and subheader implementations. Furthermore, they
tested the functionality of stream multiplexing. Additionally, they found out that the
QUIC congestion control and the NewReno’s one shared similar trends, both having
a faster window ramp-up during the congestion avoidance phase(Alvise De Biasio et
al., 2019).
Critical Analysis
In this research paper, it is found how QUIC is implemented in ns-3 and how QUIC
works with stream multiplexing, low-latency initial handshake, and improve SACK with
ACK frames. On top of that, they designed QUIC socket implementation to plug both
the TCP and new QUIC congestion control algorithms.
12
Research paper 2.2.6: 0-RTT Attack and Defense
of QUIC Protocol
In this research paper, Cao, Zhao and Zhang talk about a new transport layer
protocol named QUIC which provides security functionalities similar to TLS. QUIC
also provides the shortest round-trip delay for connection establishment and for
recovery and packet loss retransmission. They also tell us that most research done
on QUIC is mostly concerned with performance than security. QUIC has implemented
measures to prevent replay attacks, a dynamic mechanism that confirms the peer
identity and a timestamp. Then, they provide more information about the security part
of the protocol. They investigate the differences between QUIC and other protocols to
found out vulnerabilities of QUIC for the different version updates. They compared
QUIC with TCP and UDP on different aspects namely packet structure, connection
establishment, connection release, congestion control and version negotiation. They
propose a new attack named 0-RTT attack that will refuse service to a client that has
not established a connection by forging the data packet. Afterwards, they try three
different experimental environments for the attack scenarios. Furthermore, they
experiment on types of attacks namely QUIC RST and Version Forgery, and they
explain the steps taken to reach that goal(Cao, Zhao and Zhang, 2019).
They observed that QUIC does not provide protection during the connection
establishment for the client but after the connection establishment, QUIC gives
adequate protection. Since QUIC uses UDP, it needs less handshake thus the client
is vulnerable to attacks. They provide advice for preventing this problem and tell us
that LAN is a must for the environment of attack. They also mentioned that QUIC had
a defect that could make the client disconnect, meaning the attack of the forge packet
can be easily succeeded.
Critical Analysis
13
As it is shown, this research paper focuses mostly on the security part of QUIC and
the authors of this paper prove that the 0-RTT attack can be feasible for the client’s
first connection establishment. But for the server-side, the connection is safe.
Research paper 2.2.7: QUIC Protocol

Performance in Wireless Networks
In this research paper, Kharat et al. talk about the future for IP traffic usage and how
IP-enabled devices grow fast. QUIC over UDP will be used as an alternative for
HTTP/2 over TCP/IP and the QUIC protocol is still left unexplored for the wireless
connection domain. So, the aim of Kharat et al. is to explore the wireless connection
domain and the properties that lie in QUIC and they also provide a proposal for the
Forward Error Correction to ameliorate the congestion control, retransmission
latencies and throughput of the connection. Before the testing section, they provided
us with a background study on HTTP/2 over TCP/IP and QUIC over UDP. They also
give an insight on UDP fundamentals and on the QUIC protocol. An amazing
advantage of QUIC is that after a successful connection between a server and a
client, the client can achieve 0-RTT by using a connection ID that is found in every
packet. Afterwards, the congestion control mechanism is also explained as well as
the Forward error correction and retransmissions. After the description of all the
functionalities above they did an experiment to examine the improvement of QUIC
when put in a low BCP network and fairness in a wireless environment. They used a
MacBook Pro laptop to undergo the experiment to test competing flows serviced by
both QUIC and HTTP/2(Kharat et al., 2018).
After the experiments, they found out that QUIC is better than TCP/IP, especially for a
single dominant QUIC flow. Since QUIC uses multiplexed UDP streams, this causes
a fall in speed measured in throughput and speedup of QUIC. However, they found
out that QUIC achieves lower with multiple competing flows but TCP/IP achieves
better throughput. They also concluded that a dominant QUIC flow improves
14
throughput and overall speedup of a wireless connection. Since the experiment was
in a wireless environment, the percentage of packet loss was significant. QUIC
showed that it had potential since the UDP protocol does not require changes(Kharat
et al., 2018).
Critical Analysis
Nowadays it can clearly be seen that video streaming is especially used, so the QUIC
protocol is critically important here. The experiment they made showed that QUIC is
nearly 50% better than TCP/IP in unrestricted flows for wireless video download.
Since QUIC uses 0-RTT for a client already connected to the server, this means that
a wireless connection achieves low response time.
Research paper 2.2.8: The QUIC Transport

Protocol: Design and Internet-Scale Deployment
In this research paper, Langley et al. talk about QUIC replaces most of HTTPS such
as HTTP/2, TLS and TCP. They also mention that UDP allows QUIC packets to go
through middleboxes and this prevents the modification and limiting ossification by
middleboxes. As described in most of the research papers, they also talk about the
minimization of handshake latency and about the multiplexed streams over a single
connection. In this paper, they make use of the pre-IETF QUIC design and
deployment. The authors explain in detail why use QUIC with some main points such
as Protocol Entrenchment, Implementation Entrenchment, handshake delay and
head-of-line blocking delay. Afterwards, they talk about the QUIC design and
implementation. First, they explain carefully how the connection is established for the
first time and after a connection has already been established. Then, they explain
how stream multiplexing works in QUIC and how it is better than TCP’s. After that,
they explain the authentication and encryption for a packet in QUIC and they talk
about the loss recovery and how the packet is retransmitted. The authors also explain
the flow and congestion control in QUIC as well as NAT rebinding and connection
migration, QUIC discovery for HTTPS and finally about the opensource
15
implementation. After all the explanation, they experimented heavily on QUIC’s
features and various parameters. They mentioned that they used Chrome to undergo
the QUIC experimentation and they also mentioned that they added the QUIC
support to their mobile video and search apps. After the experimentation, they
described the road they took to deploy QUIC globally since 2013. Then, they shared
the performance of QUIC with the YouTube mobile app and google searches such as
the search and video latency.
The authors shared their results with us for the experiment done such as the usage of
forwarding error correction(FEC) and also the deployment of QUIC. The packet size
was determined to be 1350 bytes as default. FEC had a significant impact on search
and video latency and also on video rebuffer rate. Since QUIC is deployed on user-
space and not on the kernel, people can freely interact with other systems in the
server. Updates for QUIC such as security fixes are easier to update and also to play
with.
Critical Analysis
It can be said that one of QUIC’s best features is that it can be used as a platform for
experimental purposes for both server and client. It is found out that working and
deploying in the userspace is very beneficial as it makes testing faster and easier. It
can also be concluded that FEC works well with search latency as well as video
latency and video rebuffer rate. The IETF work on QUIC will replace QUIC’s
cryptography handshake with TLS 1.3 which will benefit the latency of QUIC’s
handshake.
Research paper 2.2.9: Game of Protocols: Is

QUIC Ready for Prime Time Streaming?
16
In this research paper, Arisu, Yildiz and Begen explain that the aim of this new
protocol named QUIC is to reduce the connection establishment latency, improve the
congestion control, give us multiplexing streams and encryption at the transport level.
They also refer that QUIC is replacing most of the HTTPS stack such as HTTP/2, TLS
and TCP. In this paper, they study how the feature of multiplexing stream is
beneficial, especially that nowadays people watch videos mostly and do not like
buffering. They also measure the fairness of TCP and QUIC clients when competing
with other clients. The first question they want to answer is how QUIC’s multiplexing
streams perform against HTTP/1.1 over several connections and HTTP/2 over a
single connection for random losses and network delay. The second question they
attempt to answer is how the fairness of TCP and QUIC clients when competing with
other clients with different amounts of losses and delays. Beginning with the
experiment, first, they made some modifications to the python-based player for a fair
comparison of QUIC against TCP. They explained the setup they used to test QUIC
an example can be the QUIC server that is provided by Google. Afterwards, they
explained the approach they use to evaluate the performance of HAS applications
over QUIC and TCP for several frame-seek events then they installed a script at the
client machine for the evaluation of QUIC’s performance against network
disconnection and reconnection. Furthermore, they evaluated the QUIC’s multiplexing
feature and finally how QUIC provides fairness in a controlled environment(Arisu,
Yildiz and Begen, 2020).
For each test, they repeated the experiment 10 times for no anomalies. So, they
found out after testing for the frame-seek scenario that QUIC has a shorter average
wait time after seeking and that the media streams started faster. Compared to TCP,
QUIC reduced the wait time by nearly 50% and also reduce the rebuffer rate. For the
connection-switch scenario, they tested that when a user’s WiFi connection fades
away, the mobile disconnect to the active connection through WiFi, then creates a
new one through LTE or 3G mobile network. So, they found out that when a long-
lived connection that had a large congestion window is lost, the client will endure a
low throughput till the handshake and any slow-start phases are completed. Based on
their experiments, they concluded that QUIC increased the congestion window faster
and that it is able to achieve higher throughput. QUIC provides faster download for
17
the segments, meaning that media streams faster. Now for multiplexing, QUIC was
found mostly better than HTTP/1.1 and HTTP/2, especially for the large delay and
typical loss scenarios. For the evaluation of fairness, they found out that QUIC
provides fairness among multiple QUIC flows in every case.
Critical Analysis
It can be concluded that QUIC when streaming, is faster than TCP. QUIC
performance is better when frequent IP changes since QUIC makes use of a unique
Connection Identifier, this makes QUIC fast for switching of IP. This feature will make
the user have no idea that the device changed networks. Even though CID was not
used in the authors’ test, the results came out that QUIC outperformed TCP for
average playback bitrate and rebuffer rate during IP changes. It is also found that for
long delays in the network, QUIC provided higher playback bitrate and lower rebuffer
rates. Finally, it can be said that QUIC provided fairness among QUIC flows. QUIC
will eventually become a prime interest for video streaming.
Research paper 2.2.10: Assessing the Impact of

QUIC on Network Fairness
In this research paper, Corbel et al. explain the fairness issue that several protocols
still raise. They mention that network operators want to satisfy their customers by
sharing the available resources fairly according to their needs. They also say that
QUIC is much better than TCP when deploying a modification for QUIC since QUIC is
within user-space and at the application layer. They also shared a diagram that
demonstrates how QUIC transports multiple streams in a single UDP flow. In this
paper, the authors want to find out the difference between QUIC and TCP flows by
varying the number of TCP emulated connections within QUIC in order to assess the
impact of this number on network fairness. They also give us an insight into the
background of QUIC and CUBIC. They mentioned that the behavior of the congestion
window is impacted by the number of emulated TCP connections which then gives us
the allowed data rate. They vary the number of emulated TCP connections to gain
different results on congestion window size. They also mentioned that the larger the
18
number of emulated TCP connections, the faster the congestion window size
increases(Corbel et al., 2019).
First, they assumed that both QUIC and TCP use CUBIC as CCA for the experiment.
They used IETF QUIC for their testing. First, they found out that buffer size and
network latency do not affect session fairness. They considered two cases where
they analyzed the impact of fairness, first, a single TCP connection competing with a
single QUIC connection emulating N TCP connection, then, N TCP connections
competing with a single QUIC connection emulation N TCP connections. For the first
case, when the number of emulated TCP connections increase, there are more
unfairness, this is due to how CUBIC is implemented in QUIC, for a large number of
emulated TCP connections QUIC increases the data rate faster. Now for the second
case, QUIC is not able to increase the window size when the maximum is reached
due to the limitation in the QUIC’s CUBIC algorithm.
Critical Analysis
It is found that latency, packet loss and buffer size do not mostly alter fairness. But it
is also found that the number of emulated TCP connections by QUIC’s CUBIC alter
fairness the most. Furthermore, the throughput reached by independent TCP
connections is larger than by a single QUIC connection.
Research paper 2.2.11: Observing the Evolution

of QUIC Implementations
In this research paper, Piraux, De Coninck and Bonaventure talk about how internet
transport protocols are evolving such as TCP getting new extensions or QUIC being
developed for a better protocol. An advantage they mention for QUIC is that it is
implemented in the user space library so that updating is easy. They also mention
that QUIC prevents middlebox interferences. They explain that the IETF QUIC has
19
published fourteen versions. So, in this paper, they explain that their objective is to
provide, publicly, details of the test suite for QUIC. Firstly, they give a description of
the approach and architecture of the test suite. They want to test how QUIC works
and they observe the external behaviors such as the packets sent or received. Their
other objective is also to observe all the specifications of QUIC server-side
implementations. Afterwards, they describe the architecture of the test suite then they
test all the implementation drafts for QUIC(Piraux, De Coninck and Bonaventure,
2018).
The authors did the testing over a 6-month period, then giving the results into three
phases. First, they present the three metrics extracted from the data collected. The
metrics are the deployment of QUIC version, handshake success and the test
outcome percentage. For the deployment of QUIC, they found out that when a new
draft is published, the implementation for the older versions is stopped and even not
maintaining backward compatibility. They concluded that QUIC needs 15days to a
month for changes to be published in a new version of QUIC. For the handshake
success, they found out that there are fluctuations in the graph they plotted, these
fluctuations mean that there is a rapid pace at which changes are deployed. For the
test suite outcome percentage, they found that implementations that are slower to
evolve will have a lower ratio and the most active implementations will have a positive
impact on the ratio. Secondly, they report the case studies. They reported several test
scenarios about the flow control and stream transitions reordering of QUIC. Finally,
they generated a result grid from the available implementations. They observed that
most of the connection migration test were unsuccessful or was not executed(Piraux,
De Coninck and Bonaventure, 2018).
Critical Analysis
In this paper, it can seen that the authors have proposed a test suite for QUIC and
have given the architecture and the test scenarios. For the flow control, they found
that the implementation was incorrect and the developer was not active during that
period. For the stream transitions reordering, there were missing packets due to
overflow but this was a hypothesis so the authors did not release the implementation
20
source code. After each new draft, the previous drafts of QUIC do not get any
updates, and the implementers do not provide backward compatibility.
Research paper 2.2.12: QUIC: Better for what

and for whom?
In this research paper, Cook et al. explain the advantages of HTTP/2 over HTTP/1.1
and how TCP encrypts and how the handshake of TCP work. Afterwards, they
introduce QUIC and how QUIC encryption is comparable to TLS and establish the
handshake in 1-RTT only for the first time. Furthermore, they give more details about
QUIC, the congestion control and they talk about other evaluations of QUIC. In this
paper, the authors give an analysis of QUIC for end-users, network and service
providers. They provide a fast overview of QUIC, then they compare QUIC with
HTTP/1.1 and HTTP/2 on a local testbed so that any network settings can be
changed easily. Their main goal is to evaluate the page load time of websites under
several network settings for the three protocols(HTTP/1.1, HTTP/2 and QUIC). There
are two types of client-server connections for handshaking they will test, they are
namely, first connection and repeat the connection. For the first connection, they will
observe how many RTTs are needed for each protocol. For the repeat connection,
they will observe the loading time and how many RTTs are needed for each protocol
again. Now they test the three protocols on wireless networks or similar lossy
networks with their remote testbed and they used public 4G and ADSL. Afterwards,
they tested the page load time varied in the time of the day where network load was
the greatest on ADSL. The tests were done on the YouTube website. Furthermore,
they did testing on a complex website(YouTube) and a simple website(Doctor) to
observe the page load time(Cook et al., 2017).
For the testing, the authors analyzed QUIC’s performance depending on the access
type network, packet loss and delay generation. The tests were performed on the
21
public YouTube website(local testbed). Different values of delay were tested. For the
first connection, the page load time of QUIC was more than the other protocols but for
the repeat connection, QUIC was only increased by 400ms. For HTTP/2 repeat
connection, it was 5 times more when delay increases. This test showed that HTTP/2
connections were more sensitive to delay and QUIC’s ones were much less sensitive.
Now for different values of loss, QUIC first connection was much sensitive as the loss
percentage was increased but for repeat connection, it showed that it was less
sensitive to different values of loss. For HTTP/2 repeat connection was significantly
much more than QUIC. The tests for different values of loss showed that QUIC
connections are less sensitive than HTTP/2 ones. For the ADSL links, QUIC and
HTTP/2 results were similar and both were better than HTTP/1.1. For the 4G links,
HTTP/1.1 and HTTP/2 results were similar but the QUIC result was better. For the
network load impact on page load time, QUIC and HTTP/2 had a similar result and
were better than HTTP/1.1. QUIC outperformed HTTP/2 in lossy links and this is
mostly because QUIC uses UDP which avoids HOL(Head-Of-Line) blocking issues.
For complex and simple websites, page load time performance is better for a less
complex site(Cook et al., 2017).
Critical Analysis
It can be observed that QUIC will outperform the other protocols in certain conditions
such as in wireless networks or lossy networks. The advantage of QUIC that provides
to end-users is not so obvious since HTTP/2 is nearly comparable to QUIC regarding
the page load time metric. The main difference between QUIC and the other protocol
is that QUIC uses 0-RTT in most case for repeat connections. But the time difference
is not that obvious to end-users.
Research paper 2.2.13: Implementation and

Performance Evaluation of the QUIC Protocol in
Linux Kernel
22
In this research paper, Wang et al. talk about the history of TCP giving details about
how it was designed and how TLS came into place with TCP. They provide a lot of
details on TCP and afterwards, they also give details about the history of QUIC. The
authors provide advantages of QUIC over TCP and also provide some experiments
that were in other research papers. They also mention that TCP is implemented in the
kernel space and QUIC is implemented in user-space. So, in this paper, the authors
implemented QUIC in the Linux kernel and compare TCP and QUIC in the kernel
space. Afterwards, they provide the details about the Linux kernel network subsystem
and also about the steps taken to implement QUIC in the Linux kernel. Firstly, they
register the protocol in the ipv4 files which is quite easy, then they added functions for
QUIC. After that, they defined ports, addresses and sockets so that handshake can
be done or a connection can be established. The virtual box was used on both client
and server machines and the measurements were done by deploying the program in
both virtual boxes. For QUIC and TCP, the experiments were carried out with different
network settings. They also compared the protocols under a wireless environment
using WiFi with different network settings such as RTT and packet loss rate(Wang et
al., 2018).
For the measurement using virtual machines, there are two tests they made. One is
the network throughput against packet loss rate and the other is the friendliness of
QUIC and TCP. For the first one, they find out that QUIC always has a better
performance than TCP and QUIC also may have a higher jitter for low packet loss
rate. Even if both use the same congestion control algorithm, QUIC has shown that it
reaches its peak transmission rate faster than TCP. they mention that QUIC recovers
quicker than TCP even when the initial window collapse for TCP has a larger window
than QUIC. Now for the QUIC and TCP friendliness, they found out that both QUIC
and TCP can share a network bandwidth together when they achieve an average
throughput of nearly 1MBps. For the measurement in a wireless network, they have
two types of experiments they made. The first one is the comparison of the
performance when the packet loss rate is varied in a wireless network and the second
one is QUIC and TCP friendliness in a wireless network. So, for the first one, they
showed that for the first connection and for the rate management of QUIC is far better
than TCP in small data transfer. For low latency and low packet loss rate, QUIC has
23
the fastest handshake protocol. They also found out that QUIC may resend
retransmitted packets once or twice. For large data rates, TCP outperformed QUIC.
For the QUIC and TCP friendliness in a wireless network, the performance of QUIC
and TCP are not stable and TCP shows to have a high throughput than QUIC with
packet loss rates of 0% and 0.1%. But for the 1% packet loss rate, QUIC is a bit
better than TCP(Wang et al., 2018).
Critical Analysis
It is found that QUIC outperforms TCP with all the different packet loss rates they
tested and the average achieved throughput of QUIC is always higher. QUIC also has
better performance with low RTT and high packet loss. Moreover, QUIC and TCP can
share network bandwidth with a high degree of fairness. It is found that QUIC
outperformed TCP with short data packets and it reaches peak data rate faster than
TCP.
Research paper 2.2.14: How Good Is QUIC

Actually?
In this research paper, Burghard and Jaeger explain how QUIC was designed after
the SPDY protocol to improve TCP and TLS. They mention that the goal of QUIC is to
reduce latency and improve performance. Moreover, they provide some details about
the history of QUIC such as who submitted the first draft of the IETF QUIC. They also
mention the difference between IETF QUIC and Google’s QUIC. In this paper, the
authors are focused on the IETF QUIC and for real-world data usage, Google’s
QUIC(gQUIC) will be used since it is only large scale deployment. Afterwards, they
evaluate the strengths and weaknesses of the goals set by the QUIC working group.
The goals are secure transport using TLS 1.3, enable deployment without any need
to change the network equipment, multiplexing without HOL blocking, minimize the
connection establishment and transport latency and finally enable extensions for FEC
and multipath connections. For secure transport, the authors explain how the initial
design of QUIC predated TLS 1.3. They also mention that it can provide better
24
security but still, TLS 1.3 being too secure, constrains bank companies. For enabling
future changes to QUIC, the authors explain that QUIC is built on top of UDP and
most network equipment already supports UDP, also QUIC is implemented in the
user space which can be deployed easily. To prevent ossification, QUIC encrypts
more data to hide it from network equipment. For the HOL blocking, the authors
mention that QUIC supports multiple streams over a single connection and when
packets are lost, recovery only happens in the streams that the packets were lost so it
is not blocked. Also, when a packet is lost, QUIC will not retransmit the packet but it
will check every stream if the data is still needed. For the connection establishment
and transport latency, QUIC improves it by reducing the RTT and only 1-RTT
handshake needed for a connection, and if there were already a connection, QUIC
supports 0-RTT handshake. Finally, for the multipath and Forward Error Correction,
the multipath extension in QUIC is not scheduled for the time period in this research
paper and FEC support is removed in gQUIC and for the IETF QUIC, FEC is out of
scope(Burghard and Jaeger, 2019).
For secure transport, QUIC is vulnerable when using 0-RTT since there might be
application layer replay attacks. For HOL blocking, they mention that QUIC eliminates
HOL blocking for better performance in lossy networks. The authors also mention that
QUIC in a mobile environment is far better because of the 0-RTT handshake for
network switching. The 0-RTT handshake results in a better video latency when users
are on the Youtube app, the handshake is performed in the background. They
mention that QUIC has a better performance with the respective network settings;
high delay, low bandwidth and lossy networks. Another evaluation they mention is
how QUIC performs better for Page Load Time in lossy networks. For mobile
environments, QUIC is better for the Page Load Time metric. The multipath and FEC,
is still under consideration and will eventually be implemented(Burghard and Jaeger,
2019).
Critical Analysis
It can be concluded that the performance of QUIC is better than TCP for mobile
environments and since TCP uses HOL, QUIC performs better when eliminating
25
HOL. For the 0-RTT handshake of QUIC, it is observed that even if it is faster, there
still some vulnerabilities to it such as the application layer replay attack. Also, to
prevent ossification, QUIC will encrypt as much data as possible to prevent future
changes to the protocol. When there are high latency and lossy networks, QUIC is
well suited to take over TCP.
2.2 Systematic Review
In this section, the data given in the research papers in section 2.1, will be
identified, evaluated and explained as well as the different metrics found in
each research paper. Then, in the Background-Qualitative Evaluation, a table
of criteria will be provided as well as the definitions of each metrics. Some
proposed, outside of the research papers, metrics will be given.
2.2.1 Background-Qualitative Evaluation

In this subsection, all the criteria that affect QUIC will be represented for each
research papers, and all the criteria will be compared to observe what criteria
affects QUIC the most. There are some criteria that were not documented in
some research papers.
Key 1:
26
Fig 2. 2: Research Paper Names - Key
Key 2(Metrics):
Fig 2. 3: Research Paper Evaluation Metrics - Key
Table of Criteria:
QUIC P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14
Round-Trip Excellent U U Excelle U U Excellen Excelle U U U U Excellen Excellen

nt t nt t t
Time
Packet Loss Good U U Moderat U U Moderat U U U U Moderat Good U

e e e
Ratio
Congestion U U U Moderat Good Moderat Moderat Moderat Good Moderat U Moderat U

e e e e e e
Control
27
Page Load U U Good U U U U U Good U Moderat
e
Time Good U U
Bandwidth U U U Moderat U U Moderat Moderat Go U U

e e e
Good Good U U Good Moderat
e
Throughput U U s U
U U U U U Excellen U Excellen Good U U Moderat U

t t e
U
Fairness U U U U Moderat U Good Good U U

e
U U U U
Multiplexing U U Good Moderat U Moderat U U Moderat U

e e e
U U Good U
Table 2. 1: Systematic review
Note: As shown in table 2.1, many research papers did not do an experiment
on several criteria and this means that a graph could not be plotted.
Defining the criteria above:
1) Round-Trip Time(RTT)
RTT is the time taken for a packet to be sent by a client and the time it
takes for an acknowledgement of the packet then comes back to the
client.
2) Packet Loss Ratio

This represents the ratio of the number of packets that are lost against
the total number of packets that are sent.
3) Congestion Control
28
This is a method used to keep packets traffic levels where it does not
affect the network performance significantly. It manages the total
number of frames entering the network.
4) Page Load Time(PLT)

PLT is the average time taken for a page to load on your monitor.
5) Bandwidth
This is the measurement of the maximum amount of packets sent and
received in a timeframe.
6) Throughput
This is the measurement of the total amount of packets that have been
successfully arrived at the destination in a timeframe.
7) Fairness
It is used to determine if all the users in the network are receiving a fair
share of the system resources.
8) Multiplexing
This is a method of combining multiple logical streams into a single
shared transport medium.
Proposed four more criteria:
1) Latency
This is the time taken for a packet to be transferred and received from
sender to destination.
2) Competing Flows
29
This is a method that has additional flows in the same direction as a
QUIC flow. A QUIC flow is an end-to-end connection and how the data
flows through the network.
3) Bottleneck Capacity
A bottleneck capacity means the amount of data that can be stored
before having a bottleneck when a high volume of data/frames is being
received.
4) Server Response Time

This is the time taken between the last packet of the client and the first
packet of the server response.
30
3 ANALYSIS
For this section, the requirements of the system will be discussed and several
investigations which will help to analyse the structure of the system will be
described. Moreover, this section contains functional and non-functional
requirements, proposed solution and the different tools and technologies that
will be used for this system.
3.1 Description of System
This system will require a simulator named quiche to work on QUIC

accurately and to test any change. Four different extensions will be
implemented to help the system be quicker and all the critical features
that affect the system proportionally will be identified. Appropriate tools,
as well as the programming that will be used, will be discussed and
simultaneously, editing and implementing the different extensions to
several files in quiche. Afterwards, the performance using the critical
features that affect QUIC will be evaluated.
3.2 Functional Requirements and Non-Function

Requirements
Functional Requirements:
This means the description of the inputs and features that affect the
system and defines how the system should behave or should not.
Non-Functional Requirements:
This means the constraints on how the system should operate as a

whole.
31
3.2.1 Functional Requirements
Table 3.1 below displays all the functional requirements of this system.
QUIC Protocol
FR 1 The system shall use certificate compression.
FR 2 The system shall use the key update mechanism.
FR 3 The system shall use the speed up handshake completion.
FR 4 The system shall be able to have a better loss recovery function.
FR 5 The system shall allow the data to be collected and put in a log file for any
information after a successful or unsuccessful connection.
FR 6 The system shall send and receive packets faster with respect to the 4
extensions added.
FR 7 The users shall be able to use commands for testing or experimentation.
FR 8 The client shall be able to optimize the message exchange resulting in a

decrease in round-trip time after an already established connection to a
server.
FR 9 The system shall make use of TLS 1.3 encryption.
FR 10 The system shall make use of the HTTP/3 module.
Table 3. 1: Functional Requirements
3.2.2 Non-Functional Requirements

Table 3.2 below displays all the non-functional requirements of this system.
QUIC Protocol
Security The system shall be able to encrypt the data as usual and establish a
safe connection.
32
Scalability The system shall be able to accept packet sizes from 0 up to 128
bytes(128bytes since using Wireshark to capture frames).
Testability The system shall be able to test the different extensions given by
quiche and the four extensions that are implemented in this project.
Availability The system shall be available 24/7.
Maintainability The system shall be able to correct any rising problem at a fast rate.
Performance The system shall be able to achieve high throughput for better
Requirements performance.
Reliability The system shall be robust against errors and shall not be vulnerable
to problems.
Portability The system shall be easy to use on different OS platforms(Cross-

platform).
Table 3. 2: Non-Functional Requirements
3.3 Proposed Solution
In chapter 1, a solution has already been proposed for the objectives

described, but in this chapter, the methodology will be discussed and more
details will be given.

Based on the RFC 8879, there are 3 different compression algorithms
and brotli will be used for the certificate compression. The first step to
do is to implement the compression and decompression using brotli.
Afterwards, the certificate compression will be implemented.
Moreover, a way to enable the certificate compression will be
implemented as well as the brotli encoder and decoder.
33
The first step to do is to create and add the key update in the list where
all the other labels. Then create the function for the key update adding
the label “quic ku” with the key length and the secret. Afterwards, the
secrets for protecting client and server packet will be created, there is
also another step to protect a packet that uses ChaCha20-Poly1305
that can be implemented. In quiche, there are several tests’ functions
for the protection of packet.

First, an if statement to know that packets are still before the PTO
expiry, will be implemented. Then in the if statement, a function that will
let the server retransmit the handshake data will be implemented as
well.

Look into the loss recovery failures during handshakes. Quiche fails the
“L1” and “C1” test as shown in this link: https://interop.seemann.io/. “L1”
and “C1” have to be tested again then provide the fixes and
improvement to the loss recovery code if it turns out to be quiche’s fault.
3.4 Evaluation of Tools/Approaches-Pros and

Cons
In this chapter, the tools and technology that are available will be discussed
and which programming language used to implement the extensions in quiche
will as well be discussed.
3.4.1 Programming Language

Here, the different Programming Languages will be evaluated to use in this
system.
34
Programming Pros Cons
Languages
Rust ● Strong safety for ● Complex and difficult to

generics learn
● Compilation is slow
C ● Powerful ● Does not support OOP
● Very flexible ● Run-time checking
● Many built-in functions ● Exception handling is

poor
● It can extend itself
● No constructor or
● Supports both high-
destructor
level and low-level
programming
C++ ● Very flexible ● Misuse of Pointers
● Supports OOP ● Lack of security
● Supports both high- ● No garbage collector

level and low-level
● Lacks of built-in threads
programming
● Memory management
● Compatible with C
Java ● Simple to use ● Memory-consuming
● Supports OOP ● Slow
● Secure ● Memory management
● Support Memory
allocation
35
● Platform-Independent
Visual Basic.Net ● Auto format the code ● Cannot handle pointers

well
● Supports OOP
● Works only on Windows
● Creation of web apps
and web forms
● Can connect to
other .Net frameworks
Python ● Simple to use and ● Slow

easy to learn
● High-level language
● Powerful
● No brackets
● Automatic memory
allocation
● Many supported
libraries
C# ● Works well with ● Compiled language also

Windows means every change
needs the whole code to
● Easy for beginners
be compiled
● Supports Visual Studio
● Microsoft do not support
very well for merging
older .Net frameworks
codes
● It is a compiled
language
Table 3. 3: Programming languages
36
3.4.2Integrated Development Environment (IDE)
Here, the different Integrated Development Environment will be evaluated to
use in this system.
IDE Pros Cons
Visual Studio Code ● Supports several ● The interface is not

languages configured for a single
language thus making it
● Supports several built-
hard to find every feature
in plugins
for one language
● Easy to customize for
● Time taken to open the
any language
app is a bit slow
● Code completion and
detection is intelligent
● Good at debugging
code
● It is cross-platform
● Associated to GitHub
Sublime Text 3 ● Easy to use ● It is not fully free and has

popped up ads that go
● Fast and Robust
away when you buy the
● It is cross-platform license
● Powerful ● Command-line tools

should be adjusted by
the user
Atom ● Open-source software ● It is a bit slow
● Easy to use
37
● Command-line tools
are easy to set up
● Associated to GitHub
Eclipse ● Cross-platform ● JRE is a must to use

Eclipse
● Supports code
completion ● Several plugins will
require several versions
● Supports Syntax
of the same plugins
checking
Vim ● Fast ● The cut/paste

mechanism is poorly
● Powerful
integrated with other
● Good portability apps
● Easy to use ● Syntax checking feature

is poor
IntelliJ IDEA ● Brings advance ● The ultimate version is

features expensive
● Refactoring is a great ● Lack of community

feature support
● Debugging is easy ● Not fully open-source
● Supports few plugins
Table 3. 4: Integrated Development Environment
3.5 Choice of Final Tools Approached with

Justifications
38
In this section, the explanation of why the tools chosen are the appropriate
one and programming language that will be used during this project, will be
discussed.
3.5.1 Programming Language

The choice of programming language is Rust as most of the files are written in
Rust and since it is somewhat similar to C language, it can be learnt easily. It
shows excellent safety capabilities, which are useful for QUIC.
3.5.2 Integrated Development Environment (IDE)

Visual Studio Code was chosen as it contains more support for rust and also it
goes well with GitHub which is beneficial to us. Visual Studio Code has a lot
more features than any other IDE and contains a lot of built-in features.
3.5.3 Tools
Here, the tools to be used will be discussed as well as what the tools are
originally designed to do.
3.5.3.1 Linux Terminal

This is used to move from directory to directory, use with Git command,
compile quiche and use docker on it. VS Code, quiche, Git are easier to
download, edit and set up on the Linux terminal.
3.5.3.2 Quiche
This is like a simulation of QUIC and there were several extensions that
needed to be added in QUIC so the best implementation of the QUIC protocol
from Cloudflare, is chosen, to test the different extensions. This is the easiest
way to experiment with the extensions that will be added in quiche.
3.5.3.3 Git
Git is an open-source control system that is used to track changes in files and
manage files. This is used to download quiche from GitHub using the “git
clone” command in the terminal and Git will be used to update, commit and
39
push the changes on the quiche GitHub repository. “git diff” will also be used
to observe the changes made in quiche.
3.5.3.4 Wireshark
Wireshark is a free network protocol analyzer; it can be used to capture and
analyze frames. Wireshark will be used to capture QUIC packets and
observes the packets if any changes occurred.
3.5.3.5 Docker
Docker is a tool that uses containers to create, deploy and run the application.
Docker will be used to deploy the quiche package.
3.6 Software Modelling: Use Case Diagram
Here, a use case diagram, will be used, to describe how the user can use this
system
40
Fig 3. 1: Use Case Diagram interactions of the User with the system
41
4 DESIGN
In this section, an idea of the architectural design of the system will be
provided, and the focus will be put on the structure of the system as well as
the different extensions it contains. Different kinds of design issues that can
happen with this project will be provided and different diagrams will be given to
explain the architecture of this system and how they work.
4.1 Design Issues
Designing a system such as quiche is a big challenge as it is needed to

ensure several functionalities such as its security or session continuity. Issues
such as portability, security, performance, robustness, flexibility and software
design approach are the essential criteria that will be discussed.
4.1.1 Portability
Portability of the system should be available for almost every platform; Quiche
uses Rust as a programming language that is new and is available on all
platforms. The primary platform that I recommend to work with quiche is Linux.
4.1.2 Security
Security is the most essential aspect of this system. Before setting up any
communication, a tunnel is established. Private/public keys will be
authenticated by the system. Data from the network or from the client is
authenticated and handled by quiche. Quiche makes use of TLS 1.3, which is
part of the connection handshake, thus meaning that the security layer for the
QUIC protocol is the best up to now. Quiche uses a very popular library in
Rust named “ring”, which provides safe and fast cryptographic primitives.
42
4.1.3 Performance
To improve performance, Rust language is used that uses immutability,
aliasing rules, inline functions, combinable iterators to make them into chains,
reads and writes, and even more. Rust is more efficient and faster for low-level
languages. The different extensions that will be implemented will provide
better overall performance in quiche.
4.1.4 Robustness
The systems shall provide proper errors using exception handling. Rust makes
the system more robust as it will provide any errors found and handle them
before the deployment of the system. Any problem that the system encounters
will be shown as well as a proper message.
4.1.5 Flexibility
The system should be able to support any IP Addresses and ports that use
QUIC protocol. The user shall be alerted when a server has stopped working.
4.1.6 Quality of Service

The system shall be reliable when a client tries to connect to a QUIC server,
the client shall be able to ping any QUIC server, the client shall be able to use
the http3 with the server. The system shall run efficiently to ensure good
performance in packet delivery and packet reception.
4.2 Architectural Design
In this section, the different architecture diagrams that will be used to satisfy
the requirements of this project will be provided. Small descriptions also will be
provided about the diagrams.
43
4.2.1 QUIC Layers of OSI Model
QUIC makes use of a UDP-based approach. The architecture was based on
the latest IETF’s QUIC having HTTP/3 as application layer and TLS 1.3 as
encryption.
Fig 4.1 shows the QUIC layers OSI Model
Fig 4. 1: QUIC protocol architecture (CC = Congestion Control)
This architectural design is made to reduce latency for connection

establishment, to protect QUIC packets and headers with TLS 1.3 encryption
and also to maximize QUIC possibility of evolving in the near future. QUIC is
part of the application layer which makes it easier for a fast pace of adoption
and is possible for future evolution. This architecture is designed to keep all
data about connections it carries safe and private.
4.2.2 QUIC Structure

Fig 4.2 shows the different components that are found in the QUIC structure
and a small description of each component will be given.
44
Fig 4. 2: QUIC Structure
HTTP - Provide adaptation to HTTP/3
TLS – Provide keying material for protecting a part of the QUIC traffic. TLS
record layer is included.
Congestion – The successful use of accessible link capacity is verified by

packet acknowledgement and other signals included by congestion
management.
Streams(Multiplexes streams) – This is the primary payload of QUIC.

Streams provide delivery of data, carries encryption handshake and transport
parameters, HTTP header, HTTP requests and responses.
Encryption – Frame integrity protection and frame confidentiality are given

with encryption. Keying material from the TLS connection will protect the
frames and protected 0-RTT is used to protect data.
Frames - This provides different types of frames having different specific

purposes. Stream Multiplexing and Congestion Control frames are supported
by framing. Framing will let live ping tests for frames.
Version Negotiation – This is used for the client/server to agree on a

common version of QUIC to use.
45
Public Reset – This is used to terminate a QUIC connection when an
intermediary sends an unprotected packet as a request.
Envelope – This is the common packet layout. This includes markers for
framing, version connection, connection identification and public reset to be
identified.
4.2.3 QUIC Layers

Integrity and confidentiality protection of packets are in charge by QUIC. QUIC
will use keys derived from a TLS handshake directly. TLS handshake and
Alert message will be in charge by QUIC transport. Fig 4.2 shows that QUIC
relies on TLS for authentication and also for the negotiation of parameters.
Fig 4. 3: QUIC layers
Rather than TCP,
1. QUIC uses the TLS handshake.

2. TLS will use the reliability, ordered delivery and record layer
that is provided by QUIC.
4.2.4 QUIC and TLS interactions

Fig 4.4 shows in detail the interaction between QUIC and TLS components, as
well as the QUIC packet protection.
46
Fig 4. 4: QUIC and TLS interactions
Here, as shown in fig 4.4 there are two main relations between QUIC and TLS:
1) While QUIC provides a valid stream abstraction to TLS, TLS uses the
QUIC component to send and receive messages.
2) There are a series of updates that TLS provides QUIC such as:
a. Installation of new packet protection.
b. State changes(server certificate, handshake completion, etc.).
4.3 System Modelling
In this section, different diagrams, to describe the design of the server-client

session and how they work, will be provided below.
47
4.3.1 Authentication Flowchart Diagram
This is a typical server-client session.
Fig 4. 5: server and client session
48
4.3.2 Sequence Diagram
In QUIC-TLS, the connection establishment and TLS handshake are both
combined in one.
4.3.2.1 QUIC-TLS 1.3 1-RTT exchange

Fig 4.6 shows the interaction between client-server with 1 Round-Trip Time
Fig 4. 6: 1-RTT
Handshake starts when the client sends a “Hello” packet to the server, that
contains connections identifiers and QUIC version for establishing a
connection. The payload of the packet contains data used by TLS for
negotiation of encryption. Then, after the server receives the “Client Hello”
packet, it will check the QUIC version first. Now, there are two things that can
happen, either the client’s version is not found in the list of supported versions
or it is found. If the client’s version is not found then, the server will create and
send a version negotiation packet to the client. If the client’s version is found,
the server will respond with a negotiation packet containing the “Hello” from
49
the client and generate the “Hello” again. The negotiation is finished. After the
client receives the “Server Hello”, the handshake is completed with the client
and can derive keys from its TLS stack to protect the packet’s payload.
Furthermore, the client needs to let the server know that the handshake was
successful. A negotiation packet is sent back to the server containing data
from the client’s TLS stack so that all data sent after this packet is protected
with the 1-RTT packet. When the server receives this packet, which is the last
handshake packet, will let the server know that the negotiation with the client
is done. The server will send a session ticket to let the client resume the
session at the next connection made with the server again.
4.3.2.2 QUIC-TLS 1.3 0-RTT exchange

Fig 4.7 shows the interaction between client-server with 1 Round-Trip Time
Fig 4. 7: 0-RTT
50
QUIC provides a nice change here, which is, a client can connect with a server
without the wait for a single RTT for the handshake. This happens when a
client had already initiated a connection to a server previously, so the new
connection is made with the additional information from the last session. The
payload can be encrypted with the encryption keys that are exported with the
information from the last session. The server uses the payload received from
the “Client Hello” packet to export the same encryption keys. Finally, the
server decrypts the payload using the first data keys. The client can start the
session again.
4.3.3 State Transition Diagram

This section will provide the state transitions of client and server handshakes
using the TLS 1.3 encryption method.
51
4.3.3.1 Client
Fig 4. 8: TLS client handshake
52
4.3.3.2 Server
53
Fig 4. 9: TLS server handshake
54
5 IMPLEMENTATION
This section is the phase where all the components and extensions, that was
discussed in the chapter 1 and 3, will be built from scratch or by composition.
Quiche will be modified to add the different extensions that were discussed in
chapter 3 and the architecture documented in chapter 4 will be used.
5.1 Developments Tools and Environment Used
In this section, the hardware and software tools used to implement the
different modules of this project will be discussed.
5.1.1 Hardware Specifications

The hardware used is a ThinkPad laptop and the specifications are listed in
table 5.1. This is the hardware that both server and client is running on.
Platform Specifications
Memory ram 3732024 KiB
Processor Intel®Core™i5-5200U CPU @

2.20GHz
Maximum Clock Speed 2.20 GHz
Storage ATA ST500LM021-1KJ15
ATA SanDisk SSD U110
ThinkPad Lenovo GPU Intel® HD Graphics 5500
Screen Resolution 1366x768
Table 5. 1: Laptop Specifications
55
5.1.2 Software Specifications
These are the following software tools used for the implementation of the
different modules.
Specifications
Operating System Lubuntu 18.04 LTS
Rust 1.50+ build
Cargo 1.52.0
Make 4.1
Cmake 3.10.2
Docker 20.10.2
Wireshark 3.4.2
Git 2.17.1
Table 5. 2: Software Specifications
5.2 Standards and Conventions
In this section, the standards and conventions that were used to implement
the extensions in quiche will be discussed, which makes the code look simpler
and understandable for other programmers to read. Moreover, this will make
any maintenance done for each extension easier for the software.
5.2.1 Naming Conventions

This will greatly help in understanding the code and also the meaning that the
codes will represent. An example can be when creating a compression
snippet, the name compression will be used to demonstrate that this part is
the compression snippet only.
56
5.2.2 Coding Conventions
For software development, a coding convention is needed to improve the code
readability and to make any maintenance for the software a lot easier.
5.2.2.1 Indentations
During software development, it is a must to put indentation as it will provide
better readability and better clarify the code.
5.2.2.2 Declarations
The declaration will define a variable and also could define a variable
containing a value or text.
5.2.2.3 Comments
Comments are really useful to help to understand part of the code or to help
when debugging.
5.3 Implementation of Different Modules
In this part, the codes implemented will be discussed and a small description
of the code and what they are supposed to do will be given.
5.3.1 Certificate Compression Module

This module will help packets to be sent and received faster by compressing
redundant and predictable content. The brotli algorithm will be used.
The code below is to define the CBB struct that is used in the compression
function.
#[allow(non_camel_case_types)]
#[repr(transparent)]
struct CBB(c_void);
The function below is created so that the API is enabled in the tls.rs file.
pub fn enable_certificate_compression(&mut self) -> Result<()> {
57
#[cfg(any(feature = "brotlienc", feature = "brotlidec"))]
map_result(unsafe {
SSL_CTX_add_cert_compression_alg(
self.as_ptr(),
2, // TLSEXT_cert_compression_brotli
#[cfg(feature = "brotlienc")]
Some(compress_brotli_cert),
#[cfg(not(feature = "brotlienc"))]
None,
#[cfg(feature = "brotlidec")]
Some(decompress_brotli_cert),
#[cfg(not(feature = "brotlidec"))]
None,
)
})?;
Ok(())
}
The 2 functions below are the compression and decompression function and
both are using the brotli algorithm.
extern fn compress_brotli_cert(
_ssl: *mut SSL, out: *mut CBB, in_buf: *mut u8, in_len: usize,
) -> c_int {
let mut out_buf: *mut u8 = std::ptr::null_mut();
let mut out_len = unsafe { BrotliEncoderMaxCompressedSize(in_len)

};
if out_len == 0 {
return 0;
}
if unsafe { CBB_reserve(out, &mut out_buf, out_len) } == 0 {

return 0;
58
}
let rc = unsafe {
BrotliEncoderCompress(5, 17, 0, in_len, in_buf, &mut out_len,
out_buf)
};
if rc == 0 {
return 0;
}
if unsafe { CBB_did_write(out, out_len) } == 0 {

return 0;
}
return 1;
}
extern fn decompress_brotli_cert(
_ssl: *mut SSL, out: *mut *mut CRYPTO_BUFFER, uncompressed_len:
usize,
in_buf: *mut u8, in_len: usize,
) -> c_int {
let mut out_buf: *mut u8 = std::ptr::null_mut();
let decompressed =
unsafe { CRYPTO_BUFFER_alloc(&mut out_buf, uncompressed_len)
};
if decompressed.is_null() {
return 0;
}
let mut out_len = uncompressed_len;
let rc =
59
unsafe { BrotliDecoderDecompress(in_len, in_buf, &mut
out_len, out_buf) };
if rc != 1 || out_len != uncompressed_len {
return 0;
}
unsafe { *out = decompressed };
return 1;
}
The function below is where the certificate algorithm is used.
#[allow(dead_code)]
fn SSL_CTX_add_cert_compression_alg(
ctx: *mut SSL_CTX, alg_id: u16,
compress: Option<
extern fn(
ssl: *mut SSL,
out: *mut CBB,
in_buf: *mut u8,
in_len: usize,
) -> c_int,
>,
decompress: Option<
extern fn(
ssl: *mut SSL,
out: *mut *mut CRYPTO_BUFFER,
uncompressed_len: usize,
in_buf: *mut u8,
in_len: usize,
) -> c_int,
>,
) -> c_int;
60
The code below will declare the functions and variables to be used for
compression and decompression.
#[allow(dead_code)]
fn CRYPTO_BUFFER_alloc(
out_data: *const *mut u8, len: usize,
) -> *mut CRYPTO_BUFFER;
// CBB
#[allow(dead_code)]
fn CBB_reserve(cbb: *mut CBB, out_data: *const *mut u8, len: usize) -
> c_int;
#[allow(dead_code)]
fn CBB_did_write(cbb: *mut CBB, len: usize) -> c_int;
The code below will provide the brotli encoder and decoder.
// Brotli
fn BrotliEncoderMaxCompressedSize(input_size: usize) -> usize;
fn BrotliEncoderCompress(
quality: c_int, lgwin: c_int, mode: c_int, input_size: usize,
input_buffer: *const u8, encoded_size: *mut usize,
encoded_buffer: *mut u8,
) -> c_int;
fn BrotliDecoderDecompress(
encoded_size: usize, encoded_buffer: *const u8, decoded_size:
*mut usize,
decoded_buffer: *mut u8,
) -> c_int;
61
5.3.2 Key Update Module
This module will help packets to be sent and received faster by updating the
write keys.
The code below is the declaration of each function for seal and open.
@@ -152,6 +152,7 @@ impl Open {

derive_pkt_key(aead, &secret, &mut key)?;
derive_pkt_iv(aead, &secret, &mut iv)?;
derive_hdr_key(aead, &secret, &mut pn_key)?;
update_key(aead, &secret, &mut key)?;
Open::new(aead, &key, &iv, &pn_key)
@@ -236,6 +237,7 @@ impl Seal {

derive_pkt_key(aead, &secret, &mut key)?;
derive_pkt_iv(aead, &secret, &mut iv)?;
derive_hdr_key(aead, &secret, &mut pn_key)?;
update_key(aead, &secret, &mut key)?;
Seal::new(aead, &key, &iv, &pn_key)
The code below is the declaration of each function in the initial key function.
@@ -308,6 +310,7 @@ pub fn derive_initial_key_material(

derive_pkt_key(aead, &secret, &mut client_key)?;
derive_pkt_iv(aead, &secret, &mut client_iv)?;
derive_hdr_key(aead, &secret, &mut client_hp_key)?;
update_key(aead, &secret, &mut client_key)?;
The code below is the creation of the function update_key where the label is
set to “quic ku”.
pub fn update_key(
aead: Algorithm, secret: &[u8], out: &mut [u8],
) -> Result<()> {
62
const LABEL: &[u8] = b"quic ku";
let key_len = aead.key_len();
if key_len > out.len() {

return Err(Error::CryptoFail);
}
let secret = hkdf::Prk::new_less_safe(aead.get_ring_digest(),

secret);
hkdf_expand_label(&secret, LABEL, &mut out[..key_len])
}
The test vectors below for client and server is for the test of initial_secrets_v1
assert!(update_key(aead, &secret, &mut pkt_key).is_ok());

let expected_client_update_key = [
0x1f, 0x36, 0x96, 0x13, 0xdd, 0x76, 0xd5, 0x46, 0x77, 0x30,
0xef,
0xcb, 0xe3, 0xb1, 0xa2, 0x2d,
];
assert_eq!(&pkt_key, &expected_client_update_key);

let expected_server_update_key = [
0xcf, 0x3a, 0x53, 0x31, 0x65, 0x3c, 0x36, 0x4c, 0x88, 0xf0,
0xf3,
0x79, 0xb6, 0x06, 0x7e, 0x37,
];
assert_eq!(&pkt_key, &expected_server_update_key);
The test vectors below for client and server is for the test of
initial_secrets_draft29

63
0x17, 0x52, 0x57, 0xa3, 0x1e, 0xb0, 0x9d, 0xea, 0x93, 0x66,
0xd8,
0xbb, 0x79, 0xad, 0x80, 0xba,
];

0x14, 0x9d, 0x0b, 0x16, 0x62, 0xab, 0x87, 0x1f, 0xbe, 0x63,
0xc4,
0x9b, 0x5e, 0x65, 0x5a, 0x5d,
];
The test vectors below for client and server is for the test of
initial_secrets_draft27

0xaf, 0x7f, 0xd7, 0xef, 0xeb, 0xd2, 0x18, 0x78, 0xff, 0x66,
0x81,
0x12, 0x48, 0x98, 0x36, 0x94,
];

0x5d, 0x51, 0xda, 0x9e, 0xe8, 0x97, 0xa2, 0x1b, 0x26, 0x59,
0xcc,
0xc7, 0xe5, 0xbf, 0xa5, 0x77,
];
The test vectors below for client is for the test of chacha20_secrets
64
let expected_update_key = [
0x12, 0x23, 0x50, 0x47, 0x55, 0x03, 0x6d, 0x55, 0x63, 0x42, 0xee,
0x93, 0x61, 0xd2, 0x53, 0x42, 0x1a, 0x82, 0x6c, 0x9e, 0xcd, 0xf3,
0xc7, 0x14, 0x86, 0x84, 0xb3, 0x6b, 0x71, 0x48, 0x81, 0xf9,
];
assert_eq!(&pkt_key, &expected_update_key);
5.3.3 Speed up Handshake Module

This module will help packets to be sent and received faster by letting the
server to retransmit handshake data before the PTO expiry.
fn TEST_P(mut QuicConnectionTest: c_int, mut

ServerRetransmitsHandshakeDataEarly: c_int) -> c_int {
if (!connection_.SupportsMultiplePacketNumberSpaces()) {
return;
}
set_perspective(Perspective::IS_SERVER);
if (QuicVersionUsesCryptoFrames(connection_.transport_version()))
{
EXPECT_CALL(visitor_, OnCryptoFrame(_)).Times(AnyNumber());
}
EXPECT_CALL(visitor_, OnStreamFrame(_)).Times(AnyNumber());
use_tagging_decrypter();
// Receives packet 1000 in initial data.

ProcessCryptoPacketAtLevel(1000, ENCRYPTION_INITIAL);
EXPECT_TRUE(connection_.HasPendingAcks());
connection_.SetEncrypter(ENCRYPTION_INITIAL,
make_unique<TaggingEncrypter>(0x01));
connection_.SetDefaultEncryptionLevel(ENCRYPTION_INITIAL);
// Send INITIAL 1.
connection_.SendCryptoDataWithString("foo", 0,
ENCRYPTION_INITIAL);
65
QuicTime expected_pto_time =
connection_.sent_packet_manager().GetRetransmissionTime();
clock_.AdvanceTime(QuicTime::Delta::FromMilliseconds(5));
connection_.SetEncrypter(ENCRYPTION_HANDSHAKE,
make_unique<TaggingEncrypter>(0x02));
connection_.SetDefaultEncryptionLevel(ENCRYPTION_HANDSHAKE);
EXPECT_CALL(visitor_, OnHandshakePacketSent()).Times(3);
// Send HANDSHAKE 2 and 3.

connection_.SendCryptoDataWithString("foo", 0,
ENCRYPTION_HANDSHAKE);
connection_.SendCryptoDataWithString("bar", 3,
ENCRYPTION_HANDSHAKE);
// Verify PTO time does not change.

EXPECT_EQ(expected_pto_time,
connection_.sent_packet_manager().GetRetransmissionTime());
// Receives ACK for HANDSHAKE 2.

QuicFrames frames;
auto ack_frame = InitAckFrame({{QuicPacketNumber(2),
QuicPacketNumber(3)}});
frames.push_back(QuicFrame(&ack_frame));
EXPECT_CALL(*send_algorithm_, OnCongestionEvent(_, _, _, _, _));
ProcessFramesPacketAtLevel(30, frames, ENCRYPTION_HANDSHAKE);
// Discard INITIAL key.

connection_.RemoveEncrypter(ENCRYPTION_INITIAL);
connection_.NeuterUnencryptedPackets();
// Receives PING from peer.

frames.clear();
frames.push_back(QuicFrame(QuicPingFrame()));
66
frames.push_back(QuicFrame(QuicPaddingFrame(3)));
ProcessFramesPacketAtLevel(31, frames, ENCRYPTION_HANDSHAKE);
EXPECT_EQ(clock_.Now() + kAlarmGranularity,
connection_.GetAckAlarm()->deadline());
// Fire ACK alarm.

clock_.AdvanceTime(kAlarmGranularity);
connection_.GetAckAlarm()->Fire();
EXPECT_FALSE(writer_->ack_frames().is_empty());
if (GetQuicReloadableFlag(quic_retransmit_handshake_data_early))
{
// Verify handshake data gets retransmitted early.
EXPECT_FALSE(writer_->crypto_frames().is_empty ());
} else {
EXPECT_TRUE(writer_->crypto_frames().is_empty());
}
}
5.4 Difficulties Faced and How They Were

Addressed
In this part, all the problems that were encountered during the implementation
chapter will be discussed:
● The first problem was with the compilation of quiche. There were errors
that were incorrect and some were nonexistent as cargo was updated
and those errors were also updated. Since cargo is new and is always
upgrading, cargo on my machine was lagging behind so an update was
required and after the update, new errors were seen but it was more
descriptive and easier to understand what was the error.
67
● Rust being a new language and a bit hard to understand some new
features, it was required to understand rust more to start coding and
understanding past codes.
● Getting the Certificate Compression code to work was a bit difficult as
the RFC 8879 which is about TLS Certificate Compression was not
easy to understand. So, to face this I tried to look at the Boringssl
binding to see if there are any connection between quiche and
Boringssl, and luckily there was.
● There was a problem where quiche was not up to date and I had to go
on GitHub to update it to my forked repository of quiche directly. Then I
had to use the “git pull” command to update it.
5.5 Implementation Issues
In this part, all the problems that were encountered when implementing codes
for the different modules will be discussed:
● Initially, rust was difficult to cope with as there was new syntax and type
was not able to be defined in an extern block. So, to go pass through
this problem, the type had to be created before the extern block.
● A function had to be passed as a parameter in another function, but an
error always occurred. So, to counter this, a type option had to to
created first as a parameter then add the function in the option.
5.6 Building Issue with quiche
To re-create this issue, the steps taken to get the error and how it was fixed is
provided.
1) Download quiche from GitHub by using this command:
git clone https://github.com/jeremie1112/quiche.git
68
(Where jeremie1112 is my username on GitHub)
2) Enter the quiche directory
3) Then, compile quiche with this command:
cargo build --examples
Fig 5. 1: Compilation of quiche
4) It will continue to compile but at the end, it gave an error as shown in

Fig 5.2
Fig 5. 2: Error when compiling
5) Then, a fix was found on https://github.com/cloudflare/quiche/issues/10:
69
git submodule update --init
6) Again, quiche was compiled and it was a success as shown in Fig 5.3
Fig 5. 3: Fix for compiling quiche
70
6 TESTING
In this section, the testing process of this project will be discussed and the
tests of the different extensions that are implemented will be explained. The
requirements that were described in chapter 3 will be observed if they are
functioning well in the implementation.
6.1 Unit Test
Unit test is the process of breaking down a whole into small individual
components and validating each of the small components to observe if the
codes are performing as required. White box and black box testing will be
used to identify test cases and validate the functional and non-functional
requirements.
6.1.1 White Box Testing

White box testing is the process of validating snippets of code that is actually
known to the tester, this is time-consuming.
6.1.2 Black Box Testing

Black box testing is the process of validating the different modules to the
requirements where the codes are unknowncodes unknown to the
programmer. The tests will also validate the functional and non-functional
requirements of this software. Testing on the different test cases will also be
carried on the software.
6.2 Test Cases
In this part, the different implementation modules will be put as test cases and
the description, steps taken to perform testing, data tested and expected
71
results will be provided for each test case. Each module will be tested one by
one and not every module at one go.
6.2.1 Running Client Against a Local Server

In this part, the demonstration of how the client is run against the server on the
machine will be provided and this part will contribute to the “steps taken to
perform testing” in the following subsectionssub-sections.
6.2.1.1 Running Server and Testing Server

Firstly, for the server to work, an HTML file named index had to be created
since it will be run locally(localhost) and the file had to be in the root directory
which is initially in the path “quiche/tools/apps/src/bin/”.
Fig 6. 1: index.html in the server root
Afterwards, the file needs at least a word or some text in it to prove that the
client connected to the server.
Fig 6. 2: Server works text in index.html
“cat index.html” will show the text inside index.html.
Now, to run the server, this command will be used:
cargo run --manifest-path=tools/apps/Cargo.toml --bin quiche-server

-- --cert tools/apps/src/bin/cert.crt --key
tools/apps/src/bin/cert.key --root tools/apps/src/bin/
--cert will provide the default certificate in the root directory.
--key will provide the default certificate in the root directory.
72
--root will provide the root directory and this is how the server will use the
index.html file.
Running this will provide the following result:
Fig 6. 3: Server running
One way to test if this works is with netstat with the following code:
netstat -pan | grep udp
After running this code, the following results are provided:
Fig 6. 4: Testing 1st method if the server is running
The server is running as shown in the yellow rectangle.
Another way to test if the server is working is by connecting the client to the
server. So, the following command is run to get the client to connect:
cargo run --manifest-path=tools/apps/Cargo.toml --bin quiche-client

-- --no-verify https://127.0.0.1:4433/
73
This will provide the following result as shown in Fig 6.5.
Fig 6. 5: Testing 2nd method if the server is running
The server is running since the result given(SERVER WORKS) is the text in
the index.html file that is in the server root.
6.2.2 Taking Data from Wireshark

After that the server is running and that the client is connected to the server,
the data(timestamp) of the packets sent by the server will be recorded. The
delay of each packet will be observed.
First, the packets are located on localhost which is the loopback IP(127.0.0.1)
and the filter is set on loopback as shown in Fig 6.6.
Fig 6. 6: Loopback filter
Afterwards, the client connected to the server and Wireshark recorded the
packets as shown in Fig 6.7.
74
Fig 6. 7: QUIC Packets recorded
To get the timestamp of the packets, the UDP drop-down will provide
timestamps of the previous packet and the sum of all the packets since the
first packet.
Fig 6.8 provided is the timestamp of the second packet.
75
Fig 6. 8: QUIC Packet Timestamps
As shown in Figin the Fig 6.8, the timestamps for the previous packet and the
time since the first packet is given.
6.2.3 Certificate Compression

Table 6.1 will provide the first test case with a description, steps taken to
perform testing, data tested and the expected results.
Test Case 1
Description This module will make the handshake faster by compressing

redundant content.
Steps taken to 1) Uncomment the Certificate compression codes and

perform testing comment on all the other different modules codes.
76
2) Run the server locally.
3) Start Wireshark with the loopback filter.
4) Run client against the server.
5) Collect the timestamp for each packet.
Data tested Timestamps of the packets
Expected Results A 10-15% decrease in time.
Table 6. 1: Test Case 1
6.2.4 Key Update

Test Case 2
Description This module will make the handshake faster by updating write
keys.
Steps taken to 1) Uncomment the Key update codes and comment on all
perform testing the other different modules codes.
77
6.2.5 Speed up Handshake
Test Case 3
Description This module will make the handshake faster by sending

unacknowledged crypto data before the Probe Timeout expiry.
Steps taken to 1) Uncomment the Speed up handshake codes and

perform testing comment on all the other different modules codes.
6.2.6 Loss Recovery Failures

Test Case 4
Description This module will help to provide fix for the loss recovery during
the handshake.
Steps taken to 1) Uncomment the loss recovery codes and comment all
perform testing the other different module’s codes.
78
Expected Results Bugs during handshake for loss recovery failures are fixed.
7 EVALUATION
In this chapter, what was implemented and tested in the chapters before will
be assessed. Moreover, the reason how the modules implemented are
achieving their goal or not will be provided. To check whether the modules
have been well refactored to see if they met the requirements will be
discussed as well. This chapter will be divided into several parts such as
Quantitative and Qualitative Evaluation, Critical Analysis, Issues faced during
evaluation, and Domain recommendation.
7.1 Quantitative Evaluation
Quantitative evaluation is the method of assessing the data collected after the
testing chapter by using these numerical data on graphs. The information
gathered will be observed whether the goal of this project is achieved. Several
tables will be provided, one for the original traffic without any implementation
modules, and one for each implementation module. Since the timestamps will
change every time that the client is connected to the server, the test will be
done 10 times for each test cases and the average time will be recorded on
the tables below.
79
7.1.1 Original Traffic
Table 7.1 will provide the values of timestamp capture by Wireshark with no
implementation module.
Original Traffic
Packet Time since first frame(in sec) Time since previous frame(in sec)
No
1 0 0
2 0.000358941 0.000358941
3 0.001927852 0.001568911
4 0.002177915 0.000250063
5 0.003179496 0.001001581
6 0.016629008 0.013449512
7 0.016740059 0.000111051
8 0.016844906 0.000104847
9 0.018982427 0.002137521
10 0.019103536 0.000121109
11 0.019218958 0.000115422
12 0.023864929 0.004645971
13 0.024177290 0.000312361
14 0.024388881 0.000211591
15 0.024517312 0.000128431
80
16 0.024642842 0.000125530
17 0.025899755 0.001256913
18 0.029059069 0.003159314
Table 7. 1: Original Traffic
Original traffi c
Time Since First Frame(in sec)
0.03
0.02
0.01
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Packet No
Fig 7. 1: Original Traffic
The total time taken of the packets to be sent or/and received is nearly
0.0269(3 s.f) without any extensions added. As shown in Fig 7.1, the packets
sending or/and receiving rate areis not stable, this is why an averageing will
be done so that a better result is recorded.
7.1.2 Certificate Compression Traffic

Table 7.2 will provide the values of timestamp capture by Wireshark when only
the certificate compression is enabled.
Certificate Compression Traffic
No
81
1 0 0
2 0.000131586 0.000131586
3 0.000825739 0.000694153
4 0.001870600 0.001044861
5 0.002596239 0.000725639
6 0.005447835 0.002851596
7 0.005548960 0.000101125
8 0.012585708 0.007036748
9 0.012738285 0.000152577
10 0.016690160 0.003951875
11 0.016769275 0.000079115
12 0.016844889 0.000075614
13 0.016932668 0.000087779
14 0.017044237 0.000111569
15 0.017166784 0.000122547
16 0.017261940 0.000095156
17 0.017379052 0.000117112
18 0.018335687 0.000956635
Table 7. 2: Certificate Compression Traffic
82
Certifi cate compression traffi c
Time Since First Frame(in sec)

0.03
0.02
0.01
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Packet No
Fig 7. 2: Certificate Compression Traffic
The first thing that is found is the difference between the original traffic data is
that the total time taken of the packets is significantly less. The total time taken
here is nearly around 0.0187(3 s.f) and the certificate compression has
reduced the size of the handshakes by compressing the redundant and
predictive data. The TLS certificate compression has a good impact on QUIC
handshakes’ performance.
7.1.3 Key Update Traffic

the key update mechanism is enabled.
Key Update Traffic
No
1 0 0
2 0.000173688 0.000173688
83
3 0.000717013 0.000543325
4 0.000885924 0.000168911
5 0.001431289 0.000545365
6 0.004246820 0.002815531
7 0.004336835 0.000090015
8 0.012491734 0.008154899
9 0.012642863 0.000151129
10 0.012746035 0.000103172
11 0.012820050 0.000074015
12 0.012903138 0.000083088
13 0.017219050 0.004315912
14 0.017973841 0.000754791
15 0.01817640 0.000202559
16 0.018284296 0.000107896
17 0.018348979 0.000064683
18 0.018414148 0.000065169
Table 7. 3: Key Update Traffic
84
Fig 7. 3: Key Update Traffic
here is nearly around 0.0184(3 s.f) and the key update mechanism has
reduced the time taken of the handshakes by updating packet protection write
secret which is used to protect newer packets.
7.1.4 Speed up Handshake Traffic

the speed up handshake mechanism is enabled.
Speed up handshake Traffic
No
1 0 0
2 0.000233691 0.000233691
3 0.001078920 0.000845229
85
4 0.009162173 0.008083253
5 0.009994742 0.000832569
6 0.010164257 0.000169515
7 0.010250026 0.000085769
8 0.013486421 0.003236395
9 0.015264947 0.001778526
10 0.015354640 0.000089693
11 0.015442179 0.000087539
12 0.015524546 0.000082367
13 0.015788157 0.000263611
14 0.015909416 0.000121259
15 0.016006208 0.000096792
16 0.016091139 0.000084931
17 0.017936078 0.001844939
18 0.019338372 0.001402294
Table 7. 4: Speed up Handshake Traffic
86
Fig 7. 4: Speed up Handshake Traffic
here is nearly around 0.0195(3 s.f) and the speed up handshake mechanism
has reduced the time taken of the handshakes by sending a packet containing
unacknowledged CRYPTO data before the PTO expiry.
7.1.5 Difference Between Each Test Case

Fig 7.5 is the representation of the difference between each test case traffic
and the original traffic.
87
Fig 7. 5: Chart representing the difference between each test case and the original traffic
As shown in Fig 7.5, it can be deduced that the three implemented modules
are working and have a better performance than the original traffic. Even if the
timestamps are decreased by merely milliseconds, it actually makes a big
difference compared to the original traffic.
7.2 Qualitative Evaluation
Qualitative evaluation is the method of assessing the data collected after the
testing chapter. The functional and non-functional requirements provided in
chapter 3 will be used to observe if the implemented modules are really
working by evaluating them against the data collected. The criteria that were
identified in chapter 2 will be used to assess the modules implemented.
7.2.1 Evaluating Functional Requirements

Table 7.5 will assess the Functional Requirements that were previously written
in the Analysis Chapter.
QUIC Protocol
FR Description Implemented
88
FR 1 The system shall make use of the certificate Yes
compression.
FR 2 The system shall make use of the key update Yes

mechanism.
FR 3 The system shall make use of the speed up handshake Yes

completion.
FR 4 The system shall be able to have a better loss recovery No

function.
FR 5 The system shall allow the data to be collected and put in Yes
a log file for any information after a successful or
unsuccessful connection.
FR 6 The system shall send and receive packets faster with Yes
respect to the 4 extensions added.
FR 7 The users shall be able to use commands for testing or Yes

experimentation.
FR 8 The client shall be able to optimize the message Yes

exchange resulting in decreased in round-trip time after
an already established connection to a server.
FR 9 The system shall make use of TLS 1.3 encryption. Yes
FR 10 The system shall make use of the HTTP/3 module. Yes
Table 7. 5: Evaluating Functional Requirements
89
7.2.2 Evaluating Non-Functional Requirements
Table 7.6 will assess the Non-Functional Requirements that were previously
written in the Analysis Chapter.
QUIC Protocol
NFR Description Implemented
Security The system shall be able to encrypt the data as Yes

usual and establish a safe connection.
Scalability The system shall be able to accept packet sizes Yes

from 0 up to 128 bytes(128bytes since using
Wireshark to capture frames).
Testability The system shall be able to test the different Yes

extensions given by quiche and the four
extensions that are implemented in this project.
Availability The system shall be available 24/7. Yes
Maintainability The system shall be able to correct any rising Yes

problem at a fast rate.
Performance The system shall be able to achieve high Yes

Requirements throughput for better performance.
Reliability The system shall be robust against errors and Yes

shall not be vulnerable to problems.
Portability The system shall be easy to use on different OS Yes

platforms(Cross-platform).
Table 7. 6: Evaluating Non-Functional Requirements
90
7.2.3 Discussion About Each Non-Functional
Requirements
In this section, each non-functional requirement will be discussed according to
the modules implementedimplemented modules in quiche. Through actual
observation of test cases and data sets, the non-functional requirements will
be assessed.
7.2.3.1 Security
Based on the IETF draft for TLS Certificate Compression, the Certificate
message will be using the TLS security properties as it normally would, even
when being compressed. The attacker will not be able to see the information
about the certificate or take control of the certificate message. Therefore, the
security aspect is still working and is somewhat better than before when
encrypting or decrypting data.
7.2.3.2 Scalability
Based on the data set for each module, it can be said that the packet
timestamps are scalable. Their timestamps are mostly around milliseconds
and nanoseconds. For QUIC the maximum packet size is 1500 bytes, which is
really scalable.
7.2.3.3 Testability
Based on chapter 6 and sub-heading 6.2.1, it is shown that testing with quiche
can be done and for each and every module implemented. Several options to
test each module is available as well.
7.2.3.4 Availability
Based on the system, quiche server can be run 24/7, and a client can be run
against the server anytime.
7.2.3.5 Maintainability
Since the system is stored as a repository on GitHub, any issues, updates or
changes can be quickly updated on the client-side.
91
7.2.3.6 Performance Requirements
Based on the data set for each module, it can be said that they outperformed
the original traffic, and they delivered a higher throughput.
7.2.3.7 Reliability
Based on the system, each function created will provide a good error message
and try-catch methods are also implemented for robustness.
7.2.3.8 Portability
The system can be built on Linux, Windows, Android and IOS.
7.2.4 Qualitative Evaluation of Identified Criteria

For the evaluation of the different modules implemented, the background-
qualitative evaluation proposed in chapter 2 will be used to assess these
modules. The criteria below will be used to assess the different test cases that
were described in the Testing Chapter.
7.2.4.1 Round-Trip Time

Based on the handshake’s packets, it can be deduced that the Round-Trip
Time was functioning well and the optimization of the message exchange that
reduces the Round-Trip Time was working.
7.2.4.2 Packet Loss Ratio

Based on the number of packets gotten in the tables above and in the server
log, it can be deduced that the packet loss ratio is great since the number of
packets sent is the same as the number of packets received.
7.2.4.3 Congestion Control

Based on the implementation of quiche, quiche uses the CUBIC, HyStart++
and Reno where it will have a better performance than using only the Reno
algorithm.
92
7.2.4.4 Page Load Time
Since the modules have been implemented, it can be deduced that the time
taken for packets is less and it will have a better page load time.
7.2.4.5 Bandwidth
It can be deduced that the bandwidth has a better result as the maximum
number of packets sent and received is the same and is faster with the
modules implemented.
7.2.4.6 Throughput
It can be deduced that the throughput is the same as the project did not tweak
with functions that changed the throughput.
7.2.4.7 Fairness
It can be deduced that the fairness was not changed as the system was able
to record with only one client against a local server.
7.2.4.8 Multiplexing
Multiplexing was not actually a work in progress in this project, so it was not
changed.
7.2.4.9 Latency
The latency has a better result now since the packets sent and received are
faster with the implemented modules.
7.2.4.10 Competing Flows

This criterion was not a work in process as well, so nothing changed.
7.2.4.11 Bottleneck Capacity

This criterion was not a work in process as well, so nothing changed.
7.2.4.12 Server Response Time

It can be deduced that this criterion has a better result as the modules server
response time was better than the original traffic’s server response time.
93
7.2.5 Loss Recovery Failure
The loss recovery failure generally means that there are packet losses during
the handshake and there are also cases of handshake corruption where
packets may be corrupted. An example of packet losses can be when using
Wi-Fi some packets are lost in transit when sending or receiving. The loss
recovery in QUIC is used so that it will be tough against high loss rates and so
that it will be improved for high RTTs’ Search Latency as well. The problem
with quiche(not really sure) is that there is handshake loss and handshake
corruption with different QUIC clients and servers. Quiche client against
Quiche server have a successful result and most of the other results, against
other servers or clients, have failed results as you can see on this website
‘https://interop.seemann.io/’. The work here is to investigate the loss recovery
failures during handshakes of different clients against quiche server and
quiche client against different servers. As it is shown on the website, there are
“L1” and “C1” tests that fail most frequently. Fig 7.5 and Fig 7.6 shows the L1
and C1 definition respectively.
Fig 7. 6: L1
94
Fig 7. 7: C1
Basically, the solution is to provide fixes and improvement to this problem. To

solve this, each client and server will have to be tested against each other for
this experiment. To know whether the issue is with quiche, the problem should
be figured out after the experiment. If it turns out to be quiche’s fault, a fix to
the loss recovery code has to be provided. The experimentation is time-
consuming as well as trying to figure out the problem. To know where the
issue might be, the loss recovery code must be learnt and what does the code
initially do. After this process, a fix for the loss recovery code will be provided.
Then again do the above experiment again to know if it really worked.
7.3 Issues Faced during Evaluation
In this part, all the problems that were encountered during the evaluation
chapter will be discussed as well as how these problems were solved:
● The packet timestamps for each test were changing every time, so to fix
this problem, 10 tests were made for each test case and for each test
case an averaging was made.
● During evaluation when running the client against the server, there was
a problem that didn’t let the client be run. To fix this, it took a while to
find out that the server root was in “tools/apps/src/bin/” and all data was
sent to the server root.
95
● While testing and running the client against the server, there were a
different total number of packets. For instance, occasionally the total
number was 18 and rarely 19. So, to fix this problem, only the total
number 18 was taken.
● When recording packets on Wireshark initially, the filter QUIC was not
available then to fix this, Wireshark had to be updated.
● Primarily, the server was not running and the error “Not Found!” was
being displayed. After some searching, a fix was found on
“https://github.com/cloudflare/quiche/issues/444”. The fix was to put
some data in the server root and to provide the “--root” option in the
server launch command.
7.4 Critical Analysis
In this sub-section, the strengths and weaknesses of this project will be

discussed. This is where the critical analysis of this project will determine
whether there will be future works or that the project can go beyond and
improve the requirements with other compressions or is one enough. Based
on the strengths and weaknesses, in the next chapter, future works will be
provided that can improve the performance, better security and reliability of
the software.
7.4.1 Strengths
● This system uses Certificate Compression that decreases the
timestamp of the packet.
● This system uses the Key Update Mechanism that decreases the
timestamp of the packet.
● This system uses the Speed up Handshake Mechanism that decreases
the timestamp of the packet.
96
● Generally, one of the best compression algorithms was used for
certificate compression.
● The system can use several options when running a server and when
running a client.
● Since quiche uses TLS, a lot of the security properties of TLS will be
available to quiche.
7.4.2 Weaknesses
● Since quiche is still new, the client(when downloading on git) should
download the updates from GitHub.
● Cargo should be updated as well, since there may be some errors that
were not updated and will provide invalid errors.
● The codes for the speed up handshake are not well refactored, which
can lead to a longer processing time.
● Some tasks may take a long period of time to code since QUIC is new
and there are few amounts of documentation.
7.5 Domain Recommendation
There are a lot of implementations of the QUIC protocol that uses the IETF
version of QUIC. Based on the data obtained in this chapter, the modules
implemented can be exported to other implementations of QUIC.
Applications Other implementations of QUIC

that can use this module
Certificate Compression Aioquic, Akamai QUIC, ats, f5,

Haskell quic, kwik, MsQuic
The difference in total timestamps
between Table 7.2 and Table 7.1 is
clear that using the Certificate
Compression gives better
97
performance for quiche. The
Certificate Compression will
compress the message by removing
redundant/predictive data and
keeping cryptographic material. In
quiche, the brotli compression
algorithm is used.
Key Update Mechanism Aioquic, Akamai QUIC, ats, f5,

clear that using the Key Update
Mechanism gives better performance
for quiche. The key update will
update the keys for packet protection
as well as the next packet sent which
will use the new keys.
Speed Up Handshake Mechanism Aioquic, Akamai QUIC, ats, f5,

clear that using the Speed up
Handshake Mechanism gives better
performance for quiche. The
Speeding up Handshake completion
will send an unacknowledged
CRYPTO data before the PTO expiry.
Doing this will help recover packet
loss.
Table 7. 7: Domain Recommendation
98
8 CONCLUSION
In this last section, all the achievements, difficulties and future works will be
discussed. The modules created in this project werewas originally done
because TLS 1.3 and BoringSSL had these modules but were not
implemented in quiche, and these modules would greatly help quiche get a
better result. During the development of this project, a lot of tools, different
technologies and way of thinking was developed. Rust skill has been
improved, but still needs a lot more skills to be a good programmer in Rust
and for quiche. QUIC is still a new protocol and a lot of tasks to make QUIC a
better protocol than TCP. There are a lot of interesting tasks for quiche that
can be implemented. These tasks will be discussed in the future works sub-
section.
8.1 Achievements
Now that the project is completed, even if the Loss recovery failure was not
successful, it can be said that a lot has been done in quiche. The modules
implemented in quiche have a big impact on the timestamp mostly and this is
a great achievement for quiche. Even if the security part of quiche was not
mostly touched, at least a high performance on the speed of the packets have
been achieved. Another achievement done is the ability to understand RFCs
and trying to figure out what it means and how it helps in the implementation
of technology. Building quiche was fun and running a client against the local
server was a good experience to test all the different things that are in quiche.
While working on quiche, it helped to learn a lot more about the structure of
QUIC and how it differs from the old TCP protocol and trying new things with
QUIC. By doing the main objective of this project, it also helped to learn more
about rust and QUIC as it seems that it might be the future and more of it will
be discussed in the Future works subsection.
99
8.2 Difficulties
The implementation part was the longest section since quiche and cargo/rust
were new technologies and learning rust and applying it to the code took some
time. For each module implemented, a lot of time was dedicated to the reading
of RFCs and understanding each RFC, so that the codes would work, was
time-consuming. Moreover, even after building quiche, it was time-consuming
to understand how to run the client against the local server. Now, for the local
server, it was challenging to make it run as an error was constantly being
displayed, so this delayed the implementation time. This is the reason why the
last module to implement was delayed and it could not be done in time. Since
the cargo was not updated, some errors that were displayed were errors that
were not updated and it showed the wrong errors or showed outdated errors.
When searching for the outdated errors, nothing appeared, it was non-
productive. So, an idea struck me to update cargo and it worked fine, but still,
it was time-consuming.
8.3 Future Works
In Chapter 7, the domain recommendation was already provided, and in this

subsection, other future works that will improve the system will be provided as
well. Due to the time constraint, in the last module, the investigation of loss
recovery failure could not be implemented but it can be a future work to make
the system better. The additional future works, that will make the system more
performant, will be provided:
● For the Certificate Compression, other compression algorithms can be

used. Such as zlib and zstd.
● For the Key Update Mechanism, other test vectors for “quic ku” can be
provided.
● Write an API to set initcwnd, which will include a set of changes to
support to set initial window size.
100
● Code a quiche congestion control based on ECN, which will detect or
control congestion.
● Implement BBR congestion control.
Another work that can be done is test quiche against spinquic(QUIC stress
tester built by Microsoft). This can help to get familiar with quiche.
101
● LIST OF REFERENCES
Agilites (2017). Pros and cons of using c# as your backend programming
language. [online] Agilites.com. Available at: https://agilites.com/pros-and-
cons-of-using-c-as-your-backend-programming-language.html.
Alvise De Biasio, Chiariotti, F., Polese, M., Zanella, A. and Zorzi, M. (2019). A
QUIC implementation for ns-3. Acm, 2 Penn Plaza, Suite 701, New York, Ny
1-, Usa 06-19.
Anderson, W. (2015). What are the drawbacks of using visual studio code? -
quora. [online] www.quora.com. Available at: https://www.quora.com/What-
are-the-drawbacks-of-using-Visual-Studio-Code [Accessed Mar. 2021].
Arisu, S., Yildiz, E. and Begen, A.C. (2020). Game of protocols: Is QUIC ready
for prime time streaming? International Journal of Network Management,
[online] 30. Available at:
https://ideas.repec.org/a/wly/intnem/v30y2020i3ne2063.html [Accessed Dec.
2020].
Burghard, M. and Jaeger, B. (2019). How good is QUIC actually? [online]

Available at:
https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2019-10-1/NET-2019-10-
1_06.pdf [Accessed Dec. 2020].
Cao, X., Zhao, S. and Zhang, Y. (2019). 0-RTT attack and defense of QUIC
protocol. IEEE Xplore, [online] pp.1–6. Available at:
https://ieeexplore.ieee.org/document/9024637 [Accessed Nov. 2020].
Cary, I. (2020). Python: Pros and cons. [online] scholarlyoa.com. Available at:
https://scholarlyoa.com/python-pros-and-cons/ [Accessed Mar. 2021].
102
Cook, S., Mathieu, B., Truong, P. and Hamchaoui, I. (2017). QUIC: Better for
what and for whom? IEEE Xplore, [online] pp.1–6. Available at:
https://ieeexplore.ieee.org/abstract/document/7997281 [Accessed Dec. 2020].
Corbel, R., Tuffin, S., Gravey, A., Marjou, X. and Braud, A. (2019). Assessing
the impact of QUIC on network fairness. Journal of Communications, 14,
pp.908–914.
DataFlair Team (2018). Pros and cons of java | advantages and

disadvantages of java - DataFlair. [online] DataFlair. Available at: https://data-
flair.training/blogs/pros-and-cons-of-java/.
DataFlair Team (2019a). Advantages and disadvantages of c programming -

discover the secrets of c. [online] DataFlair. Available at: https://data-
flair.training/blogs/advantages-and-disadvantages-of-c/.
DataFlair Team (2019b). Advantages and disadvantages of C++ | make your

next move! - DataFlair. [online] DataFlair. Available at: https://data-
flair.training/blogs/advantages-and-disadvantages-of-cpp/.
Educba (2019). What is visual studio code? | features and advantages | scope
& career. [online] EDUCBA. Available at: https://www.educba.com/what-is-
visual-studio-code/.
Ghedini, A. and Vasiliev, V. (2017). Transport Layer Security (TLS) Certificate

Compression. [online] tools.ietf.org. Available at: https://tools.ietf.org/id/draft-
ietf-tls-certificate-compression-01.html [Accessed 22 Jun. 2021].
Guru99 (2019). What is VB.net? Introduction, history, features, advantages,

disadvantages. [online] Guru99.com. Available at: https://www.guru99.com/vb-
net-introduction-features.html.
Holý, J. (2011). Comparison of eclipse 3.6 and IntelliJ IDEA 10.5: Pros and
cons - DZone java. [online] dzone.com. Available at:
https://dzone.com/articles/comparison-eclipse-36-and [Accessed Mar. 2021].
103
K, K.P., Rege, A., Goel, A. and Kulkarni, M. (2018). QUIC protocol
performance in wireless networks. IEEE Xplore, [online] pp.0472–0476.
Available at: https://ieeexplore.ieee.org/document/8524247 [Accessed Nov.
2020].
Langley, A., Riddoch, A., Wilk, A., Vicente, A., Krasic, C., Zhang, D., Yang, F.,
Kouranov, F., Swett, I., Iyengar, J., Bailey, J., Dorfman, J., Roskind, J., Kulik,
J., Westin, P., Tenneti, R., Shade, R., Hamilton, R., Vasiliev, V. and Chang,
W.-T. (2017). The QUIC transport protocol: Design and internet-scale
deployment. Proceedings of the Conference of the ACM Special Interest
Group on Data Communication.
Lazar, A. (2018). The battle of the IDEs. [online] JAXenter. Available at:
https://jaxenter.com/battle-ides-150122.html.
Learn Enough (n.d.). Learn enough text editor to be dangerous. [online]

Softcover.io. Available at:
https://www.learnenough.com/text-editor-tutorial/modern_text_editors/
choosing_a_text_editor [Accessed Mar. 2021].
Megyesi, P., Krämer, Z. and Molnár, S. (2016). How quick is QUIC? IEEE
Xplore, [online] pp.1–6. Available at:
https://ieeexplore.ieee.org/document/7510788 [Accessed Oct. 2020].
Mehta, A. (n.d.). Social network for programmers and developers. [online]

morioh.com. Available at: https://morioh.com/p/c5c859c99fcf [Accessed Mar.
2021].
Nepomuceno, K., Oliveira, Igor Nogueira de, Aschoff, R.R., Bezerra, D., Ito,
M.S., Melo, W., Sadok, D. and Szabó, G. (2018). QUIC and TCP: A
performance evaluation. IEEE Xplore, [online] pp.00045–00051. Available at:
https://ieeexplore.ieee.org/document/8538687 [Accessed Oct. 2020].
104
Piraux, M., De Coninck, Quentin and Bonaventure, O. (2018). Observing the
evolution of QUIC implementations. Proceedings of the Workshop on the
Evolution, Performance, and Interoperability of QUIC.
Rescorla, E. (2018). The transport layer security (TLS) protocol version 1.3.
[online] tools.ietf.org. Available at: https://tools.ietf.org/id/draft-ietf-tls-tls13-
23.html [Accessed May 2021].
Ribeiro, C. (2021). Advantages and disadvantages of vim in 2018. [online]

www.hebergementwebs.com. Available at:
https://www.hebergementwebs.com/news/advantages-and-disadvantages-of-
vim-in-2018 [Accessed Mar. 2021].
Rüth, J., Poese, I., Dietzel, C. and Hohlfeld, O. (2018). A first look at QUIC in
the wild. Passive and Active Measurement, [online] pp.255–268. Available at:
https://link.springer.com/chapter/10.1007%2F978-3-319-76481-8_19.
Rüth, J., Wolsing, K., Wehrle, K. and Hohlfeld, O. (2019). Perceiving QUIC.
Proceedings of the 15th International Conference on Emerging Networking
Experiments And Technologies. [online] Available at:
https://www.researchgate.net/publication/337779239 [Accessed Oct. 2020].
Thomson, M. and Hamilton, R. (2016). Using transport layer security (TLS) to

secure QUIC. [online] tools.ietf.org. Available at: https://tools.ietf.org/html/draft-
thomson-quic-tls-01 [Accessed May 2021].
Turner, S. and Thomson, M. (2021). Using TLS to secure QUIC. [online]

tools.ietf.org. Available at: https://tools.ietf.org/html/draft-ietf-quic-tls-34
[Accessed May 2021].
Wang, P., Bianco, C., Riihijärvi, J. and Petrova, M. (2018). Implementation and
performance evaluation of the QUIC protocol in linux kernel. Proceedings of
the 21st ACM International Conference on Modeling, Analysis and Simulation
of Wireless and Mobile Systems.
105
UNIVERSITY OF MAURITIUS
FACULTY/ CENTRE OIDT
PROGRESS
LOG
Student Name : Emmanuel Jeremie Daniel
Student ID : 1812415
Department : ICT
Programme : BSc(Hons) Computer Science

Title of : Congestion control for QUIC
Dissertation
Supervisor(s) : Dr. Avinash Utam Mungur
Project/ Dissertation/ Programme Coordinator :
● Your Progress Log serves as a record of your transferable skills and

participation and attainment as a student for dissertation purposes.
● Its purpose is to help you to plan your own dissertation and to record the
outcomes.
● As well as gaining valuable skills, you will find that the information
accumulated in this Log will prove helpful during the write up of the
dissertation.
● The document belongs to you and it is your responsibility to keep it up to

date.
● It is your responsibility to ensure your supervisor(s) is/are aware of

the dissertation activities you have undertaken.
You should sign the appropriate statement below when you submit your
Progress Log:
106
I confirm that the information I have given in this Log is a true and accurate
record:
Signed: ………E.J.D….………………… Date: …27/06/21…...
PROGRESS LOG
RECORD OF STRATEGIC MEETINGS WITH SUPERVISOR(S)
Meetin Date Topics/ Themes Commen Supervisor Student

gs ts (If any) ’s ’s
Discussed Initials Initials
1 28/09/ -Talking about E.J.D
20 the project
guidelines, the
scope of the
project.
-using quiche
prototype
-talking about
Background
Study
-look for 14
research papers
2 16/10/ -Table of criteria E.J.D
20 -summarise a
research paper
on 1 or 1 ½ page
-using ns3 for
simulation
-write synopsis
-give more
criteria for
research paper
3 30/10/ -Table of E.J.D
20 criteria(write
about each layer)
107
-do 14 research
papers then
observe if the
table of criteria is
applied.
-start
downloading the
pre-requisite for
quiche/ns3 and
start playing with
the code to
understand how it
works.
-write each
definition for each
criterion.
4 18/11/ -Format of a E.J.D
20 research paper is
good.
-add a transport
layer in the table
of criteria.
-
implementation( s
tart adding
features to
quiche).
5 09/12/ -Do all the E.J.D
20 research papers
left.
-the scope
changed so that
quiche will be
faster.
-Add more
elements to the
table of criteria
6 13/01/ -All research E.J.D
21 papers are done.
-Do
implementation.
-Start doing
Design and
Analysis.
7 18/03/ -Write the E.J.D
21 definitions for
108
each chapter.
-write more for
the problem
statement.
-propose 4 more
criteria and write
the definition for
each.
-re-write FR and
NFR.
-Expand
methodology.
-write definitions
for tools.
21 working on
Design.
-Reviewed the
architectural
design provided.
-Start working on
all
implementation
module.
21 the guideline and
how to submit.
-Remove all “we”
and rephrase the
sentences.
-Changed an NF.
-Provide a graph
for the results in
the evaluation.
-All tables and
figures have to be
referenced.
-Do an average
of 10 for every
module
implemented.
-Talk about the
NFR in
evaluation.
-Explain the
criteria provided
109
in the evaluation.
-Talking about
the domain
recommendation.
Supervisor(s) Signature(s) Date

……………………………… …………………………… ……………………
….. ….. …
……………………………… …………………………… ……………………
….. ….. …
N.B: Both the supervisor(s) and the student should retain a copy of this Project Progress
Log.
A copy of the duly filled and signed Progress Log should be included and
submitted in the section ‘Appendices’ of the Dissertation.
110

Computer Science 1812415 AM6-Proposed RD

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Computer Science 1812415 AM6-Proposed RD

Uploaded by

Copyright:

Available Formats

Congestion control for QUIC

Submitted in Partial Fulfillment for the Degree of

Department of Information and Communication

a. I have read and understood the sections on “Plagiarism and Fabrication

Emmanuel Jeremie Daniel

List of Figures viii

1.1 Problem Statement 1

1.2 Aims and Objectives 1

1.3 Project Scope 2

1.5 Project Timeline 3

2.1 Research on Existing Systems with a Critical View 4

Research paper 2.2.1: QUIC and TCP: A Performance Evaluation 4

Research paper 2.2.2: A First Look at QUIC in the Wild 6

Research paper 2.2.3: Perceiving QUIC: do users notice or even care? 7

Research paper 2.2.4: How quick is QUIC? 9

Research paper 2.2.5: A QUICK Implementation for ns-3 10

Research paper 2.2.6: 0-RTT Attack and Defense of QUIC Protocol 11

Research paper 2.2.7: QUIC Protocol Performance in Wireless Networks 12

Research paper 2.2.10: Assessing the Impact of QUIC on Network Fairness 17

Research paper 2.2.11: Observing the Evolution of QUIC Implementations 18

Research paper 2.2.13: Implementation and Performance Evaluation of the

Research paper 2.2.14: How Good Is QUIC Actually? 23

2.2 Systematic Review 24

2.2.1 Background-Qualitative Evaluation 25

3.1 Description of System 29

3.2 Functional Requirements and Non-Function Requirements 29

3.2.1 Functional Requirements 30

3.2.2 Non-Functional Requirements 30

3.3 Proposed Solution 31

3.4 Evaluation of Tools/Approaches-Pros and Cons 32

3.4.1 Programming Language 32

3.4.2 Integrated Development Environment (IDE) 34

3.5 Choice of Final Tools Approached with Justifications 36

3.5.1 Programming Language 36

3.5.2 Integrated Development Environment (IDE) 36

3.6 Software Modelling: Use Case Diagram 37

4.1 Design Issues 39

4.1.6 Quality of Service 40

4.2 Architectural Design 40

4.2.1 QUIC Layers of OSI Model 41

4.2.2 QUIC Structure 41

4.2.3 QUIC Layers 43

4.2.4 QUIC and TLS interactions 43

4.3 System Modelling 44

4.3.1 Authentication Flowchart Diagram 45

4.3.2 Sequence Diagram 46

4.3.3 State Transition Diagram 48

5.1 Developments Tools and Environment Used 51

5.1.1 Hardware Specifications 51

5.1.2 Software Specifications 52

5.2 Standards and Conventions 52

5.2.1 Naming Conventions 52

5.2.2 Coding Conventions 53

5.3 Implementation of Different Modules 53

5.3.1 Certificate Compression Module 53

5.3.2 Key Update Module 58

5.3.3 Speed up Handshake Module 61

5.4 Difficulties Faced and How They Were Addressed 63

5.5 Implementation Issues 64

6.1 Unit Test 67

6.1.1 White Box Testing 67

6.1.2 Black Box Testing 67

6.2 Test Cases 67

6.2.1 Running Client Against a Local Server 68