DOCSLIB.ORG

QUIC - Quick UDP Internet Connections

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
QUIC - Quick UDP Internet Connections QUIC - Quick UDP Internet Connections Florian Gratzer Betreuer: Sebastian Gallenmüller, Quirin Scheitle Seminar Innovative Internet-Technologien und Mobilkommunikation SS2016 Lehrstuhl Netzarchitekturen und Netzdienste Fakultät für Informatik, Technische Universität München Email: fl[email protected] ABSTRACT ences between TCP and QUIC connections are that QUIC QUIC is a transport protocol on top of UDP, developed by connections are always encrypted and connection establish- Google. It uses mechanisms of TCP and introduces new ment takes 0 RTTs when a server is known by a client and features not used by other transport protocols. QUIC is 1 RTT for the first connection to an unknown server. Figure optimized to be used for HTTP/2 connections and aims to 1 shows the connection establishment of QUIC compared to reduce the end-to-end latency. QUIC works best (compared the TCP three-way handshake [10]. to TCP) for slow connections with high latency. This pa- per addresses the problems of TCP and the mechanisms of QUIC are discussed. QUIC packet and frame types are ex- amined. The performance of HTTP over QUIC is compared to HTTP over TCP and HTTP + SPDY over TCP. The re- sults show that QUIC is not better than the other protocols in all scenarios, but it can outperform TCP under certain network conditions. Keywords QUIC, Quick UDP Internet Connections, TCP, UDP, Layer 4, Google, Transport Protocol, HTTP/2, congestion control Figure 1: Connection Establishment of TCP and 1. INTRODUCTION QUIC These days, the Internet is used for read the latest news or watching videos on platforms like YouTube. When the page TCP cannot be used to establish an encrypted connection load time is high, the user experience can become very bad. within 0 RTT. Consequently, a different protocol is used as Transport Layer protocol. Therefore UDP is used, because it In the last years, many approaches were considered to make is already supported by most devices. Google’s services like Internet surfing faster. Internet Service Providers (ISPs) try YouTube are already supporting QUIC , as well as Google’s to reduce page load times by increasing the bandwidth and Browser Chrome [6]. In 2016, QUIC is still in development, using faster networking devices. Developers of web browsers so it is likely that the protocol changes in the near future. tempt to make their software more efficient. Google’s recent For this reason, Internet drafts of the IETF are used as approach is to reduce the latency in the middle of the OSI sources instead of RFCs. These drafts can be updated or model, namely in Layer 4, called Transport Layer. replaced by other documents at any time [9, 14]. Today, TCP and UDP are the most used protocols in the This paper discusses the mechanisms of QUIC compared Transport Layer. While TCP is connection oriented, UDP is to TCP. Moreover, the QUIC packet and frame types are connectionless. Both protocols have advantages and disad- observed and the performance of QUIC is evaluated. vantages. TCP provides a reliable connection, but the TCP three-way handshake increases the latency for establishing 2. OVERVIEW OVER QUIC a connection. This can be problematic for short living con- QUIC is a transport protocol built upon UDP, designed to nections. In contrast, UDP establishes no connection, which be used mainly for HTTP/2 [10], but it can be used by results in a fast, but unreliable data transfer. To unite the every application layer protocol. It is developed by Google advantages of both protocols, Google is developing a new and aims to reduce the connection establishment latency transport protocol called QUIC - Quick UDP Internet [10]. In contrast to TCP and UDP, QUIC connections are Connections [8]. always encrypted and authenticated (see Section 5.7). The handshake is inspired by the handshake of TLS [5]. QUIC According to Google, QUIC performs better than TCP in can be compared to TCP + TLS + HTTP/2. According to scenarios with high Round Trip Time (RTT) and at least Google, QUIC has a better congestion control compared to as good as TCP in most other scenarios [4]. This claim TCP [10]. In Section 10, different scenarios are considered will be evaluated in Section 10. The most important differ- to evaluate this claim. Seminars FI / IITM SS 16, 39 doi: 10.2313/NET-2016-09-1_06 Network Architectures and Services, September 2016 3. PROBLEMS OF TCP mechanism triggers and the connection changes to/stays in Today, TCP is widely used. It is more reliable than UDP the Congestion Avoidance phase (more details in Section but nevertheless it has several problems, especially when us- 4.1) [16]. ing it for HTTP/1.1. When designing a protocol based on TCP, these problems have to be addressed. To establish 4.1 Fast Retransmit a TCP connection, the TCP three-way handshake is used. Fast Retransmit is a mechanism to avoid retransmission This handshake increases the connection establishment la- timeouts (RTOs). It triggers, when the sender receives three tency significantly. This is not problematic for long lasting duplicate acknowledgments (ACKs) (this threshold is used connections, but can decrease the user experience for web in TCP as well as in QUIC) [4, 16]. A duplicate ACK is surfing significantly. HTTP/1.1 uses a new TCP connection an acknowledgment for a segment, which has already been for each fetched URL [17]. acknowledged and indicates a packet loss. When a RTO occurs, the congestion window is set to one maximum seg- Another problem is that a TCP segment can only carry a ment size (MSS), while the Fast Retransmit mechanism sets single HTTP/1.1 Request/Response. Consequently it is pos- the congestion windows (and the Slow Start threshold) to a sible that a large number of small segments are sent within value dependent on the value it was before the loss. Also, an HTTP/1.1 session. This can lead to a large overhead. the connection stays in the Congestion Avoidance phase and does not start with a new Slow Start as it is done after a Also, HTTP/1.1 transfers are always initiated by the client RTO. According to evaluations by Google, over 99% of the [17]. This decreases the performance of HTTP/1.1 signifi- packet losses are recognized by duplicate ACKs and so the cantly when loading embedded files, because a server has to Fast Retransmit mechanism kicks in in most cases [10]. wait for a request from the client, even if the server knows that the client needs a specific resource [7]. 4.2 Tail Loss Probe (TLP) The last problem discussed in this Section is Head-of-line When a receiver does not receive the last segment of a trans- (HOL) blocking. It occurs, when a packet is lost and consec- mission, Fast Retransmit cannot be triggered, because the utive packets arrive at the destination. The receiving host receiver needs to receive (any) segments to identify the loss has then to wait for the retransmission of the lost packet and therefore to send duplicate ACKs. To overcome this until it can process consecutive packets, which arrived at problem, QUIC uses Tail Loss Probes (TLPs). Before a the host without a loss. In scenarios like video streaming, a RTO, the sender sends two TLPs containing the last unac- small number of lost packets do not have a notable influence knowledged segment [4]. The receiver then triggers the fast on the user experience. Nevertheless, a TCP receiver has to recovery mechanism [21]. wait for the lost packet before it is able to continue playing the video. 4.3 Forward RTO-Recovery (F-RTO) F-RTO aims to avoid unnecessary retransmissions to im- One way to overcome this problem with TCP is to open mul- prove the performance of TCP/QUIC. TCP and QUIC use tiple connection between the same endpoints. This can work two mechanisms to trigger retransmission. As described in satisfyingly for a small number of connections, but when too Section 4.1, Fast Retransmit kicks in, when the sender re- many connections are opened, the connections tend to oscil- ceives three duplicate ACKs. The second reason for retrans- late between very small and too large congestion windows missions are RTOs. After RTOs, a sender sets the congestion when losses occur. This leads to a bad throughput and a window to one MSS and continues with a new Slow Start bad user experience. phase. 4. TCP MECHANISMS IN QUIC It is possible that a RTO occurs, even without a packet loss Although QUIC uses UDP, many mechanisms are inspired [18]. There are several reasons for spurious retransmissions, by TCP. QUIC uses acknowledgments like TCP to inform including delay spikes in mobile networks and different pri- the sender, that segments arrived at the receiver. The con- orities of the sent data from the sender and the acknowl- gestion control and loss recovery of QUIC is a reimplemen- edgments of the receiver [18]. After reducing the congestion tation of TCP cubic with additional mechanisms [10]. TCP window caused by delayed (but not lost) ACKs, the delayed Cubic is optimized for high bandwidth networks with high ACKs reach the sender. As a result of the reduced conges- latency [2]. In this section, the most important mechanisms tion window, the ACKs are not inside the congestion window of TCP used in QUIC are discussed. More can be found in and trigger additional spurious retransmissions [18]. QUIC the according Internet draft [14]. The mechanisms not used avoids this problem by not reducing the congestion window in TCP are focused in Section 5. QUIC uses a retransmis- (and the Slow Start threshold) until the sender receives a sion timer.
Load more

