QUIC is a general-purpose transport layer network protocol proposed as the replace- ment for TCP and TLS in HTTP/3. QUIC is based on UDP and provides always- encrypted connections able to transmit multiple streams of data in parallel. Compared to TCP, QUIC promises lower latency, better congestion control flexibility, and a solution to head-of-line blocking occurring in multiplexed HTTP/2 connections. The latest release of .NET - .NET 5 - has shipped with experimental support for QUIC based on the MsQuic C library. However, when implementing new features in stan- dard .NET libraries, purely .NET implementations are preferable to adding dependencies on native libraries because .NET implementations offer better maintainability and - in some cases - even better performance. This thesis explores the viability of a purely C# QUIC implementation as a future replacement for .NET 6 or later release. This thesis's result is a fork of the official .NET runtime repository with partial C# implementation of the QUIC protocol. We implemented a subset of the QUIC speci- fication, which is sufficient for a basic performance evaluation. As part of the thesis, we have benchmarked the throughput and latency of our and the MsQuic-based QUIC implementation and compared them to TCP's performance in two environments: LAN and...

TCP is a widely used protocol for web traffic. However, TCP€™s connection setup and congestion response can impact web page load times, leading to higher page load times for users. In order to address this issue, Google came out with QUIC (Quick UDP Internet Connections), a UDP-based protocol that runs in the application layer. While already deployed, QUIC is not well-studied, particularly QUIC€™s congestion response as compared to TCP€™s congestion response which is critical for stability of the Internet and flow fairness. To study QUIC€™s congestion response we conduct three sets of experiments on a wired testbed. One set of our experiments focused on QUIC and TCP throughput under added delay, another set compared QUIC and TCP throughput under added packet loss, and the third set had QUIC and TCP flows share a bottleneck link to study the fairness between TCP and QUIC flows. Our results show that with random packet loss QUIC delivers higher throughput compared to TCP. However, when sharing the same link, QUIC can be unfair to TCP. With an increase in the number of competing TCP flows, a QUIC flow takes a greater share of the available link capacity compared to TCP flows.

Várias características da Internet mudaram drasticamente desde que o TCP foi criado, como o maior compartilhamento de recursos devido à maior quantidade de usuários, maior largura de banda disponível, a existência de muitas conexões que podem percorrer longas distâncias e a ubiquidade das redes sem fio. Confrontado com essas novas características, o TCP apresenta diversas limitações. Dentre elas estão a subutilização da rede quando a largura de banda é da ordem de centenas de Gbps, o favorecimento de conexões que possuem pouco atraso (poucas dezenas de milisegundos), a incapacidade de distinção de causas de perdas de pacote e a demora para estabelecimento de conexões seguras (até 3 RTTs). Nesse contexto, com o objetivo de tornar o transporte de dados na Internet mais rápido e eficiente, a Google desenvolveu o protocolo QUIC. O QUIC propõe diversos avanços em relação aos protocolos existentes, como um novo mecanismo para estabelecimento de conexão e controle de congestionamento otimizado. Resultados apresentados pela Google mostraram claro ganho de desempenho em relação ao TCP, justificando o trabalho de tornar o QUIC um padrão IETF da Internet. Porém, esses resultados são impossíveis de serem verificados porque nos relatórios divulgados não há informação suficiente para que os cenários de teste sejam reproduzidos e porque é implausível possuir a mesma infraestrutura para os testes que a Google tem. Neste trabalho, avaliamos o desempenho do protocolo QUIC em diversos cenários de rede, comparando-o com o desempenho de várias implementações do TCP, principalmente o CUBIC. Diferente do realizado na literatura, todos os cenários utilizados são bem descritos, permitindo a reprodutibilidade dos experimentos. Além disso, para a realização dos experimentos foi criado um novo módulo que implementa o QUIC no simulador de redes NS-3. Este módulo está disponível como software livre, permitindo que outros pesquisadores usem o módulo para replicar e verificar nossos experimentos e para criarem novos experimentos de forma reprodutível. Ademais, eles também podem usar o módulo como uma ferramenta para avaliar, de maneira rápida, o comportamento de novas técnicas dentro do protocolo. / Many characteristics of the Internet have drastically changed since TCP was created such as the increase on resource sharing due to a larger number of Internet users, the growth of available bandwidth, the existence of many connections that may travel long distances and the ubiquity of wireless networks. When faced with those new characteristics, TCP showed severe limitations. Among them are network underutilization in high bandwidth environments of hundreds of Gbps, favoring of connections with small delays (few tens of milliseconds), incapacity of distinguishing packet loss causes and high delays for establishing secure connections (up to 3 RTTs). In this context, with the goal of making Internet data transport faster and more efficient, Google has developed the QUIC protocol. QUIC proposes many advances compared to existing protocols, such as a new mechanism for establishing connections and an optimized congestion control algorithm. Google has reported results indicating that QUIC performs better than TCP, justifying the work on making QUIC an IETF Internet standard. However, those results cannot be verified because on the published reports there is not enough information to reproduce the test scenarios and it is implausible to have the same test infrastructure Google has. In this work, we evaluate QUICs performance in a number of network scenarios, comparing it with the performance of different TCP flavours, specially TCP CUBIC. Unlike other works in the literature, all scenarios are well described, enabling experiment replicability. Furthermore, to run experiments we created a new module that implements QUIC on the network simulator NS-3. The module is available as free software, allowing other researchers to use it to reproduce and verify our experiments and to create new ones in a replicable way. Additionally, they can use the module as a tool to quickly assess the behaviour of new techniques in the protocol.

