User Datagram Protocol with Congestion Control

Total Page:16

File Type:pdf, Size:1020Kb

User Datagram Protocol with Congestion Control Brigham Young University BYU ScholarsArchive Theses and Dissertations 2006-03-22 User Datagram Protocol with Congestion Control Spencer L. Cox Brigham Young University - Provo Follow this and additional works at: https://scholarsarchive.byu.edu/etd Part of the Computer Sciences Commons BYU ScholarsArchive Citation Cox, Spencer L., "User Datagram Protocol with Congestion Control" (2006). Theses and Dissertations. 379. https://scholarsarchive.byu.edu/etd/379 This Thesis is brought to you for free and open access by BYU ScholarsArchive. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of BYU ScholarsArchive. For more information, please contact [email protected], [email protected]. USER DATAGRAM PROTOCOL WITH CONGESTION CONTROL by Spencer Cox A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Department of Computer Science Brigham Young University March 2006 Copyright c 2006 Spencer Cox All Rights Reserved BRIGHAM YOUNG UNIVERSITY GRADUATE COMMITTEE APPROVAL of a thesis submitted by Spencer Cox This thesis has been read by each member of the following graduate committee and by majority vote has been found to be satisfactory. Date Dr. Mark Clement, Chair Date Dr. Daniel Zappala Date Dr. Parris Egbert BRIGHAM YOUNG UNIVERSITY As chair of the candidate's graduate committee, I have read the thesis of Spencer Cox in its final form and have found that (1) its format, citations, and bibliographical style are consistent and acceptable and fulfill university and department style requirements; (2) its illustrative materials including figures, tables, and charts are in place; and (3) the final manuscript is satisfactory to the graduate committee and is ready for submission to the university library. Date Dr. Mark Clement Committee Chairman Accepted for the Department Dr. Parris Egbert Graduate Coordinator Accepted for the College Dr. Thomas W. Sederberg Associate Dean, College of Physical and Mathematical Sciences ABSTRACT USER DATAGRAM PROTOCOL WITH CONGESTION CONTROL Spencer Cox Department of Computer Science Master of Science Communication through the Internet is one of the dominant methods of ex- changing information. Whether at an individual or large corporate level the Internet has become essential to gathering and disseminating information. TCP and UDP are the transport layer protocols responsible for transit of nearly all Internet communica- tions. Due to the growth of real-time audio and video applications, UDP is being used more frequently as a transport protocol. As UDP traffic increases potential problems arise. Unlike TCP, UDP has no mechanism for congestion control leading to wasted bandwidth and poor performance for other competing protocols. This thesis defines a congestion control protocol called UDPCC to replace UDP. Several other protocols or applications have been proposed to provide UDP-like transport with congestion control. DCCP and UDP-MM are two schemes examined and will be used as com- paretors to UDPCC. This thesis will show that the proposed UDPCC can perform at the level of DCCP, UDP-MM or higher while maintaining a simple implementation. ACKNOWLEDGMENTS First I would like to acknowledge my Heavenly Father. Without the blessings and opportunities that he has provided I would not be where I am. I'm indebted to my family. My parents for their complete confidence in me. They believed in what I could accomplish before I believed in myself, their encouragement gave me confidence to pursue and complete this thesis. To my beautiful (future) wife, Annaliese. She spent many hours editing. as well as providing support and fun diversions when things were particularly tough. I want to express thanks to the faculty of the Computer Science Department, in particular Dr Clement. He provided needed insight and added experience to my inexperience. Many thanks to Casey Deccio and Jeremy Goold for creating a fun environment in which to work. Contents Acknowledgments vi List of Tables ix List of Figures xiii 1 Introduction 1 1.1 Internet traffic . 1 1.2 Non-responsive flows . 2 1.3 UDPCC . 3 1.4 Congestion control . 3 1.4.1 Congestion collapse due to undelivered packets . 4 1.4.2 Increased control traffic congestion collapse . 5 1.4.3 Stale packet congestion collapse . 5 1.5 Unfairness problems . 6 1.5.1 TCP friendly . 6 1.5.2 TCP fair . 7 2 Related Work 9 2.1 Existing Protocols . 9 2.1.1 DCCP . 9 2.1.2 MM APP . 11 2.1.3 Other Protocols . 12 3 The Design of UDPCC 13 3.1 Goals . 13 vii 3.2 Overview . 14 3.2.1 Connectionless . 14 3.2.2 Memoryless . 15 3.2.3 Packet header . 15 3.3 Congestion Control Algorithm . 16 3.3.1 Slow Start . 16 3.3.2 Congestion detection mechanism . 16 3.3.3 Reaction to congestion . 18 3.4 TCP fairness . 20 4 Experimental Results 21 4.1 Simulation . 21 4.1.1 Network Simulator ns . 21 4.2 Congestion collapse . 22 4.2.1 Undelivered packets congestion collapse . 22 4.2.2 Ring topology . 22 4.2.3 Parking lot topology . 25 4.3 Sustained throughput . 30 4.3.1 Media friendly in bursty traffic . 30 4.4 Fairness . 33 4.4.1 Fairness with two TCP flows . 34 4.4.2 Fairness with five TCP flows . 35 5 Conclusion 41 5.1 Future Work . 43 A Congestion ring 49 B Goodput with TCP flows 53 viii List of Tables 4.1 Average number of packets dropped by each node for each protocol dur- ing the ten second ring simulation. 25 4.2 Average throughput of each flow during the four 10 second downstream bottleneck simulations . 29 ix x List of Figures 1.1 Packets flowing from node B to node F cause congestion on the link between nodes C and D. 5 3.1 UDPCC data header contains the standard UDP header plus type and sequence number. 15 3.2 UDPCC control header contains the standard UDP header plus type, sequence number and received count. 15 3.3 Simple form of feedback that allows the sender to know how many pack- ets made it to the receiver. 18 3.4 Simple state machine of the AIPD rate control mechanism. 19 4.1 Simple ring topology to test congestion collapse. 23 4.2 Number of packets per time interval of 0.5 seconds that reach destination. 25 4.3 Simple parking lot topology to test congestion collapse. 26 4.4 Goodput of TCP and UDP flows in parking lot topology. 26 4.5 Goodput of TCP and MM APP flows in parking lot topology. 27 4.6 Goodput of TCP and DCCP flows in parking lot topology. 28 4.7 Goodput of TCP and UDPCC flows in parking lot topology. 28 4.8 Goodput of DCCP, MM APP and UDPCC with a single burst of traffic. 31 4.9 Goodput of DCCP, MM APP and UDPCC with continuous bursty traffic. 32 4.10 Dog bone topology with one test protocol flow and between one to n TCP flows. 33 4.11 Goodput of MM APP and two TCP flows. 34 4.12 Goodput of DCCP and two TCP flows. 35 4.13 Goodput of UDPCC and two TCP flows. 36 4.14 Fairness of DCCP, MM APP and UDPCC. 36 xi 4.15 Goodput of MM APP and five TCP flows. 37 4.16 Goodput of DCCP and five TCP flows. 38 4.17 Goodput of UDPCC and five TCP flows. 38 4.18 Fairness of DCCP, MM APP and UDPCC with five TCP flows. 39 A.1 Congestion ring flow 1 . 49 A.2 Congestion ring flow 2 . 50 A.3 Congestion ring flow 3 . 50 A.4 Congestion ring flow 4 . 51 A.5 Congestion ring flow 5 . 51 A.6 Congestion ring flow 6 . 52 A.7 Congestion ring flow 7 . 52 B.1 Goodput of DCCP and one TCP flow . 53 B.2 Goodput of MM APP and one TCP flow . 54 B.3 Goodput of UDPCC and one TCP flow . 54 B.4 Goodput of DCCP and three TCP flows . 55 B.5 Goodput of MM APP and three TCP flows . 55 B.6 Goodput of UDPCC and three TCP flows . 56 B.7 Goodput of DCCP and four TCP flows . 56 B.8 Goodput of MM APP and four TCP flows . 57 B.9 Goodput of UDPCC and four TCP flows . 57 B.10 Goodput of DCCP and six TCP flows . 58 B.11 Goodput of MM APP and six TCP flows . 58 B.12 Goodput of UDPCC and six TCP flows . 59 B.13 Fairness of DCCP, MM APP and UDPCC in the presence of one TCP flow . 59 B.14 Fairness of DCCP, MM APP and UDPCC in the presence of three TCP flows . 60 B.15 Fairness of DCCP, MM APP and UDPCC in the presence of four TCP flows . 60 xii B.16 Fairness of DCCP, MM APP and UDPCC in the presence of six TCP flows . 61 xiii Chapter 1 Introduction 1.1 Internet traffic Internet communications have become the principal method of gathering and transporting information. TCP and UDP are responsible for the transit of nearly all Internet communications but have vastly different usage models [33]. TCP, the more dominant of the two, is a reliable protocol that provides congestion control. How- ever, reliability and congestion control come with substantial overhead. Much of this overhead is due to the delay introduced while the sender awaits an acknowledgment of sent data, which ensures reliability. TCP overhead reduces throughput, making it difficult to run applications that must stream large amounts of data in real-time. In contrast UDP is an unreliable protocol with no mechanism for reliability or congestion control.
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]
  • 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]
  • 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]
  • 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]
  • 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]
  • User Datagram Protocol UDP Is a Connectionless Transport Layer
    UDP: User Datagram Protocol UDP is a connectionless transport layer (layer 4) protocol in OSI model, which provides a simple and unreliable message service for transaction-oriented services. UDP is basically an interface between IP and upper-layer processes. UDP protocol ports distinguish multiple applications running on a single device from one another. Since many network applications may be running on the same machine, computers need something to make sure the correct software application on the destination computer gets the data packets from the source machine, and some way to make sure replies get routed to the correct application on the source computer. This is accomplished through the use of the UDP "port numbers". For example, if a station wished to use a Domain Name System (DNS) on the station 128.1.123.1, it would address the packet to station 128.1.123.1 and insert destination port number 53 in the UDP header. The source port number identifies the application on the local station that requested domain name server, and all response packets generated by the destination station should be addressed to that port number on the source station. Details of UDP port numbers could be found in the TCP/UDP Port Number document and in the reference. Unlike the TCP , UDP adds no reliability, flow-control, or error-recovery functions to IP. Because of UDP's simplicity, UDP headers contain fewer bytes and consume less network overhead than TCP. UDP is useful in situations where the reliability mechanisms of TCP are not necessary, such as in cases where a higher-layer protocol might provide error and flow control, or real time data transportation is required.
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • CHAPTER 02 Quizzes.Pdf
    1 Chapter 2 Quizzes 1 The TCP/IP protocol suite consists of _______ layers. A) two B) three C) five D) six 2 A router is involved in ____________ layers of the TCP/IP protocol suite. A) two B) three C) four D) five 3 A link-layer switch is involved in ______________ layers of the TCP/IP protocol suite. A) two B) three C) four D) five 4 In the TCP/IP protocol suite, which of the following is an application layer protocol? A) The User Datagram Protocol (UDP) B) The Internet Protocol (IP) C) The File Transfer Protocol (FTP) D) The Transmission Control Protocol (TCP) 5 In the TCP/IP protocol suite, which of the following is a transport-layer protocol? A) The Internet Control Message Protocol (ICMP) B) The Internet Protocol (IP) C) The Address Resolution Protocol (ARP) D) The Transmission Control Protocol (TCP) 6 In the TCP/IP protocol suite, which of the following is a network layer protocol? A) The Stream Control Transmission Protocol (SCTP) B) The Secure Shell (SSH) C) The Internet Protocol (IP) D) User Datagram Protocol (UDP) CREATED BY SAHAR SALEM 2 Chapter 2 Quizzes 7 The transport-layer packet in the TCP/IP protocol suite is called _______________. A) a message B) a datagram C) a segment or a user datagram D) a frame 8 In the TCP/IP protocol suite, the ______ layer is responsible for moving frames from one hop (node) to the next. A) physical B) data-link C) transport D) network 9 In the TCP/IP protocol suite, the physical layer is concerned with the movement of _______ over the physical medium.
    [Show full text]
  • Why Are Avaya Phones No Longer Able to Connect Via Ipsec VPN After Code Upgrade on the ASA?
    IPsec FAQ: Why are Avaya phones no longer able to connect via IPsec VPN after code upgrade on the ASA? Contents Introduction Why are Avaya phones no longer able to connect via IPSEC VPN after code upgrade on the Cisco Adaptive Security Appliance (ASA)? Introduction This document describes a problem encountered when Avaya is deployed on a system in which the phones use the built-in Internet Protocol Security (IPsec) client. Why are Avaya phones no longer able to connect via IPSEC VPN after code upgrade on the Cisco Adaptive Security Appliance (ASA)? In order to understand this problem, you need to understand how Network Address Translation traversal (NAT-T) and NAT discovery (NAT-D) works. The NAT-D process is comprised of these steps: 1. Detects one or more NAT devices between IPsec hosts. 2. Identifies if the peer supports NAT-T. 3. Negotiates the use of User Datagram Protocol (UDP) encapsulation of IPsec packets through NAT devices in the Internet Key Exchange (IKE). NAT-D sends the hashes of the IP addresses and ports of both IKE peers from each end to the other. If both ends calculate those hashes and produce the same results, they know there is no NAT between. The hashes are sent as a series of NAT-D payloads. Each payload contains one hash. In the case of multiple hashes, multiple NAT-D payloads are sent. Normally, there are only two NAT-D payloads. The NAT-D payloads are included in the third and fourth packets of the Main Mode, and in the second and third packets of the Aggressive Mode.
    [Show full text]
  • Keyed User Datagram Protocol: Concepts and Operation of an Almost Reliable Connectionless Transport Protocol
    Received September 20, 2018, accepted November 16, 2018, date of publication February 7, 2019, date of current version February 20, 2019. Digital Object Identifier 10.1109/ACCESS.2018.2886707 Keyed User Datagram Protocol: Concepts and Operation of an Almost Reliable Connectionless Transport Protocol NUNO M. GARCIA 1,2, FÁBIO GIL1,3, BÁRBARA MATOS1,4, COULIBALY YAHAYA5, (Member, IEEE), NUNO POMBO1,2, (Member, IEEE), AND ROSSITZA IVANOVA GOLEVA6 1Departamento de Informática, Faculdade de Engenharia, Universidade da Beira Interior, 6200-001 Covilhã, Portugal 2Instituto de Telecomunicações, 6200-001 Covilhã, Portugal 3ECATI, Universidade Lusófona de Humanidades e Tecnologias, 1749-024 Lisbon, Portugal 4Department of Artificial Intelligence and Systems Engineering, Faculty of Computer Science and Information Technology, Riga Technical University, LV-1658 R¯ıga, Latvia 5Université de Ségou, Ségou, Mali 6Department of Informatics, New Bulgarian University, 1618 Sofia, Bulgaria Corresponding author: Nuno M. Garcia ([email protected]) This work was supported by Grant FCT UID/EEA/50008/2013. ABSTRACT Departing from the well-known problem of the excessive overhead and latency of connection oriented protocols, this paper describes a new almost reliable connectionless protocol that uses user datagram protocol (UDP) segment format and is UDP compatible. The problem is presented and described, the motivation, the possible areas of interest and the concept and base operation modes for the protocol named keyed UDP are presented (here called KUDP). Also, discussed are some of the possible manners in which the KUDP can be used, addressing potential problems related with current networking technologies. As UDP is a connectionless protocol, and KUDP allows for some degree of detection of loss and re-ordering of segments received out-of-sequence, we also present a proposal for a stream reconstruction algorithm.
    [Show full text]
  • Tunneling DOWNLOAD
    Tunneling Tunneling is a way of creating a direct connection between two devices across a network, allowing them to communicate as if they were the only two devices around. The tunnel enables these two devices to communicate over the network without understanding TCP/IP or Ethernet. “That sounds like RealPort®,” you say. Well, not quite. RealPort only works if one of the devices is a computer that supports TCP/IP, like Windows or Linux. If neither device is a computer and neither device supports TCP/IP, then you need to tunnel. Tunneling is a way of wrapping up bundles of information on the way into the network and unwrapping them again on the way out. Think of the postal service as a network through which you want to send a letter. Since you know how to use the postal service, you stuff the letter in an envelope, address it, and throw it into the network (or your mailbox). The lucky recipient receives the letter and opens it reading what you’ve just written. That is normal networking. Both the sender and recipient of the letter understand how to send and receive letters through the postal service or network. Now, imagine you’ve never sent any mail and have no idea how to do so, and neither does the recipient. You might find someone else who knows how to use the postal service and hand them the letter. That person wraps up the letter in an envelope and sends it for you. Someone else receives the letter, unwraps it and hands it to your friend.
    [Show full text]