DOCSLIB.ORG

Fixing the Internet: Congestion Control and Buffer Bloat

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fixing the Internet: Congestion Control and Buffer Bloat Fixing the Internet: Congestion Control and Buffer Bloat Influential OS Research Julian Stecklina <[email protected]> Outline TCP Protocol TCP Implementation Queuing Algorithms Buffer Bloat Unreliable Packet Networks A packet can be: ● damaged, ● dropped, ● duplicated, ● reordered with other packets. Need an abstraction to deal with this! Transmission Control Protocol Provides bidirectional channel. Each direction is a reliable byte stream over unreliable best-effort packet network. TCPv4 specified in 1981. Later changes essentially backward compatible. Basis for advanced protocols (MPTCP, SCTP). TCP Header Position in byte +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+stream of first byte | Source Port in this packet | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Byte stream received | Sequence correctlyNumber upto this byte | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number Can receive this many | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+bytes additionally | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format [RFC 793] Receive Window sequence numbers 232 / 0 initial sequence number can be discarded recv’d, ack’d, delivered wait for recv() call by application recv’d, ack’d available space need to for recv’d packets ACK empty recv’d announced window receive buffer Send Window sequence numbers 232 / 0 initial sequence number can be discarded sent, ack’d wait for ACK sent waiting for space waiting to be in receive window transmitted data that data ready can’t be to be sent sent yet send buffer Network Congestion Recognized as a problem in the Internet as soon as 1984 [RFC 896]. By 1986 ‘congestion collapses’ were observed, where bandwidth dropped by orders of magnitude. Especially bad when networks of wildly varying speeds are connected. How much can we send? “The internet is not something you just dump something on. It’s not a big truck. It’s, it’s series of tubes. [...] when you put your message in it, it gets in line, it’s gonna be delayed by anyone who puts into that tube enormous amounts of material [...]” [1] Ted Stevens (former US Senator of Alaska) 5x (re)transmits of same data Data sent faster than slow middle link can handle. Retransmissions in a TCP/IP connection without congestion avoidance. Two fast networks are connected by a slow link. [Jacobson 1988] Network Congestion Connection should reach an equilibrium where ‘conservation of packets’ principle holds. [Jacobson 1988] How to get to equilibrium? → Slow Start How to maintain it? → Round-trip Timing → Congestion Avoidance “Self-clocking” in a TCP connection. Number of packets in-flight is constant. [Jacobson 1988] Bandwidth Delay Product (BDP) BDP = packet delay ⋅ bandwidth The ideal amount of unacknowledged data in-flight. In TCP speak, usually called the ‘pipe size’. Round-Trip Time Estimation Need RTT estimation to know when to retransmit data. Retransmitting earlier violates conservation rule, later wastes bandwidth. Old method [RFC 793] roughly: last smoothin scaling measured g factor factor RTT R ← αR + (1 - α)M RTO ← βR smoothed RTT Retransmission Timeout Retransmission Death Spiral β in [1.3, 2.0] was suggested, but a loaded network exhibits more variance in RTTs. Early retransmissions → More traffic → More RTT variance → Collapse A solution is to estimate β based on observed variance. Estimating RTT Variation Error: e ← M - R RTT estimation: R ← R + αe (same as before) Var. estimation*: v ← v + α’(|e| - v) RTO ← R + 4v RTO adapts to changes in RTT variance. No early retransmissions in most scenarios. *Computes mean deviation, which is smaller than the standard deviation. Slow Start Probe available bandwidth by adding a congestion window. Only send min(cwnd, rwnd) bytes. Congestion window starts at 1* packet. Increase by 1 per received ACK. Effectively double bandwidth per packet round-trip. No need to change wire protocol. * Today we usually use 2 or more packets and ACKs are generated every two packets. Congestion Avoidance With proper RTO, timeout fires for lost packets. Packets are lost due to damage or congestion. TCP model assumes rare packet damage. Timeout indicates network congestion. When congestion occurs, half the current window size is remembered as ssthresh. cwnd is set to intial value. Slow start takes over again. (4.3BSD Tahoe TCP) Congestion Avoidance If cwnd > ssthresh, slow start is stopped and window grows linear by at most 1 segment per RTT. [Stevens 1994] TCP/IP with Slow Start and Congestion Avoidance. [Jacobson 1988] Recap: TCP Two phases for operation: ● Slow-Start with exponential window growth on new connection or after packet loss ● Congestion Avoidance with linear window growth. RTT estimation is crucial to maintain ‘conservation of packets’. Packet loss behavior is improved with Fast Retransmit and Fast Recovery. Assumptions on Internet Routers Routers/switches in the Internet are dumb best-effort. Packets may be: ● dropped ● damaged ● reordered. Transient congestion is handled via buffers. Routers know in advance that congestion is likely. Global Synchronization With FIFO queue and Tail Drop, a congestion causes multiple TCP connections to back off and slow start at the same time. Connections synchronize: Cause congestion again. Available bandwidth is used inefficiently when Global Synchronization occurs. RED - Random Early Detection Probabilistically mark packets when queue is getting filled. Drop if protocol doesn’t support marking. [Floyd 1993]: don’t mark mark fewmark moremark all packets packets packets packets minth maxth filled filled filled filled empty Switch Buffer full RED: Mark Probability When average queue size between minth and maxth: pb = maxp (avg - minth) / (maxth - minth) Avoid global synchronization by keeping counter since last mark: pa = pb / (1 - count · pb) th At pb = 0.01 at least every 100 packet will be dropped. Early Congestion Notification Dropping packets if switch has buffer space is wasteful. ECN introduces marking of TCP packets [RFC 3168]. Congestion Experienced (CE) treated as packet loss. Not widely deployed due to compatibility concerns. Recap: Queue Management Simple FIFO queues in switches lead to global synchronization and poor performance. Active queue management (AQM) needed. RED is an example of an AQM system with probabilistic marking/dropping of packets according to average queue size. AQM is complicated, so... use el cheapo solution: Large buffers. “AQM is MIA” [Gettys 2011] TCP fills the pipe! Buffer in front of slowest link will be filled. Link latency inflated → “Bufferbloat” Problem here, if WiFi slow. Problem here, if DSL/cable Problem here, slow. if Netflix has a new Breaking Bad episode. ISP Switch Problematic buffer in front of slowest link. But slowest link and bandwidth change! Buffer at slowest link (startup) [Nichols 2012] After one RTT it is clear that queue will never be empty. Congestion window larger than BDP! [Nichols 2012] Standing Queues When the congestion window is larger than BDP, standing queues develop. Standing queues add needless latency: 1 MiB standing router buffer, 16 MBit/s link speed → ~0.5s latency Latency vs. Fairness RTT determines “reaction time” of TCP connection. A long lived connection causing large latency essentially starves short-lived connections. Short connections spend most time in Slow Start. Ramp up speed determined by RTT. ‘Good’ vs. ‘Bad’ Queue How do we decide how much queueing is bad? [Nichols 2012] ‘Good’ queue: ● absorbs temporary changes in packet arrival ● resolves after RTT roughly ‘Bad’ queue: ● adds needless latency ● persists for several RTT Queue length in the standing queue situation. [Nichols 2012] Controlled Delay (CoDel) Queueing Idea: Control delay of queue. t Target delay of queue (5ms) i Measuring interval (100ms) When minimum queue delay of packets in measuring interval is exceeding t for longer than i, start dropping packets. Details in [Nichols 2012]. TCP Implementation *BSD / Linux implementations are largely similar. Kernel implements complete protocol stack. BSD sockets API maps TCP connections to file descriptors for applications: ● bind/connect/send/recv/… ● read/write user kernel hardware network driver TCP/IP stack socket layer Application socket queue device queue Send buffering in a typical TCP/IP stack. Device Queue Fixed-size queue in front of driver usually limited in the number of packets. 1000 64-byte packets at 54MBit/s: ~9.4ms 1000 1518-byte packets at 1MBit/s: ~12s One queue size doesn’t fit all. Linux: Byte Queue Limits Dynamically adapt maximum queue length of NIC measured in bytes: ● Increase maximum if NIC is starved quickly. ● Decrease maximum if NIC cannot keep up slowly. Implemented in Linux 3.3. [Hruby 2012] Experimental CoDel is built on top. Linux: TCP Small Queues Linux’ TCP/IP has several queues between the application and the hardware. Introduce a configurable global limit on data queued for a single connection: /proc/sys/net/ipv4/tcp_limit_output_bytes (128K) First step to more comprehensive queue management. Wrap up Effective flow / congestion control in TCP needs: ● the protocol (ECN, SACK, …) ● the protocol implementation (cwnd, ...) ● the OS implementation (BQL, TCP small queues) Sidenote: InfiniBand Networks Infiniband is a HPC / datacenter interconnect. It uses credit-based flow control to never send data unless a data buffer is available. Switches need less buffer space. Very low latency. References [Jacobson 1988] Congestion Avoidance and Control [Floyd 1993] Random early detection gateways for congestion avoidance [Gettys 2011] Bufferbloat: Dark Buffers in the Internet [Nichols 2012] Controlling Queue Delay CeroWRT Bufferbloat-reducing router firmware based on OpenWRT.
Load more

