Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?

Total Page:16

File Type:pdf, Size:1020Kb

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. In conclusion, from a performance perspective, QUIC appears to be a better candidate than TCP in the 5G Core Network Service Based Architecture. iv Sammanfattning Den snabba utvecklingen av det mobila nätverket 5G har medfört högre krav för 5G Core Network och dess protokoll. Under årtionden har TCP dominerat Internet som transportprotokoll. De senaste åren har dock stora aktörer som Google, Facebook och CloudFlare börjat använda det relativt nya transport- protokollet QUIC. Designantagandena för Internet (best-effort delivery) och 5G Core skiljer sig dock åt. Målet med denna studie är att undersöka huruvida QUIC är lika fördelaktigt att använda i 5G Core Network Service Based Ar- chitecture som på Internet. En testbädd sattes up för att emulera trafiken mel- lan två nätverksfunktioner. Resultaten visar att QUIC har halverar latensen jämfört med TCP i en majoritet av fallen, samt dubblerar genomströmning- en även under mycket goda nätverksförhållanden där inga paket förloras och tur-och-retur-tiden är låg (20 ms). Genom att mäta ett HTTP requests start- och sluttider “rakt på ledningen”, utan att inbegripa QUICs kortare förbin- delseetableringstid, menar vi att resultaten indikerar QUICs lämplighet också vid användande av långlivade kommunikationsförbindelser. Med avseende på prestanda, framstår QUIC som ett bättre alternativ än TCP också i 5G Core Network Service Based Architecture. v Acknowledgements I would like to express my gratitude to several experts at Ericsson for the op- portunity to work on this interesting topic and for the enriching discussions that emerged. I would like to thank my industrial supervisor, Zaheduzzaman Sarker, for his knowledgeable guidance, help, and feedback during this project. I would like to thank Patrick Sellstedt, for providing me the platform at Eric- sson for this work. I would also like to thank Magnus Westerlund and Mirja Kühlewind for additional very valuable feedback and insights. I am also grateful to my KTH supervisor, Marco Chiesa, for his valuable feedback and insights, and to my examiner, Peter Sjödin, for reviewing and approving the initial thesis proposal and providing helpful academic feedback on the report. I would also like to thank my parents for always being supportive, my father for the encouragement and support during all my studies, and my mother for believing in a positive outcome of this work. Finally, I want to thank my wife for enabling me to spend time, sometimes on nights and weekends, to track down bugs and finalize the report. Without your support, I would not be able to have both a Master Thesis and a beautiful family as well. Contents 1 Introduction 1 1.1 Overview . .1 1.2 QUIC vs. TCP . .2 1.3 Problem Area . .3 1.4 Goals . .4 1.5 Methodology . .4 1.6 Delimitations . .5 1.7 Ethics and Sustainability . .5 1.8 Outline . .5 2 Background 7 2.1 Mobile Systems Architecture . .7 2.1.1 Common Logical Building Blocks . .7 2.1.2 5G Core Service Based Architecture . .8 2.2 Protocols . .9 2.2.1 Introduction . .9 2.2.2 TCP/TLS . 11 2.2.3 HTTP/1.1 and HTTP/2 . 12 2.2.4 QUIC and HTTP/3 . 13 2.3 QUIC on the Web vs. the 5G Core . 15 2.4 Related Work . 16 2.4.1 QUIC in the 5G Core Service Based Architecture . 16 2.4.2 QUIC on the Web . 17 3 Method 19 3.1 Testbed Requirements . 19 3.1.1 Overview . 19 3.1.2 Requirements to Ensure Comparability . 20 3.2 Testbed Components . 24 vi CONTENTS vii 3.2.1 Platform & Network Tools . 24 3.2.2 QUIC/TCP Client & Server Implementations . 25 3.3 Benchmark Parameter Settings . 26 3.3.1 Main Parameters . 26 3.3.2 Sub-parameters . 27 3.4 Key Performance Indicators . 27 3.5 Test Design . 28 4 Results 30 4.1 Sub-parameters . 30 4.1.1 Number of Multiplexed Requests . 31 4.1.2 Request Payload . 35 4.1.3 Response Payload . 39 4.2 Main Parameters . 46 4.2.1 Round Trip Time . 46 4.2.2 Packet Loss Rate . 47 5 Discussion 50 5.1 Faster Connection Establishment – Not the Only Factor for Improving Latency . 50 5.2 QUIC has a Significant Advantage Also in QoS Networks . 52 5.3 Performance Difference is Negligible With Few Multiplexed GET Requests . 52 5.4 Impacts of the Method used to Measure Request Duration . 53 5.5 Limitations & Future Work . 53 5.6 Conclusions . 54 Bibliography 56 Chapter 1 Introduction A short background overview of the research is presented followed by a brief comparison of QUIC and TCP. We then lay out the problem area, research question and hypotheses followed by the goals, methodology and a brief dis- cussion of ethical concerns and impacts on sustainability. Chapter 2 contains a more thorough background presentation. 1.1 Overview Mobile telecommunication systems evolve continuously in order to meet new and increasing demands such as massive IoT deployment, time-sensitive re- mote control of robots over a network and increased throughput. Between 2010 and 2020, there was an expected capacity increase of a 1000 times more devices, 100 times higher data rate and 10 times lower latency. The fifth gener- ation (5G) mobile telecommunication system has been designed to meet these demands. [1] 3G, 4G and 5G architectures all have in common that they consist of two networks: the Radio Access Network and the Core Network. The role of the Radio Access Network is to provide a connection between the User Equipment – a cell phone or other device – and the Core Network. The Core Network is responsible for handling everything related to connection management and the forwarding of data to and from the Internet. It is logically divided in two parts, the Control Plane and the User Plane. The User Plane only handles the forwarding of data and the Control Plane handles all other functionality such as authentication, authorization, policy control and so forth. [2] In order to modularize network components and make them independently scalable and evolvable, the new Service Based Architecture (SBA) was in- 1 2 CHAPTER 1. INTRODUCTION troduced with 5G for the Control Plane of the Core Network [3]. SBA is a microservices-type architecture where the goals are to provide easier scaling and more rapid development [4, p. 12]. According to the "System architecture for the 5G System" specification [3], Network Functions (NFs) communicate over Representational State Transfer (REST) interfaces via request-response and subscribe-notify communication patterns. The authors argue that by iso- lating NFs and using generic protocols such as HTTP for communication, scal- ing and evolvability of individual components become easier; thereby, SBA also paves the way for eventual transitioning into a cloud-based environment where NFs run in containers in data centers. The choice of protocols impacts all types of communication. With the introduction of REST interfaces in SBA, the protocol stack of the higher layers – layer 3 to layer 5 – becomes very similar to the protocol stack used on the Web [4, p. 22]. Therefore, any new protocol development in the Web stack could also be of use in the SBA protocol stack. In this thesis, we are interested in evaluating the transport protocol performance within the context of the 5G Core Network Control Plane SBA. 1.2 QUIC vs. TCP The Transmission Control Protocol (TCP) has been the transport protocol of choice on the Internet for decades and provides reliability as well as congestion control [5]. In conjunction with the Transport Layer Security (TLS) protocol, authentication and encryption are also ensured [6]. However, in 2012 Google laid out the guidelines for a new transport protocol called QUIC [7]. The protocol was submitted to the Internet Engineering Task Force (IETF) which has since continued the development [8] and made substantial changes to the protocol. It is the IETF draft of QUIC [9] that this thesis is concerned with. To understand why companies such as Google, CloudFlare and others opt for QUIC whenever possible [10, 11], we need to understand the design goals of QUIC and in what regards QUIC performs better than TCP.
Recommended publications
  • DE-CIX Academy Handout
    Networking Basics 04 - User Datagram Protocol (UDP) Wolfgang Tremmel [email protected] DE-CIX Management GmbH | Lindleystr. 12 | 60314 Frankfurt | Germany Phone + 49 69 1730 902 0 | [email protected] | www.de-cix.net Networking Basics DE-CIX Academy 01 - Networks, Packets, and Protocols 02 - Ethernet 02a - VLANs 03 - the Internet Protocol (IP) 03a - IP Addresses, Prefixes, and Routing 03b - Global IP routing 04 - User Datagram Protocol (UDP) 05 - TCP ... Layer Name Internet Model 5 Application IP / Internet Layer 4 Transport • Data units are called "Packets" 3 Internet 2 Link Provides source to destination transport • 1 Physical • For this we need addresses • Examples: • IPv4 • IPv6 Layer Name Internet Model 5 Application Transport Layer 4 Transport 3 Internet 2 Link 1 Physical Layer Name Internet Model 5 Application Transport Layer 4 Transport • May provide flow control, reliability, congestion 3 Internet avoidance 2 Link 1 Physical Layer Name Internet Model 5 Application Transport Layer 4 Transport • May provide flow control, reliability, congestion 3 Internet avoidance 2 Link • Examples: 1 Physical • TCP (flow control, reliability, congestion avoidance) • UDP (none of the above) Layer Name Internet Model 5 Application Transport Layer 4 Transport • May provide flow control, reliability, congestion 3 Internet avoidance 2 Link • Examples: 1 Physical • TCP (flow control, reliability, congestion avoidance) • UDP (none of the above) • Also may contain information about the next layer up Encapsulation Packets inside packets • Encapsulation is like Russian dolls Attribution: Fanghong. derivative work: Greyhood https://commons.wikimedia.org/wiki/File:Matryoshka_transparent.png Encapsulation Packets inside packets • Encapsulation is like Russian dolls • IP Packets have a payload Attribution: Fanghong.
    [Show full text]
  • The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D
    The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D. AMER University of Delaware AND PHILLIP T. CONRAD Temple University Transport layer protocols provide for end-to-end communication between two or more hosts. This paper presents a tutorial on transport layer concepts and terminology, and a survey of transport layer services and protocols. The transport layer protocol TCP is used as a reference point, and compared and contrasted with nineteen other protocols designed over the past two decades. The service and protocol features of twelve of the most important protocols are summarized in both text and tables. Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: General—Data communications; Open System Interconnection Reference Model (OSI); C.2.1 [Computer-Communication Networks]: Network Architecture and Design—Network communications; Packet-switching networks; Store and forward networks; C.2.2 [Computer-Communication Networks]: Network Protocols; Protocol architecture (OSI model); C.2.5 [Computer- Communication Networks]: Local and Wide-Area Networks General Terms: Networks Additional Key Words and Phrases: Congestion control, flow control, transport protocol, transport service, TCP/IP 1. INTRODUCTION work of routers, bridges, and communi- cation links that moves information be- In the OSI 7-layer Reference Model, the tween hosts. A good transport layer transport layer is the lowest layer that service (or simply, transport service) al- operates on an end-to-end basis be- lows applications to use a standard set tween two or more communicating of primitives and run on a variety of hosts. This layer lies at the boundary networks without worrying about differ- between these hosts and an internet- ent network interfaces and reliabilities.
    [Show full text]
  • Solutions to Chapter 2
    CS413 Computer Networks ASN 4 Solutions Solutions to Assignment #4 3. What difference does it make to the network layer if the underlying data link layer provides a connection-oriented service versus a connectionless service? [4 marks] Solution: If the data link layer provides a connection-oriented service to the network layer, then the network layer must precede all transfer of information with a connection setup procedure (2). If the connection-oriented service includes assurances that frames of information are transferred correctly and in sequence by the data link layer, the network layer can then assume that the packets it sends to its neighbor traverse an error-free pipe. On the other hand, if the data link layer is connectionless, then each frame is sent independently through the data link, probably in unconfirmed manner (without acknowledgments or retransmissions). In this case the network layer cannot make assumptions about the sequencing or correctness of the packets it exchanges with its neighbors (2). The Ethernet local area network provides an example of connectionless transfer of data link frames. The transfer of frames using "Type 2" service in Logical Link Control (discussed in Chapter 6) provides a connection-oriented data link control example. 4. Suppose transmission channels become virtually error-free. Is the data link layer still needed? [2 marks – 1 for the answer and 1 for explanation] Solution: The data link layer is still needed(1) for framing the data and for flow control over the transmission channel. In a multiple access medium such as a LAN, the data link layer is required to coordinate access to the shared medium among the multiple users (1).
    [Show full text]
  • User Datagram Protocol - Wikipedia, the Free Encyclopedia Página 1 De 6
    User Datagram Protocol - Wikipedia, the free encyclopedia Página 1 de 6 User Datagram Protocol From Wikipedia, the free encyclopedia The five-layer TCP/IP model User Datagram Protocol (UDP) is one of the core 5. Application layer protocols of the Internet protocol suite. Using UDP, programs on networked computers can send short DHCP · DNS · FTP · Gopher · HTTP · messages sometimes known as datagrams (using IMAP4 · IRC · NNTP · XMPP · POP3 · Datagram Sockets) to one another. UDP is sometimes SIP · SMTP · SNMP · SSH · TELNET · called the Universal Datagram Protocol. RPC · RTCP · RTSP · TLS · SDP · UDP does not guarantee reliability or ordering in the SOAP · GTP · STUN · NTP · (more) way that TCP does. Datagrams may arrive out of order, 4. Transport layer appear duplicated, or go missing without notice. TCP · UDP · DCCP · SCTP · RTP · Avoiding the overhead of checking whether every RSVP · IGMP · (more) packet actually arrived makes UDP faster and more 3. Network/Internet layer efficient, at least for applications that do not need IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · guaranteed delivery. Time-sensitive applications often IPsec · ARP · RARP · RIP · ICMP · use UDP because dropped packets are preferable to ICMPv6 · (more) delayed packets. UDP's stateless nature is also useful 2. Data link layer for servers that answer small queries from huge 802.11 · 802.16 · Wi-Fi · WiMAX · numbers of clients. Unlike TCP, UDP supports packet ATM · DTM · Token ring · Ethernet · broadcast (sending to all on local network) and FDDI · Frame Relay · GPRS · EVDO · multicasting (send to all subscribers). HSPA · HDLC · PPP · PPTP · L2TP · ISDN · (more) Common network applications that use UDP include 1.
    [Show full text]
  • RFC 5405 Unicast UDP Usage Guidelines November 2008
    Network Working Group L. Eggert Request for Comments: 5405 Nokia BCP: 145 G. Fairhurst Category: Best Current Practice University of Aberdeen November 2008 Unicast UDP Usage Guidelines for Application Designers Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. Eggert & Fairhurst Best Current Practice [Page 1] RFC 5405 Unicast UDP Usage Guidelines November 2008 Table of Contents 1. Introduction . 3 2. Terminology . 5 3. UDP Usage Guidelines .
    [Show full text]
  • Internet Protocol Suite
    InternetInternet ProtocolProtocol SuiteSuite Srinidhi Varadarajan InternetInternet ProtocolProtocol Suite:Suite: TransportTransport • TCP: Transmission Control Protocol • Byte stream transfer • Reliable, connection-oriented service • Point-to-point (one-to-one) service only • UDP: User Datagram Protocol • Unreliable (“best effort”) datagram service • Point-to-point, multicast (one-to-many), and • broadcast (one-to-all) InternetInternet ProtocolProtocol Suite:Suite: NetworkNetwork z IP: Internet Protocol – Unreliable service – Performs routing – Supported by routing protocols, • e.g. RIP, IS-IS, • OSPF, IGP, and BGP z ICMP: Internet Control Message Protocol – Used by IP (primarily) to exchange error and control messages with other nodes z IGMP: Internet Group Management Protocol – Used for controlling multicast (one-to-many transmission) for UDP datagrams InternetInternet ProtocolProtocol Suite:Suite: DataData LinkLink z ARP: Address Resolution Protocol – Translates from an IP (network) address to a network interface (hardware) address, e.g. IP address-to-Ethernet address or IP address-to- FDDI address z RARP: Reverse Address Resolution Protocol – Translates from a network interface (hardware) address to an IP (network) address AddressAddress ResolutionResolution ProtocolProtocol (ARP)(ARP) ARP Query What is the Ethernet Address of 130.245.20.2 Ethernet ARP Response IP Source 0A:03:23:65:09:FB IP Destination IP: 130.245.20.1 IP: 130.245.20.2 Ethernet: 0A:03:21:60:09:FA Ethernet: 0A:03:23:65:09:FB z Maps IP addresses to Ethernet Addresses
    [Show full text]
  • Medium Access Control Layer
    Telematics Chapter 5: Medium Access Control Sublayer User Server watching with video Beispielbildvideo clip clips Application Layer Application Layer Presentation Layer Presentation Layer Session Layer Session Layer Transport Layer Transport Layer Network Layer Network Layer Network Layer Univ.-Prof. Dr.-Ing. Jochen H. Schiller Data Link Layer Data Link Layer Data Link Layer Computer Systems and Telematics (CST) Physical Layer Physical Layer Physical Layer Institute of Computer Science Freie Universität Berlin http://cst.mi.fu-berlin.de Contents ● Design Issues ● Metropolitan Area Networks ● Network Topologies (MAN) ● The Channel Allocation Problem ● Wide Area Networks (WAN) ● Multiple Access Protocols ● Frame Relay (historical) ● Ethernet ● ATM ● IEEE 802.2 – Logical Link Control ● SDH ● Token Bus (historical) ● Network Infrastructure ● Token Ring (historical) ● Virtual LANs ● Fiber Distributed Data Interface ● Structured Cabling Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.2 Design Issues Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.3 Design Issues ● Two kinds of connections in networks ● Point-to-point connections OSI Reference Model ● Broadcast (Multi-access channel, Application Layer Random access channel) Presentation Layer ● In a network with broadcast Session Layer connections ● Who gets the channel? Transport Layer Network Layer ● Protocols used to determine who gets next access to the channel Data Link Layer ● Medium Access Control (MAC) sublayer Physical Layer Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.4 Network Types for the Local Range ● LLC layer: uniform interface and same frame format to upper layers ● MAC layer: defines medium access ..
    [Show full text]
  • The Internet Protocol, Version 4 (Ipv4)
    Today’s Lecture I. IPv4 Overview The Internet Protocol, II. IP Fragmentation and Reassembly Version 4 (IPv4) III. IP and Routing IV. IPv4 Options Internet Protocols CSC / ECE 573 Fall, 2005 N.C. State University copyright 2005 Douglas S. Reeves 1 copyright 2005 Douglas S. Reeves 2 Internet Protocol v4 (RFC791) Functions • A universal intermediate layer • Routing IPv4 Overview • Fragmentation and reassembly copyright 2005 Douglas S. Reeves 3 copyright 2005 Douglas S. Reeves 4 “IP over Everything, Everything Over IP” IP = Basic Delivery Service • Everything over IP • IP over everything • Connectionless delivery simplifies router design – TCP, UDP – Dialup and operation – Appletalk – ISDN – Netbios • Unreliable, best-effort delivery. Packets may be… – SCSI – X.25 – ATM – Ethernet – lost (discarded) – X.25 – Wi-Fi – duplicated – SNA – FDDI – reordered – Sonet – ATM – Fibre Channel – Sonet – and/or corrupted – Frame Relay… – … – Remote Direct Memory Access – Ethernet • Even IP over IP! copyright 2005 Douglas S. Reeves 5 copyright 2005 Douglas S. Reeves 6 1 IPv4 Datagram Format IPv4 Header Contents 0 4 8 16 31 •Version (4 bits) header type of service • Functions version total length (in bytes) length (x4) prec | D T R C 0 •Header Length x4 (4) flags identification fragment offset (x8) 1. universal 0 DF MF s •Type of Service (8) e time-to-live (next) protocol t intermediate layer header checksum y b (hop count) identifier •Total Length (16) 0 2 2. routing source IP address •Identification (16) 3. fragmentation and destination IP address reassembly •Flags (3) s •Fragment Offset ×8 (13) e t 4. Options y IP options (if any) b •Time-to-Live (8) 0 4 ≤ •Protocol Identifier (8) s e t •Header Checksum (16) y b payload 5 •Source IP Address (32) 1 5 5 6 •Destination IP Address (32) ≤ •IP Options (≤ 320) copyright 2005 Douglas S.
    [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]
  • 61A Lecture 35 Distributed Computing Internet Protocol Transmission
    Announcements • Homework 9 (6 pts) due Wednesday 11/26 @ 11:59pm ! Homework Party Monday 6pm-8pm in 2050 VLSB • Guest in live lecture, TA Soumya Basu, on Monday 11/24 • Optional Scheme recursive art contest due Monday 12/1 @ 11:59pm 61A Lecture 35 • No lecture on Wednesday 11/26 (turkey) • No lab on Tuesday 11/25 & Wednesday 11/26 • The week of 12/1: Homework 10 due Wednesday 12/3 & Quiz 3 due Thursday 12/4 on SQL Monday, November 24 ! The lab on SQL (12/2 & 12/3) will be an excellent place to get homework help 2 Distributed Computing A distributed computing application consists of multiple programs running on multiple computers that together coordinate to perform some task. • Computation is performed in parallel by many computers. • Information can be restricted to certain computers. • Redundancy and geographic diversity improve reliability. Distributed Computing Characteristics of distributed computing: • Computers are independent — they do not share memory. • Coordination is enabled by messages passed across a network. • Individual programs have differentiating roles. Distributed computing for large-scale data processing: • Databases respond to queries over a network. • Data sets can be partitioned across multiple machines (next lecture). 4 Network Messages Computers communicate via messages: sequences of bytes transmitted over a network. Messages can serve many purposes: • Send data to another computer • Request data from another computer • Instruct a program to call a function on some arguments. Internet Protocol • Transfer a program to be executed by another computer. Messages conform to a message protocol adopted by both the sender (to encode the message) & receiver (to interpret the message).
    [Show full text]
  • User Datagram Protocol (UDP)
    Overview • User datagram protocol (UDP) • Packet checksums • Reliability: sliding window • TCP connection setup • TCP windows, retransmissions, and acknowledgments Transport Protocol Review FTP HTTP NV TFTP TCP UDP IP … NET1 NET2 NETn • Transport protocols sit on top of the network layer (IP) • Can provide: - Application-level multiplexing (“ports”) - Error detection, reliability, etc. UDP – user datagram protocol 0 16 31 SrcPort DstPort Length Checksum Data • Unreliable and unordered datagram service • Adds multiplexing, checksum on whole packet • No flow control, reliability, or order guarantees • Endpoints identified by ports • Checksum aids in error detection Error detection • Transmission errors definitely happen - Cosmic rays, radio interference, etc. - If error probability is 2−30, that’s 1 error per 128 MB! • Some link-layer protocols provide error detection - But UDP/IP must work over many link layers - Not all links on a path may have error detection - Moreover, recall end-to-end argument! Need end-to-end check • UDP detects errors with a checksum - Compute small checksum value, like a hash of the packet - If packet corrupted in transit, checksum likely to be wrong - Similar checksum on IP header, but doesn’t cover payload Checksum algorithms • Good checksum algorithms - Should detect errors that are likely to happen (E.g., should detect any single bit error) - Should be efficient to compute • IP, UDP, and TCP use 1s complement sum: - Set checksum field to 0 - Sum all 16-bit words in pkt - Add any carry bits back in (So 0x8000 +
    [Show full text]
  • Lesson-13: INTERNET ENABLED SYSTEMS NETWORK PROTOCOLS
    DEVICES AND COMMUNICATION BUSES FOR DEVICES NETWORK– Lesson-13: INTERNET ENABLED SYSTEMS NETWORK PROTOCOLS Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 1 Raj Kamal, Publs.: McGraw-Hill Education Internet enabled embedded system Communication to other system on the Internet. Use html (hyper text markup language) or MIME (Multipurpose Internet Mail Extension) type files Use TCP (transport control protocol) or UDP (user datagram protocol) as transport layer protocol Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 2 Raj Kamal, Publs.: McGraw-Hill Education Internet enabled embedded system Addressed by an IP address Use IP (internet protocol) at network layer protocol Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 3 Raj Kamal, Publs.: McGraw-Hill Education MIME Format to enable attachment of multiple types of files txt (text file) doc (MSOFFICE Word document file) gif (graphic image format file) jpg (jpg format image file) wav format voice or music file Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 4 Raj Kamal, Publs.: McGraw-Hill Education A system at one IP address Communication with other system at another IP address using the physical connections on the Internet and routers Since Internet is global network, the system connects to remotely as well as short range located system. Chapter-5 L13: "Embedded Systems - Architecture, Programming and Design", 2015 5 Raj Kamal, Publs.: McGraw-Hill Education
    [Show full text]