Várias características da Internet mudaram drasticamente desde que o TCP foi criado, como o maior compartilhamento de recursos devido à maior quantidade de usuários, maior largura de banda disponível, a existência de muitas conexões que podem percorrer longas distâncias e a ubiquidade das redes sem fio. Confrontado com essas novas características, o TCP apresenta diversas limitações. Dentre elas estão a subutilização da rede quando a largura de banda é da ordem de centenas de Gbps, o favorecimento de conexões que possuem pouco atraso (poucas dezenas de milisegundos), a incapacidade de distinção de causas de perdas de pacote e a demora para estabelecimento de conexões seguras (até 3 RTTs). Nesse contexto, com o objetivo de tornar o transporte de dados na Internet mais rápido e eficiente, a Google desenvolveu o protocolo QUIC. O QUIC propõe diversos avanços em relação aos protocolos existentes, como um novo mecanismo para estabelecimento de conexão e controle de congestionamento otimizado. Resultados apresentados pela Google mostraram claro ganho de desempenho em relação ao TCP, justificando o trabalho de tornar o QUIC um padrão IETF da Internet. Porém, esses resultados são impossíveis de serem verificados porque nos relatórios divulgados não há informação suficiente para que os cenários de teste sejam reproduzidos e porque é implausível possuir a mesma infraestrutura para os testes que a Google tem. Neste trabalho, avaliamos o desempenho do protocolo QUIC em diversos cenários de rede, comparando-o com o desempenho de várias implementações do TCP, principalmente o CUBIC. Diferente do realizado na literatura, todos os cenários utilizados são bem descritos, permitindo a reprodutibilidade dos experimentos. Além disso, para a realização dos experimentos foi criado um novo módulo que implementa o QUIC no simulador de redes NS-3. Este módulo está disponível como software livre, permitindo que outros pesquisadores usem o módulo para replicar e verificar nossos experimentos e para criarem novos experimentos de forma reprodutível. Ademais, eles também podem usar o módulo como uma ferramenta para avaliar, de maneira rápida, o comportamento de novas técnicas dentro do protocolo. / Many characteristics of the Internet have drastically changed since TCP was created such as the increase on resource sharing due to a larger number of Internet users, the growth of available bandwidth, the existence of many connections that may travel long distances and the ubiquity of wireless networks. When faced with those new characteristics, TCP showed severe limitations. Among them are network underutilization in high bandwidth environments of hundreds of Gbps, favoring of connections with small delays (few tens of milliseconds), incapacity of distinguishing packet loss causes and high delays for establishing secure connections (up to 3 RTTs). In this context, with the goal of making Internet data transport faster and more efficient, Google has developed the QUIC protocol. QUIC proposes many advances compared to existing protocols, such as a new mechanism for establishing connections and an optimized congestion control algorithm. Google has reported results indicating that QUIC performs better than TCP, justifying the work on making QUIC an IETF Internet standard. However, those results cannot be verified because on the published reports there is not enough information to reproduce the test scenarios and it is implausible to have the same test infrastructure Google has. In this work, we evaluate QUICs performance in a number of network scenarios, comparing it with the performance of different TCP flavours, specially TCP CUBIC. Unlike other works in the literature, all scenarios are well described, enabling experiment replicability. Furthermore, to run experiments we created a new module that implements QUIC on the network simulator NS-3. The module is available as free software, allowing other researchers to use it to reproduce and verify our experiments and to create new ones in a replicable way. Additionally, they can use the module as a tool to quickly assess the behaviour of new techniques in the protocol.

