Beyond QUIC v1: A First Look at Recent Transport Layer IETF Standardization Efforts
11 Beyond QUIC v1 – A First Look at RecentTransport Layer IETF Standardization Efforts
Mike Kosek, Tanya Shreedhar, and Vaibhav Bajpai
Abstract —The transport layer is ossified. With most ofthe research and deployment efforts in the past decadefocussing on the Transmission Control Protocol (TCP)and its extensions, the QUIC standardization by theInternet Engineering Task Force (IETF) is to be finalizedin early 2021. In addition to addressing the most urgentissues of TCP, QUIC ensures its future extendibility andis destined to drastically change the transport protocollandscape. In this work, we present a first look at emergingprotocols and their IETF standardization efforts beyond
QUIC v1 . While multiple proposed extensions improve onQUIC itself, Multiplexed Application Substrate over QUICEncryption (MASQUE) as well as
WebTransport presentdifferent approaches to address long-standing problems,and their interplay extends on QUIC’s take to addresstransport layer ossification challenges.
Index Terms —Transport protocols, IETF, QUIC,MASQUE, WebTransport
I. I
NTRODUCTION
The transport layer, which is responsible for theend-to-end connectivity between peers, is ossified[1]. While most of the transport protocol related re-search in the past decade focussed on the extensionof TCP as the predominant transport protocol in theInternet, multiple studies showed that this quest iscumbersome, leading to slow adoption of innovativeimprovements like Explicit Congestion Notification(ECN) (RFC 3168) or Multipath TCP (MPTCP)(RFC 6824), or even no adoption at all. Whereprevious efforts to deploy novel transport protocolslike Stream Control Transmission Protocol (SCTP)(RFC 4960) also did not lead to a wide adoptiondue to deployment obstacles for non-TCP/UDP-based protocols, using UDP as a substrate proto-col promises Internet-scale deployability. Recently,QUIC as a UDP-based protocol set out to solveTCP’s issues while ensuring its future extendibility[2]. While QUIC is destined to drastically changethe transport protocol landscape, TCP is still themost used protocol, and its importance will notdiminish in the near future. Acting as a fallback protocol, services will be offered with both TCP and
QUIC for an extensive amount of time, andmore specialized use-cases like Border GatewayProtocol (BGP) (RFC 4271) might continue to useTCP indefinitely. To ensure continuous improve-ments, the IETF TCP Maintenance and Minor Ex-tensions (TCPM) Working Group (WG) discussesTCP and MPTCP modifications, and directs thestandardization process for proposed specifications.Within TCPM, RFC 8803 as well as RFC 8961were recently standardized. The (RFC 8803) aims at improving the deploy-ment of TCP extensions, where
Requirements forTime-Based Loss Detection (RFC 8961) discussesbest practices to parameterize loss detection algo-rithms.
The RACK-TLP loss detection algorithm forTCP [3] was submitted to the Internet EngineeringSteering Group (IESG) for publication in December2020, leveraging Recent Acknowledgements for fastrecovery and improving on tail loss by explicitlytriggering ACK feedback through Tail Loss Probes.While these additions are essential improvements toTCP, they may not overcome TCP’s inherent issues.With the standardization of QUIC by the IETFto be finalized in early 2021, QUIC’s first version v1 (see §II) addresses the most urgent issues ofTCP such as multiplexing, Head-of-line blocking(HOL blocking), mandatory encryption, as well asreduced connection establishment time with 0-RTTsupport while focussing on the web use-case, i.e.,delivery of web content to browsers. Extending on v1 , the WG actively discusses future extensions,which we will detail in §III. These extensionsintroduce improvements to version negotiation aswell as connection IDs, add multipath capabilities,enable unreliable delivery within QUIC as well asHTTP/3, further extend the future useability of theQUIC protocol, and add performance improvementsby negotiating acknowledgement handling.QUIC’s mandatory encryption does provide chal-lenges for specialized use-cases where end-to-end a r X i v : . [ c s . N I] F e b connectivity is not possible (e.g., censorship), notfeasible (e.g., satellite links), or not wanted (e.g.,privacy concerns). The IETF MASQUE WG waschartered to address these challenges.MASQUE (see §IV) proposes the use of QUICas a substrate protocol, allowing arbitrary data tobe tunneled over QUIC. While this addresses TCPproxy use-cases, it also introduces an alternativelayering of Virtual Private Networks (VPNs), wherenested reliability can be avoided by leveragingQUIC datagram frames.While QUIC and MASQUE set out to changeour transport protocol usage, the web security modellimits browser-based web applications to directly ac-cess transport protocol features. Protocols like Web-Socket (RFC 6455) and WebRTC (RFC 7478) [4]were indispensable in rejuvenating static request-response-based web content and benefited fromyears of deployment of their substrate protocols.However, they also inherited their fundamental dis-advantages. The WebTransport WG (see §V) ad-dresses these shortcomings by utilizing QUIC as asubstrate protocol, exposing its features to browser-based web applications while considering fallbackmechanisms to traditional TCP-based connections.In this article, we present a first look at thesemost recent transport layer IETF standardizationefforts beyond QUIC v1 . While our work does notcover advances in congestion control schemes suchas Bottleneck Bandwidth and Round-trip propaga-tion time (BBR) or related standardization workby the Internet Congestion Control Research Group(ICCRG), we refer the inclined reader to [5] [6]. Theremainder of this article is structured as follows: §IIbriefly introduces QUIC, where §III details futureextensions beyond v1 . §IV presents recent develop-ments in the usage of QUIC as a substrate protocolwithin MASQUE, where §V details the advances ofproviding novel transport protocol features withinthe web security model pursued by the WebTrans-port WG. Finally, §VI details the interplay of thepresented IETF standardization efforts, followed bythe conclusion in §VII.II. QUIC V IETF96
Jul
IETF97
Nov
IETF106
Nov
IETF107
Mar
IETF107
Mar
IETF108
Jul
IETF108
JulQUIC WebTransport MASQUE B O F P r opo s ed W G W G B O F W G B O F W G Fig. 1.
Timeline of recent IETF transport layer standardizationefforts. The QUIC working group was established at IETF ’97in 2016, followed by the establishment of MASQUE as well asWebTransport at IETF ’108 in 2020. and Android YouTube app users were using QUIC.QUIC provides stream multiplexing without thedrawbacks of TCP’s HOL blocking. The initial de-sign idea of QUIC was provided by SPDY, whichwas later standardized as HTTP/2 (RFC 7540),enabling the multiplexing of streams using the sameTCP connection. The IETF chartered the QUICworking group in 2016 (see Figure 1) to providea standards-track specification for a UDP-based,stream-multiplexing, encrypted transport protocolbased on Google’s pre-standardization implemen-tation and deployment experiences. QUIC’s WGcharter holds several goals and milestones relatingto the core transport functionality, security, themapping between different HTTP protocols, theextension of core protocol facilities, and the applica-bility and manageability of the implications of theprotocol. QUIC mitigates the HOL blocking issueby leveraging stream multiplexing in the transportlayer, improves on connection establishment timesby sending a cryptographic handshake as part ofthe transport handshake, and provides 1-RTT hand-shakes for first-time connections as well as 0-RTThandshakes for subsequent connections using TLS1.3 (RFC 8446).III. QUIC E
XTENSIONS
While the working group initially focussed on theweb use-case, many QUIC extensions have recentlybeen proposed. In the following, we will discuss theproposals listed in Table I.
An Unreliable Datagram Extension to QUIC:
QUIC transmits a reliable stream of application datawhere reliability is achieved on a per-stream basis.The proposed extension enhances QUIC with thesupport for unreliable datagrams, aiding in use-caseswhere reliability is undesired (e.g., real-time com-munication). With its reduced handshake latency,
WG Document Type Reference
QUIC WG Charter Charter /wg/quic/about/An Unreliable Datagram Extension to QUIC WG I-D draft-ietf-quic-datagramQUIC-LB: Generating Routable QUIC Connection IDs WG I-D draft-ietf-quic-load-balancersCompatible Version Negotiation for QUIC WG I-D draft-ietf-quic-version-negotiation3GPP Access Traffic Steering Switching and Splitting Ind I-D draft-bonaventure-quic-atsss-overviewMultipath Extensions for QUIC Ind I-D draft-deconinck-quic-multipathMultipath Extension for QUIC Ind I-D draft-liu-multipath-quicGreasing the QUIC Bit Ind I-D draft-quic-bit-greaseSender Control of Acknowledgement Delays in QUIC Ind I-D draft-quic-delayed-ackTABLE IO
VERVIEW OF
QUIC IETF D
OCUMENTS . T YPE
DIFFERENTIATES D OCUMENT TYPE : WG C
HARTERS ARE DENOTED AS C HARTER , ADOPTED I NTERNET -D RAFTS AS
WG I-D , AND INDIVIDUAL DRAFTS AS I ND I-D . unreliable delivery via QUIC improves on existingsolutions such as DTLS (RFC 6347). Moreover, itsmulti-streaming feature can be leveraged to mul-tiplex reliable and unreliable streams within oneconnection, thereby providing partial reliabilty, anduse pluggable congestion control where required.Another use-case for unreliable delivery are VPNs,requiring generic IP packet tunnelling as providedby MASQUE (see §IV). QUIC-LB: Generating routable QUIC connectionIDs:
QUIC maintains a connection ID (CID) perconnection, which allows migration during networkchanges, and provides unlinkability features acrossconnection migration. If servers do not provideadditional CIDs, they might choose linkable CIDsfrom servers behind load balancers. In this situ-ation, the client either terminates the connectionduring the migration or remains linkable, violatingQUIC’s design goal. QUIC-LB specifies standardsfor encoding routing information given a small setof configuration parameters. Using QUIC-LB, load-balancers communicate the algorithm parametersto generate routable CIDs rather than generatingindividual CIDs to servers.
Compatible version negotiation for QUIC:
Cur-rently, the QUIC server indicates if a client offeredversion is not accepted, but does not provide in-formation to select a mutually supported version.The proposed version negotiation mechanism allowsa client and a server to leverage the similaritiesbetween different versions and establish a mutuallysupported/compatible version without the overheadof extra round trips.
Multipath Extension for QUIC:
The QUIC Mul-tipath extension preserves the single-path QUICdesign features while simultaneously using multiplepaths for a single connection. The introduction andpreliminary work on multipath QUIC was presented in [8]. Recently, the 3rd Generation PartnershipProject (3GPP) started a discussion to enable AccessTraffic Steering, Switching, and Splitting (ATSSS)service for QUIC on multiple paths, where IETFstandardization and specifications can be beneficialto attain the ATSSS design goals. Table I lists theInformational 3GPP ATSSS Overview document, aswell as multiple individual multipath QUIC draftswhich are actively discussed within the WG. As ofnow, no consensus has been reached on the adoptionof multipath QUIC in general, or a specific proposalin particular. While all proposals differ in their wayto handle multipath QUIC requirements like link-ability between flows, they are commonly in-linewith multipath extensions of other transport proto-cols such as Concurrent Multipath Transfer SCTP(CMT-SCTP) [9] or MPTCP (RFC 8684) [10].These include features like bandwidth aggregation,seamless handovers, and improved user Quality-of-Experience related to the increasing number ofmulti-homed devices. As an example, connectionmigration can be leveraged on ordinary QUIC con-nections to move a single QUIC flow from one IPaddress to another, resulting in a hard handover .Like MPTCP, multipath QUIC improves on this,allowing devices to seamlessly switch from oneinterface to another, thus providing resilience toconnection failures. Extending on these commonmultipath features, the primary motivation behindmultipath QUIC however lies in the aggregation ofall available network resources to send data througha single connection [11]. While this is useful fore.g., large transfers, it also benefits dual-stackedhosts, automatically selecting the best available pathin case the quality of the IPv4 and IPv6 paths differ[12]. A descriptive example of multipath QUIC ispresented in §VI.
Greasing the QUIC Bit:
Intermediaries and end- points use the
QUIC Bit to distinguish QUIC fromother protocols. A fixed value is currently sent inthe QUIC Bit of every packet, thus allowing end-points and intermediaries to depend on a fixed value.By leveraging the concept of
GREASE (GenerateRandom Extensions And Sustain Extensibility), the grease_quic_bit transport parameter ensures the fu-ture usage of the QUIC Bit by indicating thatan end-point is willing to receive QUIC packetsregardless of this bit’s value.
Sender Control of Acknowledgement Delays inQUIC:
A receiver acknowledges the reception ofdata from the sender. Delaying these acknowledge-ments reduces the CPU utilization at both senderand receiver and potentially improves throughput.However, these benefits are traded off by negativelyimpacting congestion control and loss recovery.The
Sender Control of Acknowledgement Delays inQUIC extension allows the end-points to advertisethe min_ack_delay transport parameter, which de-fines the minimum amount of time an ACK can bedelayed.While these proposals improve on QUIC, thereusage requires both communication partners to mu-tually support an extension. As deployment experi-ence with TCP has shown, this can lead to slowadoption, or even no adoption at all.
PluginzingQUIC [13] enables QUIC end-points to dynamicallyexchange protocol extensions on a per-connectionbasis, therefore requiring only one communicationpartner to feature an extension.IV. MASQUEDriven by the shortcomings of proxying mech-anisms like native HTTP Proxies (unencrypted,HTTP/TCP), Socket Secure (SOCKS) (unencryptedsignaling, TCP and UDP), HTTP CONNECT (en-cryption optional, TCP), or transparent TCP Proxies(must be on-path, mandatory to use, TCP), theIETF MASQUE WG (see Figure 1) was formedin early 2020. MASQUE is chartered to developmechanisms that will allow arbitrary connectionsto be tunneled within a single HTTP/3 connectionusing explicit client-initiated signaling. Besides theexisting request/response model and authenticationmechanisms of HTTP, which can be leveraged forservice and parameter negotiation, QUIC’s unifiedcongestion controller will greatly improve on theuncoupled flows handled by traditional proxies, and allow multiple client-initiated reliable and unreli-able connections to be transported within a singleHTTP/3 connection. To address censorship use-cases, the tunneled data will be indistinguishable toarbitrary encrypted HTTP connections on the wire,preventing hints which possibly expose the nature ofthe connection to adversaries. Moreover, to addressinstances where UDP and/or HTTP/3 is activelyblocked on the client-proxy leg of the connection,the MASQUE WG will consider HTTPS/TCP as afallback.Initially proposed within the QUIC WG,
UsingQUIC Datagrams with HTTP/3 (see Table II) wasrecently moved to and adopted by the MASQUEWG as a WG Internet draft. While the unreli-able datagram extension of QUIC (see §III) pro-vides a mechanism to send reliable and unreli-able data simultaneously leveraging the securityand congestion-control properties of QUIC, it isunable to de-multiplex application contexts.
UsingQUIC Datagrams with HTTP/3 adds flow identifiersfor HTTP/3 applications at the start of the framepayload. This
Datagram-Flow-Ids represent bidirec-tional flows in a single QUIC connection and allowmultiplexing and de-multiplexing of the applicationdata. This concept is leveraged within MASQUE aswell WebTransport (see §V).As a primary focus for the WG,
CONNECT-UDP (see Table II) proposes a UDP-based counterpart tothe TCP-only
HTTP CONNECT method. While itwould be possible to reuse
HTTP CONNECT forUDP, existing implementations would fallback toTCP on the proxy-server leg of the connection,which should be avoided. However,
CONNECT-UDP will be supported on HTTP/1.1, 2, and 3, andtherefore provides a TCP fallback mechanism onthe client-proxy leg of the connection as detailedearlier. Using the
CONNECT-UDP header, the clientinstructs the proxy to open a UDP connectionto a provided URI. For HTTP/3, QUIC datagramframes are leveraged, providing a proxied unreliableconnection between client and server. This enablesconnections to multiple servers to be transportedwithin the same client-proxy HTTP/3 connection,which are multiplexed and de-multiplexed using
Datagram-Flow-Ids
While the chaining of multipleproxies is supported, a proxy receiving
CONNECT-UDP can either connect to the indicated target or toan upstream proxy. To use UDP on an end-to-endpath, all involved proxies have to support HTTP/3
WG Document Type Reference
MASQUE WG Charter Charter /wg/masque/about/Using QUIC Datagrams with HTTP/3 WG I-D draft-ietf-masque-h3-datagramThe CONNECT-UDP HTTP Method WG I-D draft-ietf-masque-connect-udpRequirements for a MASQUE Protocol to Proxy IP Traffic WG I-D draft-ietf-masque-ip-proxy-reqsThe CONNECT-IP method for proxying IP traffic Ind I-D draft-kuehlewind-masque-connect-ipQUIC-Aware Proxying Using CONNECT-UDP Ind I-D draft-pauly-masque-quic-proxyDiscovery Mechanisms for QUIC-based Proxy Services Ind I-D draft-kuehlewind-masque-proxy-discoveryTransport Considerations for IP and UDP Proxying Ind I-D draft-westerlund-masque-transport-issuesWebTransport WG Charter Charter /wg/webtrans/about/The WebTransport Protocol Framework WG I-D draft-ietf-webtrans-overviewWebTransport using HTTP/2 Ind I-D draft-kinnear-webtransport-http2WebTransport over HTTP/3 Ind I-D draft-vvv-webtransport-http3WebTransport over QUIC Ind I-D draft-vvv-webtransport-quicTABLE IIO
VERVIEW OF
MASQUE
AND W EB T RANSPORT
IETF D
OCUMENTS . T YPE
DIFFERENTIATES D OCUMENT TYPE : WG C
HARTERS AREDENOTED AS C HARTER , ADOPTED I NTERNET -D RAFTS AS
WG I-D , AND INDIVIDUAL DRAFTS AS I ND I-D . leveraging QUIC datagram frames. Following suc-cessful negotiation, all intermediaries will switch totunnel mode and restrict to forwarding packets untilthe connection is closed.Besides CONNECT-UDP , the requirements forgeneric
IP Proxying (see Table II) addressing tra-ditional VPN use-cases are actively discussed, andwere recently adopted as a WG Internet draft. Favor-ing HTTP/3 using QUIC datagram frames to preventnested reliability, a fallback to HTTP/2 is also sup-ported, leveraging both protocols multiplexing capa-bilities to run multiple IP proxied connections overthe same HTTP connection. For this purpose, anIPv4 or IPv6 session has to be established betweenthe end-points, including support for IP addressassignment requests, route negotiation, and clientand server identification as well as authentication.Where
IP Proxying lays out the requirements forproxying IP packets,
CONNECT-IP (see Table II)proposes a specific method to enable IP proxyingusing HTTP/3 connections, thus partially coveringthe outlaid requirements. A descriptive use-case of
IP Proxying is presented in §VI.To proxy arbitrary QUIC connections,
QUIC-Aware Proxying Using CONNECT-UDP (see TableII) addresses the specifics of tunneling QUIC overQUIC for long header packets, e.g., the encapsu-lation and encryption overhead of nested QUICconnections, as well as the forwarding of shortheader QUIC packets on established connections byleveraging connection IDs.Exceeding the presented efforts, supplementaltopics are discussed within the WG which arealso shown in Table II.
Discovery Mechanismsfor QUIC-based Proxy Services discusses mech- anisms to enable clients to be able to discovernon-transparent MASQUE proxies, while
Trans-port Considerations for IP and UDP Proxying inMASQUE addresses challenges to preserve end-to-end properties of the proxied flows.V. W EB T RANSPORT
The web security model shapes the Internet land-scape. While abstracting transport protocol featuresto application layer protocols and exposing them toweb developers, browser-based web applications be-came truly interactive and highly dynamic, radicallyreplacing static request-response based content.The TCP streams exposed by the WebSocketprotocol (RFC 6455) provide bidirectional ordereddelivery and suffer from HOL blocking as well asmandatory reliability, making it a poor fit for real-time communication or latency-sensitive applica-tions. This is improved by bootstrapping WebSocketonto HTTP/2 (RFC 8441), which multiplexes arbi-trary streams in a single HTTP/2 connection, henceeliminating HTTP HOL blocking, but still sufferingfrom TCP HOL blocking. Layering WebSocket ontoHTTP/3 would solve this issue. However, existingdisadvantages persist, requiring additional round-trips for the WebSocket protocol handshakes for ev-ery stream, limiting connection initiation to clientsonly, and lacking support for unreliable transport.WebRTC (RFC 7478) [4] data channels improveon this while leveraging SCTP (RFC 4960), provid-ing ordered and unordered delivery, partial reliabil-ity, and eliminating HOL blocking. As SCTP faceddeployment challenges (see §I), SCTP WebRTCdata channels use UDP as a substrate, a pattern alsoembraced by QUIC (see §II).
The IETF WebTransport WG (see Figure 1) wasformed to provide a mapping of HTTP and QUIC-based protocols to a web interface API developedby the World Wide Web Consortium (W3C) [14]honoring the web security model. The utilizedprotocols (referred to as transports ) mandate uni-and bi-directional streams, datagram support, andencryption. Moreover, optional properties are de-fined, which rely on features of specific proto-cols. These include stream independence to preventHOL blocking, partial reliability to prevent retrans-missions of datagrams, pooling support to share aunified congestion controller, connection migrationto keep connections alive if the path changes, andbandwidth prediction to aid use-cases like videostreaming or real-time gaming.While the core incentives of WebTransport havebeen discussed since 2018 as QUIC standardizationprogressed, the WG was chartered in March 2020,currently defining the requirements of WebTrans-port, and the requirements on the utilized transportsHttp2Transport , Http3Transport , as well as
Quic-Transport (see Table II). A descriptive example ofWebTransport is presented in §VI.
Http2Transport allows WebTransport peers tomultiplex arbitrary bidirectional streams overHTTP/2 connections, where either end-point caninitiate a new stream. While WebTransport and reg-ular HTTP data can be multiplexed simultaneously,intermediaries traversed must explicitly supportWebTransport. Additionally, TCP HOL blocking re-mains an issue, and the mandated support for unidi-rectional streams and unreliable delivery are notice-ably missing. While unidirectional streams can beforged by requiring bidirectional streams to only useone half of the connection, unreliability can not beprovided as TCP forcibly retransmits HTTP/2. Asdatagrams are not expected to be reliably delivered,but they might if the transport is using a TCP-based protocol, the specification also covers thisfallback case. Additionally,
Http2Transport doesfeature pooling support, which ensures that a sharedcongestion controller between multiple transports sharing the same HTTP connection can be used.
Http3Transport does support all requirementscovered by
Http2Transport , and extends on it byalso providing unidirectional streams, unreliabledelivery leveraging QUIC datagram frames withHTTP/3 (see §IV), as well as stream independencewhich eliminates HOL blocking.
QUICWebTransClientQUICWebTrans Internet
MASQUE
App. Servers
Browser
Fig. 2.
Remote office use-case: A client requests resources via QUICand WebTransport from Application Servers, which are multiplexedover a MASQUE tunnel proxying arbitrary IP packets.
Lastly,
QuicTransport offers a minimal protocolon top of QUIC, where WebTransport conceptsare directly mapped to the corresponding QUICcounterparts if applicable. The main design goal is alow overhead protocol, minimizing implementationeffort and complexity for extending existing QUICstacks with
QuicTransport capabilities.
QuicTrans-port satisfies all WebTransport design requirementsexcept pooling support.Besides the three presented proposals, a fourthoption of
FallbackTransport (no active document) isdiscussed within the WG. Aiming at a mapping toHTTP/1.1 and HTTP/2, multiplexed streams can besimulated on top of the WebSocket protocol, wherethe existing standardized WebSocket mappings tothe HTTP protocols are utilized as-is.While
QuicTransport offers a solution with lowoverhead, low complexity, and minimal implemen-tation effort,
Http3Transport offers pooling supportas well as HTTP features like status codes, headers,load balancing, and rerouting, possibly outweigh-ing the increased complexity and interdependency.Acknowledging these advantages, an adoption callwas recently issued for the
Http3Transport proposal,aiming to focus the WGs resources at WebTransportover HTTP/3 in the foreseeable future.VI. I
NTERPLAY
While all discussed protocols and extensionspropose vastly different approaches, their interplayextends on QUIC’s take to address transport layerossification challenges. We present two differentuse-cases highlighting their combined benefits. Fig-ure 2 showcases a remote office scenario. A clientrequests resources using plain QUIC as well asWebTransport via a browser. The client runs aVPN service leveraging a MASQUE tunnel to proxyarbitrary IP packets, connecting to a VPN gatewayat the main office that de-multiplexes the tunnel and
MPQUIC Client Internet MPQUIC Server
MASQUE QUIC QUIC
MASQUE ServerWiFi5G Website
Fig. 3.
Mobile use-case: A client is connected to a server usingmultipath QUIC (MPQUIC), where one QUIC connection is proxiedvia a MASQUE server. proxies the requests to their respective applicationservers. A mobile use-case is presented in Figure 3.A multipath QUIC client is connected to a multipathQUIC server using WiFi and 5G simultaneously,thus featuring multiple end-to-end paths. One con-nection is proxied using a MASQUE server, wherethe end-to-end QUIC connection is tunneled withinthe MASQUE QUIC connection. Benefitting fromboth the proxied MASQUE connection optimizedfor the access network as well as the multipathcapabilities, the client’s packet scheduler can dy-namically select the optimal path and seamlesslyre-route packets in case of path property changesor connection losses.VII. C
ONCLUSION
The transport layer is evolving. With QUIC atthe core of this renewal, its future versions willbuild on the foundation of QUIC v1 deployed on theInternet, thereby extending its reach to increasinglymore application areas. While multiple extensionsimprove on QUIC itself, MASQUE shows promiseto supersede traditional proxies and VPNs, andWebTransport will further enhance the rejuvenationof the Web, thus aiding the development of next-generation Web applications. While this article of-fered a first impression at the recent transport layerIETF standardization efforts beyond
QUIC v1 , thepresented protocols and extensions propose differentapproaches to address long-standing problems, andtheir interplay extends on QUIC’s take to addressossification challenges. Marking only the beginning,a new era of protocols is about to emerge.A CKNOWLEDGMENTS
We would like to thank Lars Eggert and MirjaKühlewind for their feedback and guidance, as wellas the editor and the reviewers for their valuableremarks. R
EFERENCES [1] G. Papastergiou et al. , “De-Ossifying the Internet TransportLayer: A Survey and Future Perspectives,”
IEEE Commu-nications Surveys Tutorials , vol. 19, no. 1, 2017. [Online].Available: https://doi.org/10.1109/COMST.2016.2626780[2] Y. Cui et al. , “Innovating Transport with QUIC: DesignApproaches and Research Challenges,”
IEEE InternetComputing , vol. 21, no. 2, 2017. [Online]. Available:https://doi.org/10.1109/MIC.2017.44[3] “The RACK-TLP loss detection algorithm for TCP,” (Dateaccessed: 03.01.2021) . [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/[4] C. Jennings et al. , “Real-time communications for the Web,”
IEEE Communications Magazine , vol. 51, no. 4, 2013. [Online].Available: https://doi.org/10.1109/MCOM.2013.6495756[5] M. Polese et al. , “A Survey on Recent Advances in TransportLayer Protocols,”
IEEE Communications Surveys Tutorials ,vol. 21, no. 4, pp. 3584–3608, 2019. [Online]. Available:https://doi.org/10.1109/COMST.2019.2932905[6] T. Zhang and S. Mao, “Machine Learning for End-to-End Congestion Control,”
IEEE Communications Magazine ,vol. 58, no. 6, 2020. [Online]. Available: https://doi.org/10.1109/MCOM.001.1900509[7] A. Langley et al. , “The QUIC Transport Protocol: Design andInternet-Scale Deployment,” in
SIGCOMM , 2017, pp. 183–196.[Online]. Available: https://doi.org/10.1145/3098822.3098842[8] Q. De Coninck and O. Bonaventure, “Multipath QUIC: Designand Evaluation,” in
CoNEXT , 2017, pp. 160–166. [Online].Available: https://doi.org/10.1145/3143361.3143370[9] J. R. Iyengar et al. , “Concurrent Multipath Transfer UsingSCTP Multihoming Over Independent End-to-End Paths,”
IEEE/ACM Transactions on Networking , vol. 14, no. 5, pp.951–964, 2006. [Online]. Available: https://doi.org/10.1109/TNET.2006.882843[10] M. Li et al. , “Multipath Transmission for the Internet: ASurvey,”
IEEE Communications Surveys Tutorials , vol. 18,no. 4, pp. 2887–2925, 2016. [Online]. Available: https://doi.org/10.1109/COMST.2016.2586112[11] J. Qadir et al. , “Resource Pooling for Wireless Networks:Solutions for the Developing World,”
SIGCOMM Comput.Commun. Rev. , vol. 46, no. 4, pp. 30–35, 2016. [Online].Available: https://doi.org/10.1145/3027947.3027953[12] V. Bajpai and J. Schönwälder, “A longitudinal view ofdual-stacked websites—failures, latency and happy eyeballs,”
IEEE/ACM Transactions on Networking , vol. 27, no. 2, pp.577–590, 2019. [Online]. Available: https://doi.org/10.1109/TNET.2019.2895165[13] Q. De Coninck et al. , “Pluginizing QUIC,” in
SIGCOMM ,2019, pp. 59–74. [Online]. Available: https://doi.org/10.1145/3341302.3342078[14] “PROPOSED WebTransport Working Group Charter,” (Dateaccessed: 03.01.2021) . [Online]. Available: https://w3c.github.io/webtransport-charter/charter.html
Mike Kosek is a PhD Student at TUM, Germany. His current researchfocuses on Internet architectures in general, and transport protocolstandardization, development, and deployment, in particular.
Tanya Shreedhar is a PhD student at IIIT-Delhi, India. Her researchinterests include next-generation networks and systems with a focuson transport layer protocols.