Recommended publications
  • Traffic Management in Multi-Service Access Networks
    MARKETING REPORT MR-404 Traffic Management in Multi-Service Access Networks Issue: 01 Issue Date: September 2017 © The Broadband Forum. All rights reserved. Traffic Management in Multi-Service Access Networks MR-404 Issue History Issue Approval date Publication Date Issue Editor Changes Number 01 4 September 2017 13 October 2017 Christele Bouchat, Original Nokia Comments or questions about this Broadband Forum Marketing Draft should be directed to [email protected] Editors Francois Fredricx Nokia [email protected] Florian Damas Nokia [email protected] Ing-Jyh Tsang Nokia [email protected] Innovation Christele Bouchat Nokia [email protected] Leadership Mauro Tilocca Telecom Italia [email protected] September 2017 © The Broadband Forum. All rights reserved 2 of 16 Traffic Management in Multi-Service Access Networks MR-404 Executive Summary Traffic Management is a widespread industry practice for ensuring that networks operate efficiently, including mechanisms such as queueing, routing, restricting or rationing certain traffic on a network, and/or giving priority to some types of traffic under certain network conditions, or at all times. The goal is to minimize the impact of congestion in networks on the traffic’s Quality of Service. It can be used to achieve certain performance goals, and its careful application can ultimately improve the quality of an end user's experience in a technically and economically sound way, without detracting from the experience of others. Several Traffic Management mechanisms are vital for a functioning Internet carrying all sorts of Over-the-Top (OTT) applications in “Best Effort” mode. Another set of Traffic Management mechanisms is also used in networks involved in a multi-service context, to provide differentiated treatment of various services (e.g.
    [Show full text]
  • Analysing TCP Performance When Link Experiencing Packet Loss
    Analysing TCP performance when link experiencing packet loss Master of Science Thesis [in the Programme Networks and Distributed System] SHAHRIN CHOWDHURY KANIZ FATEMA Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, October 2013 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Analysing TCP performance when link experiencing packet loss SHAHRIN CHOWDHURY, KANIZ FATEMA © SHAHRIN CHOWDHURY, October 2013. © KANIZ FATEMA, October 2013. Examiner: TOMAS OLOVSSON Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden October 2013 Acknowledgement We are grateful to our supervisor and examiner Tomas Olovsson for his valuable time and assistance in compilation for this thesis.
    [Show full text]
  • Application Note Pre-Deployment and Network Readiness Assessment Is
    Application Note Contents Title Six Steps To Getting Your Network Overview.......................................................... 1 Ready For Voice Over IP Pre-Deployment and Network Readiness Assessment Is Essential ..................... 1 Date January 2005 Types of VoIP Overview Performance Problems ...... ............................. 1 This Application Note provides enterprise network managers with a six step methodology, including pre- Six Steps To Getting deployment testing and network readiness assessment, Your Network Ready For VoIP ........................ 2 to follow when preparing their network for Voice over Deploy Network In Stages ................................. 7 IP service. Designed to help alleviate or significantly reduce call quality and network performance related Summary .......................................................... 7 problems, this document also includes useful problem descriptions and other information essential for successful VoIP deployment. Pre-Deployment and Network IP Telephony: IP Network Problems, Equipment Readiness Assessment Is Essential Configuration and Signaling Problems and Analog/ TDM Interface Problems. IP Telephony is very different from conventional data applications in that call quality IP Network Problems: is especially sensitive to IP network impairments. Existing network and “traditional” call quality Jitter -- Variation in packet transmission problems become much more obvious with time that leads to packets being the deployment of VoIP service. For network discarded in VoIP
    [Show full text]
  • Latency and Throughput Optimization in Modern Networks: a Comprehensive Survey Amir Mirzaeinnia, Mehdi Mirzaeinia, and Abdelmounaam Rezgui
    READY TO SUBMIT TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS JOURNAL 1 Latency and Throughput Optimization in Modern Networks: A Comprehensive Survey Amir Mirzaeinnia, Mehdi Mirzaeinia, and Abdelmounaam Rezgui Abstract—Modern applications are highly sensitive to com- On one hand every user likes to send and receive their munication delays and throughput. This paper surveys major data as quickly as possible. On the other hand the network attempts on reducing latency and increasing the throughput. infrastructure that connects users has limited capacities and These methods are surveyed on different networks and surrond- ings such as wired networks, wireless networks, application layer these are usually shared among users. There are some tech- transport control, Remote Direct Memory Access, and machine nologies that dedicate their resources to some users but they learning based transport control, are not very much commonly used. The reason is that although Index Terms—Rate and Congestion Control , Internet, Data dedicated resources are more secure they are more expensive Center, 5G, Cellular Networks, Remote Direct Memory Access, to implement. Sharing a physical channel among multiple Named Data Network, Machine Learning transmitters needs a technique to control their rate in proper time. The very first congestion network collapse was observed and reported by Van Jacobson in 1986. This caused about a I. INTRODUCTION thousand time rate reduction from 32kbps to 40bps [3] which Recent applications such as Virtual Reality (VR), au- is about a thousand times rate reduction. Since then very tonomous cars or aerial vehicles, and telehealth need high different variations of the Transport Control Protocol (TCP) throughput and low latency communication.
    [Show full text]
  • Lab 6: Understanding Traditional TCP Congestion Control (HTCP, Cubic, Reno)
    NETWORK TOOLS AND PROTOCOLS Lab 6: Understanding Traditional TCP Congestion Control (HTCP, Cubic, Reno) Document Version: 06-14-2019 Award 1829698 “CyberTraining CIP: Cyberinfrastructure Expertise on High-throughput Networks for Big Science Data Transfers” Lab 6: Understanding Traditional TCP Congestion Control Contents Overview ............................................................................................................................. 3 Objectives............................................................................................................................ 3 Lab settings ......................................................................................................................... 3 Lab roadmap ....................................................................................................................... 3 1 Introduction to TCP ..................................................................................................... 3 1.1 TCP review ............................................................................................................ 4 1.2 TCP throughput .................................................................................................... 4 1.3 TCP packet loss event ........................................................................................... 5 1.4 Impact of packet loss in high-latency networks ................................................... 6 2 Lab topology...............................................................................................................
    [Show full text]
  • Adaptive Method for Packet Loss Types in Iot: an Naive Bayes Distinguisher
    electronics Article Adaptive Method for Packet Loss Types in IoT: An Naive Bayes Distinguisher Yating Chen , Lingyun Lu *, Xiaohan Yu * and Xiang Li School of Computer and Information Technology, Beijing Jiaotong University, Beijing 100044, China; [email protected] (Y.C.); [email protected] (X.L.) * Correspondence: [email protected] (L.L.); [email protected] (X.Y.) Received: 31 December 2018; Accepted: 23 January 2019; Published: 28 January 2019 Abstract: With the rapid development of IoT (Internet of Things), massive data is delivered through trillions of interconnected smart devices. The heterogeneous networks trigger frequently the congestion and influence indirectly the application of IoT. The traditional TCP will highly possible to be reformed supporting the IoT. In this paper, we find the different characteristics of packet loss in hybrid wireless and wired channels, and develop a novel congestion control called NB-TCP (Naive Bayesian) in IoT. NB-TCP constructs a Naive Bayesian distinguisher model, which can capture the packet loss state and effectively classify the packet loss types from the wireless or the wired. More importantly, it cannot cause too much load on the network, but has fast classification speed, high accuracy and stability. Simulation results using NS2 show that NB-TCP achieves up to 0.95 classification accuracy and achieves good throughput, fairness and friendliness in the hybrid network. Keywords: Internet of Things; wired/wireless hybrid network; TCP; naive bayesian model 1. Introduction The Internet of Things (IoT) is a new network industry based on Internet, mobile communication networks and other technologies, which has wide applications in industrial production, intelligent transportation, environmental monitoring and smart homes.
    [Show full text]
  • A Comparison of Voip Performance on Ipv6 and Ipv4 Networks
    A Comparison of VoIP Performance on IPv6 and IPv4 Networks Roman Yasinovskyy, Alexander L. Wijesinha, Ramesh K. Karne, and Gholam Khaksari Towson University increasingly used on the Internet today. The increase Abstract—We compare VoIP performance on IPv6 in IPv6 packet size due to the larger addresses is and IPv4 LANs in the presence of varying levels of partly offset by a streamlined header with optional background UDP traffic. A conventional softphone is extension headers (the header fields in IPv4 for used to make calls and a bare PC (operating system- fragmentation support and checksum are eliminated less) softphone is used as a control to determine the impact of system overhead. The performance measures in IPv6). are maximum and mean delta (the time between the As the growing popularity of VoIP will make it a arrival of voice packets), maximum and mean jitter, significant component of traffic in the future Internet, packet loss, MOS (Mean Opinion Score), and it is of interest to compare VoIP performance over throughput. We also determine the relative frequency IPv6 and IPv4. The results would help to determine if distribution for delta. It is found that mean values of there are any differences in VoIP performance over delta for IPv4 and IPv6 are similar although maximum values are much higher than the mean and show more IPv6 compared to IPv4 due to overhead resulting variability at higher levels of background traffic. The from the larger IPv6 header (and packet size). We maximum jitter for IPv6 is slightly higher than for IPv4 focus on comparing VoIP performance with IPv6 and but mean jitter values are approximately the same.
    [Show full text]
  • Buffer De-Bloating in Wireless Access Networks
    Buffer De-bloating in Wireless Access Networks by Yuhang Dai A thesis submitted to the University of London for the degree of Doctor of Philosophy School of Electronic Engineering & Computer Science Queen Mary University of London United Kingdom Sep 2018 TO MY FAMILY Abstract Excessive buffering brings a new challenge into the networks which is known as Bufferbloat, which is harmful to delay sensitive applications. Wireless access networks consist of Wi-Fi and cellular networks. In the thesis, the performance of CoDel and RED are investigated in Wi-Fi networks with different types of traffic. Results show that CoDel and RED work well in Wi-Fi networks, due to the similarity of protocol structures of Wi-Fi and wired networks. It is difficult for RED to tune parameters in cellular networks because of the time-varying channel. CoDel needs modifications as it drops the first packet of queue and thehead packet in cellular networks will be segmented. The major contribution of this thesis is that three new AQM algorithms tailored to cellular networks are proposed to alleviate large queuing delays. A channel quality aware AQM is proposed using the CQI. The proposed algorithm is tested with a single cell topology and simulation results show that the proposed algo- rithm reduces the average queuing delay for each user by 40% on average with TCP traffic compared to CoDel. A QoE aware AQM is proposed for VoIP traffic. Drops and delay are monitored and turned into QoE by mathematical models. The proposed algorithm is tested in NS3 and compared with CoDel, and it enhances the QoE of VoIP traffic and the average end- to-end delay is reduced by more than 200 ms when multiple users with different CQI compete for the wireless channel.
    [Show full text]
  • Congestion Control Overview
    ELEC3030 (EL336) Computer Networks S Chen Congestion Control Overview • Problem: When too many packets are transmitted through a network, congestion occurs At very high traffic, performance collapses Perfect completely, and almost no packets are delivered Maximum carrying capacity of subnet • Causes: bursty nature of traffic is the root Desirable cause → When part of the network no longer can cope a sudden increase of traffic, congestion Congested builds upon. Other factors, such as lack of Packets delivered bandwidth, ill-configuration and slow routers can also bring up congestion Packets sent • Solution: congestion control, and two basic approaches – Open-loop: try to prevent congestion occurring by good design – Closed-loop: monitor the system to detect congestion, pass this information to where action can be taken, and adjust system operation to correct the problem (detect, feedback and correct) • Differences between congestion control and flow control: – Congestion control try to make sure subnet can carry offered traffic, a global issue involving all the hosts and routers. It can be open-loop based or involving feedback – Flow control is related to point-to-point traffic between given sender and receiver, it always involves direct feedback from receiver to sender 119 ELEC3030 (EL336) Computer Networks S Chen Open-Loop Congestion Control • Prevention: Different policies at various layers can affect congestion, and these are summarised in the table • e.g. retransmission policy at data link layer Transport Retransmission policy • Out-of-order caching
    [Show full text]
  • The Effects of Different Congestion Control Algorithms Over Multipath Fast Ethernet Ipv4/Ipv6 Environments
    Proceedings of the 11th International Conference on Applied Informatics Eger, Hungary, January 29–31, 2020, published at http://ceur-ws.org The Effects of Different Congestion Control Algorithms over Multipath Fast Ethernet IPv4/IPv6 Environments Szabolcs Szilágyi, Imre Bordán Faculty of Informatics, University of Debrecen, Hungary [email protected] [email protected] Abstract The TCP has been in use since the seventies and has later become the predominant protocol of the internet for reliable data transfer. Numerous TCP versions has seen the light of day (e.g. TCP Cubic, Highspeed, Illinois, Reno, Scalable, Vegas, Veno, etc.), which in effect differ from each other in the algorithms used for detecting network congestion. On the other hand, the development of multipath communication tech- nologies is one today’s relevant research fields. What better proof of this, than that of the MPTCP (Multipath TCP) being integrated into multiple operating systems shortly after its standardization. The MPTCP proves to be very effective for multipath TCP-based data transfer; however, its main drawback is the lack of support for multipath com- munication over UDP, which can be important when forwarding multimedia traffic. The MPT-GRE software developed at the Faculty of Informatics, University of Debrecen, supports operation over both transfer protocols. In this paper, we examine the effects of different TCP congestion control mechanisms on the MPTCP and the MPT-GRE multipath communication technologies. Keywords: congestion control, multipath communication, MPTCP, MPT- GRE, transport protocols. 1. Introduction In 1974, the TCP was defined in RFC 675 under the Transmission Control Pro- gram name. Later, the Transmission Control Program was split into two modular Copyright © 2020 for this paper by its authors.
    [Show full text]
  • Impact of Packet Losses on the Quality of Video Streaming
    Master Thesis Electrical Engineering Thesis no: MEE10:44 June 2010 Impact of Packet Losses on the Quality of Video Streaming JOHN Samson Mwela & OYEKANLU Emmanuel Adebomi School of Computing Internet : www.bth.se/com School of Computing Blekinge Institute of Technology Phone : +46 457 38 50 00 Blekinge Institute of Technology Box 520 Fax : + 46 457 271 25 Box 520 i SE – 371 79Karlskrona SE – 372 25 Ronneby Sweden Sweden This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author(s): JOHN Samson Mwela Blekinge Institute of Technology E-mail: [email protected] OYEKANLU Emmanuel Adebomi Blekinge Institute of Technology E-mail: [email protected] Supervisor Tahir Nawaz Minhas School of Computing Examiner Dr. Patrik Arlos, PhD School of Computing School of Computing Blekinge Institute of Technology Box 520 SE – 371 79 Karlskrona Sweden i ABSTRACT In this thesis, the impact of packet losses on the quality of received videos sent across a network that exhibit normal network perturbations such as jitters, delays, packet drops etc has been examined. Dynamic behavior of a normal network has been simulated using Linux and the Network Emulator (NetEm). Peoples’ perceptions on the quality of the received video were used in rating the qualities of several videos with differing speeds. In accordance with ITU’s guideline of using Mean Opinion Scores (MOS), the effects of packet drops were analyzed. Excel and Matlab were used as tools in analyzing the peoples’ opinions which indicates the impacts that different loss rates has on the transmitted videos.
    [Show full text]
  • What Causes Packet Loss IP Networks
    What Causes Packet Loss IP Networks (Rev 1.1) Computer Modules, Inc. DVEO Division 11409 West Bernardo Court San Diego, CA 92127, USA Telephone: +1 858 613 1818 Fax: +1 858 613 1815 www.dveo.com Copyright © 2016 Computer Modules, Inc. All Rights Reserved. DVEO, DOZERbox, DOZER Racks and DOZER ARQ are trademarks of Computer Modules, Inc. Specifications and product availability are subject to change without notice. Packet Loss and Reasons Introduction This Document To stream high quality video, i.e. to transmit real-time video streams, over IP networks is a demanding endeavor and, depending on network conditions, may result in packets being dropped or “lost” for a variety of reasons, thus negatively impacting the quality of user experience (QoE). This document looks at typical reasons and causes for what is generally referred to as “packet loss” across various types of IP networks, whether of the managed and conditioned type with a defined Quality of Service (QoS), or the “unmanaged” kind such as the vast variety of individual and interconnected networks across the globe that collectively constitute the public Internet (“the Internet”). The purpose of this document is to encourage operators and enterprises that wish to overcome streaming video quality problems to explore potential solutions. Proven technology exists that enables transmission of real-time video error-free over all types of IP networks, and to perform live broadcasting of studio quality content over the “unmanaged” Internet! Core Protocols of the Internet Protocol Suite The Internet Protocol (IP) is the foundation on which the Internet was built and, by extension, the World Wide Web, by enabling global internetworking.
    [Show full text]