Chronic neurodegenerative diseases, such as Alzheimer’s disease, prion diseases and many others are unified by the aberrant folding of a host encoded protein to a disease-associated isoform and the predictable cell-to-cell spread of disease-associated misfolded proteins via a putative prion-like mechanism. Prion diseases, for example, are associated with the aberrant folding of host encoded prion protein (PrPC) to a disease-associated isoform, which acts as a seed for the further conversion of PrPC to misfolded protein species. The role of misfolded prion protein in neurodegeneration remains unclear. Accumulation and spread of misfolded prion protein is typically slow and progressive, correlating with neurodegeneration. A number of studies show that mice are susceptible to prion disease with characteristic hallmarks of prion pathology but in the presence of little detectable misfolded prion protein (e.g. the GSS/101LL model). In this thesis I test the hypothesis that detectable species of misfolded prion protein correlate with neurodegeneration and spreads in a predictable, progressive fashion from one anatomically distinct brain region to the next. Using the GSS/101LL model, misfolded prion protein was detected as mostly PK-sensitive isoforms (PrPsen). The progression and pathological presentation is comparable to other prion diseases with larger quantities of PK resistant prion isoforms. A highly sensitive in vitro assay system (the QuIC assay) was subsequently used to establish the extent that misfolded protein was present within the brain. Amyloidogenic prion seeds were found to be widespread throughout the brain from an early stage and spread rapidly throughout the brain. Absence of neurodegeneration in certain brain regions is not due to differing quantities of prion seeds between regions or time exposed to prion seeds, as unaffected regions are exposed to comparative quantities of prion seeds for the same time-period as regions of the brain which eventually succumb to neurodegeneration. These results indicate a clear dissociation between prion seeds and neurotoxicity. They highlight the need to understand regional host responses to prion seeds that may evoke neurodegeneration in some but resilience in others. To test this, transcriptomic analysis was carried out on brain samples from regions undergoing neurodegeneration and unaffected regions. A gene profile signature of hybrid pro-and anti-inflammatory response was observed in regions undergoing neurodegeneration. However, large cohorts of genes were down-regulated across all regions tested, including pro-inflammatory genes and a large proportion of genes involved within transcriptional and translational regulation and function. These results highlight the possible molecular pathways in response to the presence of misfolded protein. In summary, misfolded prion protein accumulates rapidly across the CNS but only specific brain regions undergo neurodegeneration. In the presence of the misfolded protein, the host elicits a robust molecular response. The additional activation of glial cells within regions undergoing neurodegeneration highlights their importance in disease. It is therefore proposed that misfolded prion protein, alone, is not sufficient to trigger neurodegeneration. This gives rise to a “multi-hit” hypothesis whereby two or more factors, for example the accumulation of misfolded protein and glial cell response, are required to trigger neurodegeneration.

QUIC is a relatively new transport layer network protocol that has gained popularity over the last few years. The protocol was initially developed by Google and standardization work has been continued by the Internet Engineering Task Force (IETF) with the goal of it becoming the next generation transport protocol. While the standardization work is not yet finished, the protocol has seen a large adoption, already covering a large portion of the internet traffic. As a new protocol, many researchers have studied QUIC and compared it to TCP in typical scenarios. However, few studies have been performed on QUIC in specific scenarios. In this thesis, we present the first performance study of QUIC over Dual Connectivity (DC). DC is a multi-connectivity technique that allows users to connect to multiple cell towers with one user equipment. It is an important lower-layer feature accelerating the transition from 4G to 5G, which is also expected to play an important role in standalone 5G networks. With DC, higher throughput and reliability can be achieved by using multiple paths simultaneously. However, the drawback of DC is that it introduces packet reordering and jitter, which can significantly impact the performance of upper-layer protocols such as TCP and QUIC. To study the extent of this effect, a testbed is set up to evaluate QUIC over DC. Our performance evaluation compares the throughput of QUIC over DC with that of TCP over DC, and evaluates the fairness of QUIC over DC. Using a series of throughput and fairness experiments, we show how QUIC is affected by different DC parameters, network conditions, and whether the DC implementation aims to improve throughput or reliability. Our findings provide network operators with insights into understanding the impacts of splitting QUIC traffic in a DC environment. We show the value of increasing the UDP receive buffers when running QUIC over DC and that QUIC can utilize the increased bandwidth and reliability in DC, provided that the links' characteristics are similar. We also show that with reasonably selected DC parameters and increased UDP receive buffers, QUIC over DC performs similarly to TCP over DC and achieves optimal systemwide fairness under symmetric link conditions when DC is not used for packet duplication.