Recommended publications
  • Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN Master in Communication Systems Date: November 22, 2020 Supervisor at KTH: Marco Chiesa Supervisor at Ericsson: Zaheduzzaman Sarker Examiner: Peter Sjödin School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Är QUIC ett bättre val än TCP i 5G Core Network Service Based Architecture? iii Abstract The development of the 5G Cellular Network required a new 5G Core Network and has put higher requirements on its protocol stack. For decades, TCP has been the transport protocol of choice on the Internet. In recent years, major Internet players such as Google, Facebook and CloudFlare have opted to use the new QUIC transport protocol. The design assumptions of the Internet (best-effort delivery) differs from those of the Core Network. The aim of this study is to investigate whether QUIC’s benefits on the Internet will translate to the 5G Core Network Service Based Architecture. A testbed was set up to emulate traffic patterns between Network Functions. The results show that QUIC reduces average request latency to half of that of TCP, for a majority of cases, and doubles the throughput even under optimal network conditions with no packet loss and low (20 ms) RTT. Additionally, by measuring request start and end times “on the wire”, without taking into account QUIC’s shorter connection establishment, we believe the results indicate QUIC’s suitability also under the long-lived (standing) connection model.
    [Show full text]
  • Analysis of QUIC Session Establishment and Its Implementations Eva Gagliardi, Olivier Levillain
    Analysis of QUIC session establishment and its implementations Eva Gagliardi, Olivier Levillain To cite this version: Eva Gagliardi, Olivier Levillain. Analysis of QUIC session establishment and its implementations. 13th IFIP International Conference on Information Security Theory and Practice (WISTP), Dec 2019, Paris, France. pp.169-184, 10.1007/978-3-030-41702-4_11. hal-02468596 HAL Id: hal-02468596 https://hal.archives-ouvertes.fr/hal-02468596 Submitted on 5 Feb 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Analysis of QUIC Session Establishment and its Implementations Eva Gagliardi1 and Olivier Levillain2 1 French Ministry of the Armies, 2 T´el´ecomSudParis, Institut Polytechnique de Paris Abstract. In the recent years, the major web companies have been working to improve the user experience and to secure the communica- tions between their users and the services they provide. QUIC is such an initiative, and it is currently being designed by the IETF. In a nutshell, QUIC originally intended to merge features from TCP/SCTP, TLS 1.3 and HTTP/2 into one big protocol. The current specification proposes a more modular definition, where each feature (transport, cryptography, application, packet reemission) are defined in separate internet drafts.
    [Show full text]
  • How Can We Protect the Internet Against Surveillance?
    How can we protect the Internet against surveillance? Seven TODO items for users, web developers and protocol engineers Peter Eckersley [email protected] Okay, so everyone is spying on the Internet It's not just the NSA... Lots of governments are in this game! Not to mention the commerical malware industry These guys are fearsome, octopus-like adversaries Does this mean we should just give up? No. Reason 1: some people can't afford to give up Reason 2: there is a line we can hold vs. So, how do we get there? TODO #1 Users should maximise their own security Make sure your OS and browser are patched! Use encryption where you can! In your browser, install HTTPS Everywhere https://eff.org/https-everywhere For instant messaging, use OTR (easiest with Pidgin or Adium, but be aware of the exploit risk tradeoff) For confidential browsing, use the Tor Browser Bundle Other tools to consider: TextSecure for SMS PGP for email (UX is terrible!) SpiderOak etc for cloud storage Lots of new things in the pipeline TODO #2 Run an open wireless network! openwireless.org How to do this securely right now? Chain your WPA2 network on a router below your open one. TODO #3 Site operators... Deploy SSL/TLS/HTTPS DEPLOY IT CORRECTLY! This, miserably, is a lot harder than it should be TLS/SSL Authentication Apparently, ~52 countries These are usually specialist, narrowly targetted attacks (but that's several entire other talks... we're working on making HTTPS more secure, easier and saner!) In the mean time, here's what you need A valid certificate HTTPS by default Secure cookies No “mixed content” Perfect Forward Secrecy A well-tuned configuration How do I make HTTPS the default? Firefox and Chrome: redirect, set the HSTS header Safari and IE: sorry, you can't (!!!) What's a secure cookie? Go and check your site right now..
    [Show full text]
  • Recent Progress on the QUIC Protocol
    Recent Progress on the QUIC Protocol Mehdi Yosofie, Benedikt Jaeger∗ ∗Chair of Network Architectures and Services, Department of Informatics Technical University of Munich, Germany Email: mehdi.yosofi[email protected], [email protected] Abstract—Internet services increase rapidly and much data Task Force (IETF) and is on standardization progress. The is sent back and forth inside it. The most widely used IETF is an Internet committee which deals with Internet network infrastructure is the HTTPS stack which has several technologies and publishes Internet standards. Currently, disadvantages. To reduce handshake latency in network QUIC is being standardized, and it remains to be seen, traffic, Google’s researchers built a new multi-layer transfer how it will influence the Internet traffic afterwards. protocol called Quick UDP Internet Connections (QUIC). It The rest of this paper is structured as follows: Sec- is implemented and tested on Google’s servers and clients tion 2 presents background information about the estab- and proves its suitability in everyday Internet traffic. QUIC’s lished TCP/TLS stack needed for the problem analysis. new paradigm integrates the security and transport layer Section 3 explicitly investigates some QUIC features like of the widely used HTTPS stack into one and violates the stream-multiplexing, security, loss recovery, congestion OSI model. QUIC takes advantages of existing protocols and control, flow control, QUIC’s handshake, its data format, integrates them in a new transport protocol providing less and the Multipath extension. They each rely on current latency, more data flow on wire, and better deployability. IETF standardization work, and are compared to the tra- QUIC removes head-of-line blocking and provides a plug- ditional TCP/TLS stack.
    [Show full text]
  • QUIC Record Layer
    A Security Model and Fully Verified Implementation for the IETF QUIC Record Layer Antoine Delignat-Lavaud∗, Cédric Fournet∗, Bryan Parnoy, Jonathan Protzenko∗, Tahina Ramananandro∗, Jay Bosamiyay, Joseph Lallemandz, Itsaka Rakotonirinaz, Yi Zhouy ∗Microsoft Research yCarnegie Mellon University zINRIA Nancy Grand-Est, LORIA Abstract—Drawing on earlier protocol-verification work, we investigate the security of the QUIC record layer, as standardized Application Application by the IETF in draft version 30. This version features major HTTP/2 HTTP/3 differences compared to Google’s original protocol and early IETF drafts. It serves as a useful test case for our verification TLS QUIC methodology and toolchain, while also, hopefully, drawing atten- tion to a little studied yet crucially important emerging standard. TCP UDP We model QUIC packet and header encryption, which uses IP IP a custom construction for privacy. To capture its goals, we propose a security definition for authenticated encryption with Fig. 1: Modularity of current networking stack vs. QUIC semi-implicit nonces. We show that QUIC uses an instance of a generic construction parameterized by a standard AEAD-secure scheme and a PRF-secure cipher. We formalize and verify the it is possible to combine both features in a single message, security of this construction in F?. The proof uncovers interesting saving a full network round-trip. limitations of nonce confidentiality, due to the malleability of short From a security standpoint, a fully-integrated secure trans- headers and the ability to choose the number of least significant port protocol offers the potential for a single, clean security bits included in the packet counter.
    [Show full text]
  • Quick UDP Internet Connections (QUIC)
    Quick UDP Internet Connections (QUIC) Simone Ferlin [email protected] draft-ietf-quic-transport-latest https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html A First Look at QUIC in the Wild, PAM 2018 https://arxiv.org/pdf/1801.05168.pdf Taking a Long Look at QUIC, ACM IMC 2017 https://mislove.org/publications/QUIC-IMC.pdf References for this Multipath QUIC, ACM CoNEXT 2017 presentation https://multipath-quic.org/conext17-deconinck.pdf The QUIC Transport Protocol: Design and Internet-Scale Deployment, ACM SIGCOMM 2017 • https://static.googleusercontent.com/media/research.google.co m/en//pubs/archive/46403.pdf • https://conferences.sigcomm.org/sigcomm/2017/files/program/t s-5-1-QUIC.pdf Why QUIC? • Improve performance and latency of web applications • Most web applications running with HTTP and TCP and TLS (HTTPS). • Keep the idea of flow and congestion control from TCP. • It provides at least a connection-oriented, reliable and in-order byte stream. • It enables stream multiplexing (similar to HTTP/2) to optimize for latency. • Improve security with end-to-end encryption by default and full encryption. • Still with TLS/SSL, but avoiding TLS’s handshake delay inflation. • Overcome slow adoption with code in user-space • No full system updates needed (code inside your browser). • The transport layer with only UDP and TCP is difficult to update. • Overcome slow updates and ubiquitous devices, i.e. middleboxes • TCP is often affected and it became incredibly difficult to propose extensions: Is it Still Possible to Extend TCP?, M. Honda et al., ACM IMC 2011. Where is QUIC? User-space Kernel-space Where is QUIC? User-space Kernel-space Some QUICk remarks • QUIC’s first implementation appeared around 2012 in Chromium • Standardisation group established in 2016 • QUIC-WG: https://datatracker.ietf.org/wg/quic).
    [Show full text]
  • Congestion Control Tuning of the QUIC Transport Layer Protocol Spring 2018
    Congestion Control Tuning of the QUIC Transport Layer Protocol Spring 2018 Wendi Qu Director: Llorenç Cerdà-Alabern Departament d'Arquitectura de Computadors Degree: Bachelor Specialization: Information Technologies Facultat d’Informatica de Barcelona (FIB) Universitat Politecnica de Catalunya (UPC) - BarcelonaTech April 2018 UNIVERSITAT POLITÈCNICA DE CATALUNYA (UPC) Abstract The QUIC protocol is a new type of reliable transmission protocol based on UDP. Its establishment is mainly to solve the problem of network delay. It is efficient, fast, and takes up less resources. The QUIC gathers the advantages of both TCP and UDP. The first part of this thesis studies the development background of the QUIC protocol in terms of characteristics and perspectives of what they can do and how they work. Because it adds the congestion control algorithm used by TCP based on the UDP protocol, we have conducted further research and analysis of the Cubic algorithm to investigate the impact of its parameters on the behavior. The second part includes performance and fairness tests for QUIC and TCP implementations. The simulation framework Mininet is used to perform these tests using controlled network properties. In this process we verified the reliability of the mininet. This work shows how Mininet builds a test system to analyze the implementation of the transport protocol. QUIC's tests show that the performance of QUIC has improved, and the test of fairness have identified specific areas that may require further analysis. In the third part, we test the influence of the parameter on the behavior of the algorithm in the congestion control algorithm. We present an initial experimental evaluation of the newly proposed Cubic-TCP algorithm.
    [Show full text]
  • MR-471.2: Maximum IP-Layer Capacity Metric and Measurement
    MARKETING REPORT MR-471.2 Maximum IP-Layer Capacity Metric and Measurement Issue: 1 Issue Date: October 2020 October 2020 © The Broadband Forum. All rights reserved 1 of 14 Maximum IP-Layer Capacity Metric and Measurement MR-471.2 Issue History Issue Number Issue Date Issue Changes Editor 1 22 October Al Morton, AT&T Original 2020 Comments or questions about this Broadband Forum Marketing Report should be directed to [email protected]. Editor Al Morton, AT&T Work Area Director(s) David Sinicrope, Ericsson PEAT PS Leader Gregory Mirsky (ZTE) Contributors Len Ciavattone, AT&T Ken Kerpez, ASSIA October 2020 © The Broadband Forum. All rights reserved 2 of 14 Maximum IP-Layer Capacity Metric and Measurement MR-471.2 Table of Contents Executive Summary.................................................................................................................................. 4 1 Background ....................................................................................................................................... 5 2 Terminology ....................................................................................................................................... 6 2.1 References ................................................................................................................................... 6 2.2 Abbreviations ................................................................................................................................ 7 3 Access Networks and Services Outrun TCP Speed Tests ..............................................................
    [Show full text]
  • User Tracking Via Google's QUIC Protocol
    11th October 2018 PET-CON 2018.2 User Tracking via Google’s QUIC Protocol Erik Sy, M.Sc. 1 Introduction to the QUIC Transport Protocol § QUIC over UDP provides an alternative HTTPS stack to TLS over TCP – Allows for zero round-trip time secure connection establishment § Deployment on the Internet – accounts for 7% of global Internet traffic – more than five million hosts in IPv4 currently support QUIC – supported by Google Chrome (approx. 60% browser market share) – other use cases include DNS over QUIC, FTP over QUIC, SMTP over QUIC 2 QUIC’s Connection Establishment § QUIC reuses cached server config and token across several user sessions Client Server Client Server Inchoate CHLO (…) CHLO (SCID_1, Token_2, KeyShare_3, …) REJ (PUBS, CRT, SCID_1, Token_1, …) Encrypted Request (…) CHLO (SCID_1, Token_1, KeyShare_1, …) Encrypted Request (…) SHLO (Token_3, KeyShare_4, …) Encrypted Response (…) SHLO (Token_2, KeyShare_2, …) Encrypted Response (…) a) Initial Handshake b) Subsequent Handshake 3 Opportunities and Limitations of Tracking via QUIC § Independent of common tracking approaches like IP addresses, HTTP cookies and browser fingerprinting § Opportunities compared to browser fingerprinting – Faster unique identification of a user – Lower consumption of bandwidth and computational resources § Limitations – Browser restarts terminate a tracking period – QUIC configuration of a browser • Lifetime of Token and server configs • Feasibility of third-party tracking 4 Experiments to test Browsers’ default QUIC Configuration § Measurement of QUIC’s Token lifetime within popular browsers – Maximum delay between two website visits for whiCh the browser still attempts to establish the new ConneCtion with an CaChed Token § Investigating the feasibility of third-party traCking via QUIC User Loading Website A Loading Website B Website A Third-party T Website B (incl.
    [Show full text]
  • 2019-02-03 FOSDEM Low Bandwidth
    Breaking the 100 bits per second barrier with Matrix An entirely new transport for Matrix for really terrible networks. [email protected] @matrixdotorg 1 Matrix is an open network for secure, decentralised real-time communication. Interoperable chat Interoperable VoIP Open comms for VR/AR Real-time IoT data fabric 2 Mission: to create a global decentralised encrypted comms network that provides an open platform for real-time communication. Discord Telegram Slack IRC Gitter XMPP 4 Discord Telegram Slack IRC Gitter XMPP 5 No single party owns your conversations. Conversations are shared over all participants. 6 Matrix Architecture Clients Home Servers Application Servers Identity Servers Matrix Ecosystem Matrix Matrix Other Clients: Web iOS Console Console “Riot X” gomuks Quaternion (CLI/go) (Qt/C++) matrix- client matrix- matrix- sdk- react- angular- MatrixKit (iOS) Seaglass - android- side sdk sdk matrix- Fractal (macOS) android- rx (Gtk+/Rust) sdk matrix- (Java) weechat- sdk- nheko-reborn matrix-js-sdk matrix-ios-sdk matrix android (Kotlin) …and many many more The Matrix Specification (Client/Server API) server Synapse Dendrite Matrix Application Other Servers: Other Services: st nd - (1 gen Matrix (2 gen Services and Ruma (Rust), side Bridges, Bots, Integs… Server) Server) Bridges jeon (Java)… Low Bandwidth Matrix • Our target: 100bps. • It takes 2 minutes to send an Ethernet packet (1500 MTU) at 100bps. • Why would you do this? • Connectivity can get pretty bad in life or death situations. • If you are in appalling connectivity (e.g. the bottom of a crevasse) you want every bit to count. HTTP/1.1+TLS • Matrix is intended to be transport agnostic • We started with HTTPS+JSON for convenience • Any web developer can trivially send a message: curl 'https://matrix.org/_matrix/client/r0/rooms/!foo:matrix.org/send/m.room.message/1’ -X PUT --data '{"msgtype":"m.text","body":"test"}' • Typical HTTP/1.1+TLS/1.2 request to send “test” • 7,004 bytes (including Eth headers) • 8 round trips.
    [Show full text]
  • Protocols: W, X, Y, Z
    Protocols: W, X, Y, Z • WAP-PUSH, page 5 • WAP-PUSH-HTTP, page 7 • WAP-PUSH-HTTPS, page 8 • WAP-PUSHSECURE, page 9 • WAP-VCAL, page 10 • WAP-VCAL-S, page 11 • WAP-VCARD, page 12 • WAP-VCARD-S, page 13 • WAP-WSP, page 14 • WAP-WSP-S, page 16 • WAP-WSP-WTP, page 17 • WAP-WSP-WTP-S, page 18 • WALL-STREET-JOURNAL, page 19 • WAR-ROCK, page 20 • WARRIORFORUM, page 22 • WASTE, page 23 • WASHINGTON POST, page 24 • WB-EXPAK, page 25 • WB-MON, page 26 • WCCP, page 27 • WEATHER-COM, page 29 • WEATHER-GOV-WEB-PORTAL, page 30 • WEB-ANALYTICS, page 31 • WEBEX-APP-SHARING, page 32 Protocol Pack 32.0.0 1 Protocols: W, X, Y, Z • WEBEX-MEDIA, page 33 • WEBEX-MEETING, page 34 • WEBMD, page 36 • WEB-RTC, page 37 • WEB-RTC-AUDIO, page 38 • WEB-RTC-VIDEO, page 39 • WEBSENSE, page 40 • WEBSTER, page 41 • WEBTHUNDER, page 42 • WECHAT, page 43 • WEIBO, page 44 • WELLS-FARGO, page 45 • WETRANSFER, page 46 • WHATSAPP, page 47 • WHITEPAGES, page 48 • WHOAMI, page 49 • WHOIS++, page 50 • WIFI-CALLING, page 52 • WIKIA, page 53 • WIKIPEDIA, page 54 • WINDOWS-AZURE, page 55 • WINDOWS-STORE, page 57 • WINDOWS-UPDATE, page 58 • WINMX, page 60 • WINNY, page 61 • WIRED-COM, page 62 • WLCCP, page 63 • WORDREFERENCE-COM, page 64 • WORLDFUSION, page 65 • WORLDSTARHIPHOP, page 66 • WPGS, page 67 • WSN, page 68 • WUNDERGROUND-COM, page 69 Protocol Pack 32.0.0 2 Protocols: W, X, Y, Z • XACT-BACKUP, page 70 • X-BONE-CTL, page 71 • XBOX-WEB-PORTAL, page 73 • XDA-DEVELOPERS, page 74 • XDMCP, page 75 • XDTP, page 76 • XFER, page 78 • XFIRE, page 79 • XINHUANET, page 80 • XMPP-CLIENT,
    [Show full text]
  • The QUIC Transport Protocol:Design and Internet-Scale Deployment
    The QUIC Transport Protocol: Design and Internet-Scale Deployment Adam Langley, Alistair Riddoch, Alyssa Wilk, Antonio Vicente, Charles Krasic, Dan Zhang, Fan Yang, Fedor Kouranov, Ian Swett, Janardhan Iyengar, Jeff Bailey, Jeremy Dorfman, Jim Roskind, Joanna Kulik, Patrik Westin, Raman Tenneti, Robbie Shade, Ryan Hamilton, Victor Vasiliev, Wan-Teh Chang, Zhongyi Shi * Google [email protected] ABSTRACT We present our experience with QUIC, an encrypted, multiplexed, and low-latency transport protocol designed from the ground up to improve transport performance for HTTPS traffic and to enable rapid deployment and continued evolution of transport mechanisms. QUIC has been globally deployed at Google on thousands of servers and is used to serve traffic to a range of clients including a widely-used web browser (Chrome) and a popular mobile video streaming app (YouTube). We estimate that 7% of Internet traffic is now QUIC. We describe our motivations for developing a new transport, the princi- ples that guided our design, the Internet-scale process that we used Figure 1: QUIC in the traditional HTTPS stack. to perform iterative experiments on QUIC, performance improve- ments seen by our various services, and our experience deploying TCP (Figure 1). We developed QUIC as a user-space transport with QUIC globally. We also share lessons about transport design and the UDP as a substrate. Building QUIC in user-space facilitated its Internet ecosystem that we learned from our deployment. deployment as part of various applications and enabled iterative changes to occur at application update timescales. The use of UDP CCS CONCEPTS allows QUIC packets to traverse middleboxes.
    [Show full text]