The number of devices and internet traffic for applications connected to the internet increases continuously. Devices provide increasing support for multi-homing and can utilize different access networks for end-to-end communication. The simultaneous use of multiple access networks can increase end-to-end performance by aggregating capacities from multiple disjoint networks by exploiting multipath communication. However, at this current point in time, multipath compatible transport layer protocols or multipath support at lower layers of the network stack have not seen widespread adaptation. Tunneled transport layer access bundling is an approach that allows for all types of single-path resources to exploit multipath communication by tunneling data over a Virtual Private Network (VPN) with transparent entry points on the User Equipment (UE) and on the internet. Commonly, such adaptation utilizes a single queue to buffer incoming packets which pose problems with fair multiplexing between concurrent application flows while being susceptible to bufferbloat. We designed and implemented extensions to Pluganized QUIC (PQUIC) which enables Flow Queuing Controlled Delay (FQ-CoDel) as a queueing discipline in tunneled transport layer access bundling to investigate if it is possible to achieve fair multiplexing between application flows while mitigating bufferbloat at the transport layer. An evaluation in the network emulator, mininet, shows that FQ-CoDel can add mechanisms for an instant, constant, and fair access to the VPN while significantly lowering the end-to-end latency for tunneled application flows. Furthermore, the results indicate that packet schedulers, such as Lowest-RTT-First (LowRTT) that adapt to current network characteristics, upholds the performance over heterogeneous networks while keeping the benefits of FQ-CoDel.

Congestion control is an important aspect of network technology, where traffic load is balanced to not cause an overflow in the system. Google has proposed its own protocol, QUIC, which is described as being set to supersede the TCP protocol. QUIC has several advantages, namely having high efficiency and low latency, but also a more flexible congestion control due to it being situated in the user space. To be used in tandem with QUIC, Google developed a new congestion control algorithm called BBR meant to fully exploit these advantages, by reducing latency and increasing throughput. However, as BBR is still a rather new algorithm, there are many different improvements possible to make it more efficient. In this paper, a modified BBR algorithm (mBBR) is proposed, which is comprised of three other algorithms meant to improve BBR by adjusting the otherwise static congestion window and pacing rate gain values based on the round-trip time flow, and is compared to the CUBIC, NewReno, and QUIC/TCP BBR algorithms. mBBR has a greatly lower RTT over CUBIC and NewReno, and reduces it by as much as 20% over the default QUIC BBR algorithm, while maintaining the same level of throughput. This improvement makes mBBR more suitable for usage in RAN-applications and other areas where a lower delay is crucial, without sacrificing network speeds.

QUIC is an emerging connection-oriented transport layer protocol that aims to support low-latency and highly secure communication between users and cloud services. Cloud load balancers distribute incoming QUIC connections towards a pool of backend servers where applications run. The sheer size of today’s clouds requires to deploy large pools of load balancing instances across multi-core servers. Today, once a connection is handled by a load balancing instance, the handling of the connection cannot be delegated to another instance which is possibly running on an underutilized server or core. Recent work has shown that such imbalances lead to poor utilization of the server resources when implementing the load balancer component itself. Moving the handling of a connection from one load balancing instance to another one is key to achieve uniform distribution of the workload among the load balancing instances. This thesis discusses the system design, algorithmic principles, and evaluation of an approach to move the state of a QUIC connection from one QUIC instance to another one, a task that we call “connection migration”. Our preliminary investigation focuses on inter-CPU-core thread-based migration of QUIC connections within the same server machine with the goal of supporting different types of load balancers that dynamically spread the workload across the load balancing instances. We evaluated the performance of the proposed implementation in a real physical testbed in NSLab at KTH across different dimensions: the number of active connections, the size of the file transfers within each connection, and the number of load balancing instances. The results show that under ideal circumstances, the throughput of a server system built by an 8-core computer reaches 100MB per second and handles up to 500 client requests per second. Finally, this thesis analyzes the bottleneck of the system and the critical parts of the implementation that should be optimized for better performance. / QUIC är ett framväxande anslutningsorienterat protokoll för transportlager som syftar till att stödja låg latens och mycket säker kommunikation mellan användare och molntjänster. Molnslastbalansering distribuerar inkommande QUIC-anslutningar mot en pool av Backend-servrar där applikationer körs. Den stora storleken på dagens moln kräver att stora pooler av lastbalanseringsinstanser distribueras över flerkärniga servrar. Idag, när en anslutning hanteras av en lastbalanseringsinstanser, kan hanteringen av anslutningen inte delegeras till en annan instans som möjligen körs på en underutnyttjad server eller kärna. Senaste arbetet har visat att sådana obalanser leder till dåligt utnyttjande av serverresurserna vid implementering av själva lastbalanseringskomponenten. Att flytta hanteringen av en anslutning från en lastbalanseringsinstans till en annan är nyckeln för att uppnå enhetlig fördelning av arbetsbelastningen mellan lastbalanseringsinstanserna. Denna avhandling diskuterar systemdesign, algoritmiska principer och utvärdering av en metod för att flytta tillståndet för en QUIC-anslutning från en QUIC-instans till en annan, en uppgift som vi kallar “anslutningsmigrering”. Vår preliminära undersökning fokuserar på intel-CPU-core trådbaserad migration av QUIC-anslutningar inom samma servermaskin med målet att stödja olika typer av belastningsutjämnare som dynamiskt sprider arbetsbelastningen över lastbalanseringsinstanser. Vi utvärderade prestanda för den föreslagna implementeringen i en riktig fysisk testbädd i NSLab vid KTH över olika dimensioner: antalet aktiva anslutningar, storleken på filöverföringarna inom varje anslutning och antalet lastbalanseringsinstanser. Resultaten visar att under idealiska omständigheter når genomströmningen av ett serversystem som byggts av en 8-kärnig dator 100 MB per sekund och hanterar upp till 500 klientförfrågningar per sekund. Slutligen analyserar denna avhandling systemets flaskhals och de kritiska delarna av implementeringen som bör optimeras för bättre prestanda.

Since 2012 Google has been developing a new transport protocol called QUIC (Quick UDP Internet Connections). The purpose of the QUIC-protocol is to speed up the web and first of all produce lower response time on websites. This is interesting in several perspectives. First of all, this is good news for the common user that browse the web but also in an economical perspective. Studies show that quicker response time on websites attracts customers both short term and long term which is important in areas as e-commerce. On top of this the Internet alone (home computers, data centers etc.) stands for about 10% of the worlds electricity consumption and a quicker and more effective transport protocol could contribute to lower this number since a lot of data is transferred through the Internet each day. QUIC is already in use by many of Google´s servers and can be used when browsing the web in a chrome or Opera browser. This means that many people have already been in touch with QUIC unknowingly. This degree project focuses on the main problems which makes the QUICprotocol needed and compares QUIC to TCP. TCP has been the dominating transport protocol regarding reliable data transmission for decades and still is. In this project an environment for testing is implemented which makes it possible to compare response time for websites. Two different tests are made where different common internet conditions are simulated to see how these conditions effects the response time for each protocol. The tests have shown that QUIC and TCP are pretty much equal regarding response time when the delay is 100 ms or less and there is no packet loss. When the delay exceeds 100 ms have our tests shown that QUIC delivers quicker response times. The tests have also shown that QUIC is superior to TCP when data is transferred over a connection with packet losses. Although it can be questioned if we could have optimized our TCP-server to compete with QUIC in a better way. / Google utvecklar sedan 2012 ett nytt pålitligt transportprotokoll, QUIC (Quick UDP Internet Connections). Syftet med detta är att göra webben ”snabbare” genom att bland annat minska svarstider för hemsidor. Detta är intressant ur en mängd perspektiv. Dels ur användarsynpunkt vid surf på webben men även ur ett rent ekonomiskt perspektiv då forskning visar att snabbare hemsidor lockar fler kunder både på kort och lång sikt vilket är intressant inom t ex. ehandel. Dessutom beräknas Internet stå för ungefär 10% av all elkonsumtion på hela planeten och ett snabbare och effektivare transportprotokoll kan förhoppningsvis bidra till att förbättra den siffran. QUIC används redan idag på flera av Googles egna servrar och uppkopplad mot Internet med webbläsaren Chrome eller Opera har användaren med stor sannolikhet redan stött på QUIC utan att veta om det. Detta arbete fokuserar på några av de problem som ligger som grund för vad QUIC är tänkt att förbättra och jämförs sedan med transportprotokollet TCP som har varit standardprotokollet för pålitlig dataöverföring i decennier. I arbetet upprättas en testmiljö som gör det möjligt att mäta svarstider på en webbklient för de olika protokollen vid olika simulerade förhållanden. Testerna går ut på att variera fördröjning och paketförluster för att se hur detta påverkar svarstiderna för respektive protokoll. Jämförelsen har resulterat i att QUIC och TCP är jämna i avseende på svarstider då inga paketförluster förekommer och fördröjningen är 100 ms eller lägre. Däremot när fördröjningen ökar till en nivå över den genomsnittliga fördröjningen överstiger 100 ms så pekar våra tester på att QUIC levererar snabbare svarstider. Dessutom har testerna visat att QUIC är överlägset TCP gällande svarstider då paketförluster förekommer. Det kan dock ifrågasättas huruvida vår TCP-server hade kunnat optimerats för hålla jämnare steg med QUIC.