DOCSLIB.ORG

TCP Congestion Control) Checksum Urgent Pointer Options (Variable)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
TCP Congestion Control) Checksum Urgent Pointer Options (Variable) TCP Header 0 4 10 16 31 Source port Destination port Sequence number Acknowledgement CS 268: Lecture 6 HdrLen Flags Advertised window (TCP Congestion Control) Checksum Urgent pointer Options (variable) ¡ Sequence number, acknowledgement, and advertised window – used by Ion Stoica sliding-window based flow control February 6, 2006 ¡ Flags: - SYN, FIN – establishing/terminating a TCP connection - ACK – set when Acknowledgement field is valid - URG – urgent data; Urgent Pointer says where non-urgent data starts - PUSH – don’t wait to fill segment - RESET – abort connection 4 Today’s Lecture TCP Header (Cont) ¢ Checksum – 1’s complement and is computed over - TCP header Basics of Transport - TCP data - Pseudo-header (from IP header) • Note: breaks the layering! Basics of Congestion Control Source address Destination address Comments on Congestion Control 0 Protocol (TCP) TCP Segment length 2 5 Duties of Transport TCP Connection Establishment Demultiplexing: Three-way handshake - IP header points to protocol - Goal: agree on a set of parameters: the start sequence - Transport header needs demultiplex further number for each side • UDP: port Client (initiator) Server • TCP: source and destination address/port SYN, Se - Well known ports and ephemeral ports qNum = x + 1 nd Ack = x a um = y CK, SeqN Data reliability (if desired): SYN and A - UDP: checksum, but no data recovery ACK, A - TCP: checksum and data recovery ck = y + 1 3 6 1 TCP Issues Observations Connection confusion: Throughput is ~ (w/RTT) - ISNs can’t always be the same Sender has to buffer all unacknowledged packets, Source spoofing: because they may require retransmission - Need to make sure ISNs are random Receiver may be able to accept out-of-order packets, SYN floods: but only up to its buffer limits - SYN cookies State management with many connections - Server-stateless TCP (NSDI 05) 7 10 TCP Flow Control What Should the Receiver ACK? Make sure receiving end can handle data 1. ACK every packet, giving its sequence number Negotiated end-to-end, with no regard to network 2. Use negative ACKs (NACKs), indicating which packet did not arrive Ends must ensure that no more than W packets are in flight 3. Use cumulative ACK, where an ACK for number - Receiver ACKs packets n implies ACKS for all k < n - When sender gets an ACK, it knows packet has arrived 4. Use selective ACKs (SACKs), indicating those that did arrive, even if not in order 8 11 Sliding Window Error Recovery Must retransmit packets that were dropped ¡ ¢ To do this efficiently £ - Keep transmitting whenever possible ¤ - Detect dropped packets and retransmit quickly ¥ ¦ Requires: ¤ - Timeouts (with good timers) - Other hints that packet were dropped ¥ ¦ §©¨ © "! ¨ # $%§&¨ ' )(* +& ,- . © "! ¨ # $ 9 12 2 Timer Algorithm Dangers of Increasing Load packet knee cliff t loss Use exponential averaging: Knee – point after which u p - Throughput increases very slow h ¢¡¤£¦¥¨§ © ¡¤£¦¥ ¡© ¥ ¡¤£¦¥ g u - Delay increases fast o congestion ¡¤£¦¥¨§ © ¡¤£¤¥¨ ¡© ¥¤ ¦¡ ¡¤£¦¥ ¡¤£¦¥¥ r h collapse "!$#% &¡¤£¦¥¨§' ¢¡¤£¦¥¨)(*+¡¤£¦¥ T Cliff – point after which - Throughput starts to decrease very fast to zero (congestion Load Question: Why not set timeout to average delay? y collapse) a l - Delay approaches infinity e D , - ¨ ( 43 5 $ +5)6 798 ( ( ! 5 ¨6© ( ¨¢5 : & 5 .0/21 In an M/M/1 queue =6 43 : ¨08* ( : © ?> ;)/2< - Delay = 1/(1 – utilization) @)/2A 3 :. B8 (C5 & #-¨ +ED ¨5 5 ( + , 13 Load 16 Hints Cong. Control vs. Cong. Avoidance When should I suspect a packet was dropped? Congestion control goal - Stay left of cliff When I receive several duplicate ACKs Congestion avoidance goal - Receiver sends an ACK whenever a packet arrives - Stay left of knee knee cliff - ACK indicates seq. no. of last received consecutively t u received packet p h - Duplicate ACKs indicates missing packet g u congestion o r h collapse T Load 14 17 TCP Congestion Control Control System Model [CJ89] User 1 Can the network handle the rate of data? x1 x2 Determined end-to-end, but TCP is making User 2 Σ Σx >X guesses about the state of the network i goal xn User n y Two papers: - Good science vs great engineering ¢ Simple, yet powerful model ¢ Explicit binary signal of congestion 15 18 3 Multiplicative Increase, Possible Choices Multiplicative Decrease ¢ fairness ¥ ¤ a + b x (t) increase line + = I I i £ ¡ x (t 1) Converges to (x ,x ) i + 1h 2h aD bD xi (t)decrease stable cycle, (bIbDx1h, ¢ but is not fair b b x ) Multiplicative increase, additive decrease I D 2h - aI=0, bI>1, aD<0, bD=1 2 x ¢ : Additive increase, additive decrease 2 r - a >0, b =1, a <0, b =1 e (bdx1h,bdx2h) I I D D s U ¢ Multiplicative increase, multiplicative decrease - aI=0, bI>1, aD=0, 0<bD<1 ¢ Additive increase, multiplicative decrease - a >0, b =1, a =0, 0<b <1 I I D D efficiency ¢ Which one? line User 1: x1 19 22 Multiplicative Increase, Additive Increase, Additive Decrease Multiplicative Decrease fairness fairness line line Fixed point at (bI(x1h+aD), bI(x2h+aD)) Converges to (x1h,x2h) stable and (bDx1h+aI, b x +a ) bI aD fair cycle D 2h I x = x = (x1h,x2h) 1h 2h 1− b I 2 2 x x : : 2 2 r r e (x1h+aD,x2h+aD) e (bDx1h,bDx2h) Fixed point is s s unstable! U U efficiency efficiency line line User 1: x1 User 1: x1 20 23 Additive Increase, Additive Decrease Modeling fairness (x1h+aD+aI), line Reaches x2h+aD+aI)) Critical to understanding complex systems stable cycle, - [CJ89] model relevant after 15 years, 106 increase of but does not bandwidth, 1000x increase in number of users (x1h,x2h) converge to 2 x fairness : Criteria for good models 2 r e (x1h+aD,x2h+aD) - Two conflicting goals: reality and simplicity s U - Realistic, complex model → too hard to understand, too limited in applicability - Unrealistic, simple model → can be misleading efficiency line User 1: x1 21 24 4 TCP Congestion Control Slow Start Example ¢ [CJ89] provides theoretical basis for basic The congestion segment 1 window size grows cwnd = 1 congestion avoidance mechanism very rapidly ACK 2 cwnd = 2 segment 2 segment 3 Must turn this into real protocol ACK 4 cwnd = 4 ¢ TCP slows down segment 4 segment 5 the increase of segment 6 cwnd when segment 7 cwnd >= ssthresh ACK8 cwnd = 8 25 28 TCP Congestion Control Congestion Avoidance Maintains three variables: ¢ Slow down “Slow Start” - cwnd: congestion window - flow_win: flow window; receiver advertised window ¢ ssthresh is lower-bound guess about location of knee - Ssthresh: threshold size (used to update cwnd) - ¢ If cwnd > ssthresh then each time a segment is acknowledged For sending, use: win = min(flow_win, cwnd) increment cwnd by 1/cwnd (cwnd += 1/cwnd). ¢ So cwnd is increased by one only if all segments have been acknowledged. 26 29 Slow Start/Congestion Avoidance TCP: Slow Start Example cwnd = 1 Goal: reach knee quickly Assume that cwnd = 2 ssthresh = 8 cwnd = 4 Upon starting (or restarting): 14 12 - Set cwnd =1 10 cwnd = 8 ) s - Each time a segment is acknowledged increment t n 8 cwnd by one (cwnd++). e m ssthresh g 6 e s n i ( 4 Slow Start is not actually slow d n 2 cwnd = 9 w - cwnd increases exponentially C 0 0 2 4 6 t= t= t= t= Roundtrip times cwnd = 10 27 30 5 Putting Everything Together: TCP Pseudocode Fast Recovery Initially: cwnd = 1; while (next < unack + win) After a fast-retransmit set cwnd to ssthresh/2 ssthresh = infinite; transmit next packet; - i.e., don’t reset cwnd to 1 New ack received: if (cwnd < ssthresh) /* Slow Start*/ where win = min(cwnd, But when RTO expires still do cwnd = 1 cwnd = cwnd + 1; flow_win); else /* Congestion Avoidance */ Fast Retransmit and Fast Recovery cwnd = cwnd + 1/cwnd; seq # unack next - Implemented by TCP Reno Timeout: - Most widely used version of TCP today /* Multiplicative decrease */ ssthresh = cwnd/2; win cwnd = 1; Lesson: avoid RTOs at all costs! 31 34 The big picture Fast Retransmit and Fast Recovery cwnd cwnd Congestion Avoidance Slow Start Timeout Congestion Avoidance Time Slow Start Retransmit after 3 duplicated acks - prevent expensive timeouts No need to slow start again Time At steady state, cwnd oscillates around the optimal window size. 32 35 Fast Retransmit Engineering vs Science in CC ¢ Don’t wait for window to cwnd = 1 segment 1 Great engineering built useful protocol: drain ACK 2 - TCP Reno, etc. cwnd = 2 segment 2 ¢ Resend a segment after 3 segment 3 duplicate ACKs ACK 3 Good science by CJ and others ACK 4 cwnd = 4 segment 4 - Basis for understanding why it works so well segment 5 segment 6 ACK 4 segment 7 ACK 4 3 duplicate ACK 4 ACKs 33 36 6 Behavior of TCP TCP: Cooperation and Compatibility Are packets smoothly paced? TCP assumes all flows employ TCP-like - NO! Ack-compression congestion control - TCP-friendly or TCP-compatible Are long-lived flows nicely interleaved? - NO! Selfish flows: can get all the bandwidth they like How does throughput depend on drop rate? If new congestion control algorithms are developed, they must be TCP-friendly Tput ~ 1/sqrt(d) 37 40 Extensions to TCP Selective acknowledgements: TCP SACK Explicit congestion notification: ECN Delay-based congestion avoidance: TCP Vegas Discriminating between congestion losses and other losses: cross-layer signaling and guesses Randomized drops (RED) and other router mechanisms 38 Issues with TCP Fairness: - Throughput depends on RTT High speeds: - to reach 10gbps, packet losses occur every 90 minutes! Short flows: - How to set initial cwnd properly What about flows that want congestion control, but don’t want reliable delivery? 39 7.
Load more

Recommended publications
  • TCP Congestion Control: Overview and Survey of Ongoing Research
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 2001 TCP Congestion Control: Overview and Survey Of Ongoing Research Sonia Fahmy Purdue University, [email protected] Tapan Prem Karwa Report Number: 01-016 Fahmy, Sonia and Karwa, Tapan Prem, "TCP Congestion Control: Overview and Survey Of Ongoing Research" (2001). Department of Computer Science Technical Reports. Paper 1513. https://docs.lib.purdue.edu/cstech/1513 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. TCP CONGESTION CONTROL: OVERVIEW AND SURVEY OF ONGOING RESEARCH Sonia Fahmy Tapan Prem Karwa Department of Computer Sciences Purdue University West Lafayette, IN 47907 CSD TR #01-016 September 2001 TCP Congestion Control: Overview and Survey ofOngoing Research Sonia Fahmy and Tapan Prem Karwa Department ofComputer Sciences 1398 Computer Science Building Purdue University West Lafayette, IN 47907-1398 E-mail: {fahmy,tpk}@cs.purdue.edu Abstract This paper studies the dynamics and performance of the various TCP variants including TCP Tahoe, Reno, NewReno, SACK, FACK, and Vegas. The paper also summarizes recent work at the lETF on TCP im­ plementation, and TCP adaptations to different link characteristics, such as TCP over satellites and over wireless links. 1 Introduction The Transmission Control Protocol (TCP) is a reliable connection-oriented stream protocol in the Internet Protocol suite. A TCP connection is like a virtual circuit between two computers, conceptually very much like a telephone connection. To maintain this virtual circuit, TCP at each end needs to store information on the current status of the connection, e.g., the last byte sent.
    [Show full text]
  • A QUIC Implementation for Ns-3
    This paper has been submitted to WNS3 2019. Copyright may be transferred without notice. A QUIC Implementation for ns-3 Alvise De Biasio, Federico Chiariotti, Michele Polese, Andrea Zanella, Michele Zorzi Department of Information Engineering, University of Padova, Padova, Italy e-mail: {debiasio, chiariot, polesemi, zanella, zorzi}@dei.unipd.it ABSTRACT One of the most important novelties is QUIC, a transport pro- Quick UDP Internet Connections (QUIC) is a recently proposed tocol implemented at the application layer, originally proposed by transport protocol, currently being standardized by the Internet Google [8] and currently considered for standardization by the Engineering Task Force (IETF). It aims at overcoming some of the Internet Engineering Task Force (IETF) [6]. QUIC addresses some shortcomings of TCP, while maintaining the logic related to flow of the issues that currently affect transport protocols, and TCP in and congestion control, retransmissions and acknowledgments. It particular. First of all, it is designed to be deployed on top of UDP supports multiplexing of multiple application layer streams in the to avoid any issue with middleboxes in the network that do not same connection, a more refined selective acknowledgment scheme, forward packets from protocols other than TCP and/or UDP [12]. and low-latency connection establishment. It also integrates cryp- Moreover, unlike TCP, QUIC is not integrated in the kernel of the tographic functionalities in the protocol design. Moreover, QUIC is Operating Systems (OSs), but resides in user space, so that changes deployed at the application layer, and encapsulates its packets in in the protocol implementation will not require OS updates. Finally, UDP datagrams.
    [Show full text]
  • An Experimental Evaluation of Low Latency Congestion Control for Mmwave Links
    An Experimental Evaluation of Low Latency Congestion Control for mmWave Links Ashutosh Srivastava, Fraida Fund, Shivendra S. Panwar Department of Electrical and Computer Engineering, NYU Tandon School of Engineering Emails: fashusri, ffund, [email protected] Abstract—Applications that require extremely low latency are −40 expected to be a major driver of 5G and WLAN networks that −45 include millimeter wave (mmWave) links. However, mmWave −50 links can experience frequent, sudden changes in link capacity −55 due to obstructions in the signal path. These dramatic variations RSSI (dBm) in link capacity cause a temporary “bufferbloat” condition −60 0 25 50 75 100 during which delay may increase by a factor of 2-10. Low Time (s) latency congestion control protocols, which manage bufferbloat Fig. 1: Effect of human blocker on received signal strength of by minimizing queue occupancy, represent a potential solution a 60 GHz WLAN link. to this problem, however their behavior over links with dramatic variations in capacity is not well understood. In this paper, we explore the behavior of two major low latency congestion control protocols, TCP BBR and TCP Prague (as part of L4S), using link Link rate: 5 packets/ms traces collected over mmWave links under various conditions. 1ms queuing delay Our evaluation reveals potential problems associated with use of these congestion control protocols for low latency applications over mmWave links. Link rate: 1 packet/ms Index Terms—congestion control, low latency, millimeter wave 5ms queuing delay Fig. 2: Illustration of effect of variations in link capacity on I. INTRODUCTION queueing delay. Low latency applications are envisioned to play a significant role in the long-term growth and economic impact of 5G This effect is of great concern to low-delay applications, and future WLAN networks [1].
    [Show full text]
  • AQM Algorithms and Their Interaction with TCP Congestion Control Mechanisms
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Universidad Carlos III de Madrid e-Archivo Grado Universitario en Ingenier´ıaTelem´atica 2016/2017 Trabajo Fin de Grado Control de Congesti´onTCP y mecanismos AQM Sergio Maeso Jim´enez Tutor/es Celeste Campo V´azquez Carlos Garc´ıaRubio Legan´es,2 de Octubre de 2017 Esta obra se encuentra sujeta a la licencia Creative Commons Reconocimiento - No Comercial - Sin Obra Derivada Control de Congesti´onTCP y mecanismos AQM By Sergio Maeso Jim´enez Directed By Celeste Campo V´azquez Carlos Garc´ıaRubio A Dissertation Submitted to the Department of Telematic Engineering in Partial Fulfilment of the Requirements for the BACHELOR'S DEGREE IN TELEMATICS ENGINEERING Approved by the Supervising Committee: Chairman Marta Portela Garc´ıa Chair Carlos Alario Hoyos Secretary I~naki Ucar´ Marqu´es Deputy Javier Manuel Mu~noz Garc´ıa Grade: Legan´es,2 de Octubre de 2017 iii iv Acknowledgements I would like to thanks my tutors Celeste Campo and Carlos Garcia for all the support they gave me while I was doing this thesis with them. To my parents, who believe in me against all odds. v vi Abstract In recent years, the relevance of delay over throughput has been particularly emphasized. Nowadays our networks are getting more and more sensible to latency due to the proliferation of applications and services like VoIP, IPTV or online gaming where a low delay is essential for a proper performance and a good user experience. Most of this unnecessary delay is created by the misbehaviour of many buffers that populate Internet.
    [Show full text]
  • TCP Congestion Control with a Misbehaving Receiver
    TCP Congestion Control with a Misbehaving Receiver Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson Department of Computer Science and Engineering University of Washington, Seattle Abstract col modifications, a faulty or malicious receiver can at most cause the sender to transmit data at a slower rate than it otherwise would, In this paper, we explore the operation of TCP congestion control thus harming only itself. Because our work has serious practical when the receiver can misbehave, as might occur with a greedy ramifications for an Internet that depends on trust to avoid conges- Web client. We first demonstrate that there are simple attacks that tion collapse, we also describe backwards-compatible mechanisms allow a misbehaving receiver to drive a standard TCP sender ar- that can be implemented at the sender to mitigate the effects of un- bitrarily fast, without losing end-to-end reliability. These attacks trusted receivers. are widely applicable because they stem from the sender behavior As far as we are aware, the division of trust between sender specified in RFC 2581 rather than implementation bugs. We then and receiver has not been studied previously in the context of con- show that it is possible to modify TCP to eliminate this undesir- gestion control. While end-to-end congestion control protocols as- able behavior entirely, without requiring assumptions of any kind sume that both sender and receiver behave correctly, in many en- about receiver behavior. This is a strong result: with our solution vironments the interests of sender and receiver may differ consid- a receiver can only reduce the data transfer rate by misbehaving, erably – creating significant incentives to violate this “good faith” thereby eliminating the incentive to do so.
    [Show full text]
  • TCP-Friendly Congestion Control for Real-Time Streaming Applications
    MIT Technical Report MIT-LCS-TR-806, May 2000. TCP-friendly Congestion Control for Real-time Streaming Applications Deepak Bansal and Hari Balakrishnan M.I.T. Laboratory for Computer Science Cambridge, MA 02139 g Email: fbansal,hari @lcs.mit.edu Abstract ment in the Internet, however, the protocols used by these applications must implement congestion control algorithms This paper introduces and analyzes a class of nonlinear con- that are stable and interact well with TCP. Such protocols gestion control algorithms called binomial algorithms, moti- are called “TCP compatible” [3] or “TCP fair”. They ensure vated in part by the needs of streaming audio and video ap- that the TCP connections using AIMD get their fair allo- plications for which a drastic reduction in transmission rate cation of bandwidth in the presence of these protocols and upon congestion is problematic. Binomial algorithms gen- vice versa. One notion that has been proposed to capture eralize TCP-style additive-increase by increasing inversely “TCP compatibility” is “TCP-friendliness”. It is well known k proportional to a power of the current window (for TCP, that the throughput of a flow with TCP’s AIMD conges- k =¼ = ½ ) ; they generalize TCP-style multiplicative-decrease tion control (increase factor « packet, decrease factor Ô Ð =½=¾ Ô » Ë=´Ê Ôµ by decreasing proportional to a power of the current win- ¬ ) is related to its loss rate as ,where Ð = ½ dow (for TCP, ). We show that there are an infinite Ë is the packet size [19, 25, 10, 26]. An algorithm is TCP- Ô » Ë=´Ê Ôµ number of deployable TCP-friendly binomial algorithms, all friendly [20] if its throughput with the same · Ð =½ of which satisfy k , and that all binomial algorithms constant of proportionality as for a TCP connection with the converge to fairness under a synchronized-feedback assump- same packet size and round-trip time.
    [Show full text]
  • Better Throughput in TCP Congestion Control Algorithms on Manets
    (IJACSA) International Journal of Advanced Computer Science and Applications, Special Issue on Wireless & Mobile Networks Scalable TCP: Better Throughput in TCP Congestion Control Algorithms on MANETs M.Jehan Dr. G.Radhamani Associate Professor, Department of Computer Science, Professor & Director, Department of Computer Science, D.J.Academy for Managerial Excellence, Dr.G.R.Damodaran College of Science, Coimbatore, India Coimbatore, India Abstract—In the modern mobile communication world the This paper is entirely devoted to evaluating the Control congestion control algorithms role is vital to data transmission Window (cwnd), Round Trip Delay Time (rtt) and Throughput between mobile devices. It provides better and reliable using the TCP BIC, Vegas and Scalable TCP congestion communication capabilities in all kinds of networking control algorithms in the wireless networks. environment. The wireless networking technology and the new kind of requirements in communication systems needs some II. BACKGROUND WORK extensions to the original design of TCP for on coming technology development. This work aims to analyze some TCP congestion A. Congestion Control in Transmission Control Protocol control algorithms and their performance on Mobile Ad-hoc Algorithms Networks (MANET). More specifically, we describe performance TCP (Transmission Control Protocol) is a set of rules behavior of BIC, Vegas and Scalable TCP congestion control (protocol) used along with the Internet Protocol (IP) to send algorithms. The evaluation is simulated through Network data in the form of message units between computers over the Simulator (NS2) and the performance of these algorithms is Internet. It operates at a higher level, concerned only with the analyzed in the term of efficient data transmission in wireless and two end systems.
    [Show full text]
  • Copa: Practical Delay-Based Congestion Control for the Internet
    Copa: Practical Delay-Based Congestion Control for the Internet Venkat Arun and Hari Balakrishnan, MIT CSAIL https://www.usenix.org/conference/nsdi18/presentation/arun This paper is included in the Proceedings of the 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’18). April 9–11, 2018 • Renton, WA, USA ISBN 978-1-939133-01-4 Open access to the Proceedings of the 15th USENIX Symposium on Networked Systems Design and Implementation is sponsored by USENIX. Copa: Practical Delay-Based Congestion Control for the Internet Venkat Arun and Hari Balakrishnan M.I.T. Computer Science and Artificial Intelligence Laboratory Email: fvenkatar,[email protected] Abstract time or low interactive delay). Larger BDPs exacerbate This paper introduces Copa, an end-to-end conges- the \bufferbloat" problem. A more global Internet tion control algorithm that uses three ideas. First, it leads to flows with very different propagation delays sharing a bottleneck (exacerbating the RTT-unfairness shows that a target rate equal to 1=(ddq), where dq is the (measured) queueing delay, optimizes a natural func- exhibited by many current protocols). tion of throughput and delay under a Markovian packet At the same time, application providers and users arrival model. Second, it adjusts its congestion window have become far more sensitive to performance, with in the direction of this target rate, converging quickly to notions of \quality of experience" for real-time and the correct fair rates even in the face of significant flow streaming media, and various metrics to measure Web churn. These two ideas enable a group of Copa flows performance being developed.
    [Show full text]
  • Performance Analysis of Google Congestion Control Algorithm for Webrtc
    Performance Analysis of Google Congestion Control Algorithm for WebRTC M.L. Guerrero Viveros Performance Analysis of Google Congestion Control Algorithm for WebRTC by M.L. Guerrero Viveros in partial fulfilment of the requirements for the degree of Master of Science in Electrical Engineering Track Telecommunications and sensing systems at the Delft University of Technology, to be defended publicly on Thursday November 07, 2019 at 10:00 AM. Student number: 4736605 Project duration: January 1, 2019 – November 07, 2019 Thesis committee: Prof. dr. ir. P. Van Mieghem, TU Delft Dr. P. Pawelczak, TU Delft Ir. R. Noldus, Ericsson, supervisor This thesis is confidential and cannot be made public until November 07, 2019. An electronic version of this thesis is available at http://repository.tudelft.nl/. Abstract Web Real-Time communication (WebRTC) is a technology that enables web browsers to es- tablish real-time communication services without the need of specific software or plug-ins. This technology is gaining popularity and is already supported by popular browsers such as Google Chrome, Firefox and Safari. The quality of real-time communication services depends highly on latency. For this reason, real-time flows have different requirements than conven- tional TCP flows which focus mainly on the transfer of bulk traffic. The IETF created the working group RMCAT (RTP Media Congestion Avoidance Techniques) to define requirements for real-time congestion control algorithms. One of the proposed algorithms is Google Con- gestion Control (GCC). This is the only real-time congestion control algorithm implemented in commercial browsers such as Google Chrome. Unfortunately, the performance of GCC in wireless networks has not been extensively evaluated.
    [Show full text]
  • Techniques for End-To-End Tcp Performance Enhancement Over Wireless Networks
    University of Pennsylvania ScholarlyCommons Publicly Accessible Penn Dissertations 2016 Techniques for End-to-End Tcp Performance Enhancement Over Wireless Networks Bong Ho Kim University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/edissertations Part of the Computer Sciences Commons, and the Engineering Commons Recommended Citation Kim, Bong Ho, "Techniques for End-to-End Tcp Performance Enhancement Over Wireless Networks" (2016). Publicly Accessible Penn Dissertations. 1813. https://repository.upenn.edu/edissertations/1813 This paper is posted at ScholarlyCommons. https://repository.upenn.edu/edissertations/1813 For more information, please contact [email protected]. Techniques for End-to-End Tcp Performance Enhancement Over Wireless Networks Abstract Today’s wireless network complexity and the new applications from various user devices call for an in- depth understanding of the mutual performance impact of networks and applications. It includes understanding of the application traffic and network yla er protocols to enable end-to-end application performance enhancements over wireless networks. Although Transport Control Protocol (TCP) behavior over wireless networks is well known, it remains as one of the main drivers which may significantly impact the user experience through application performance as well as the network resource utilization, since more than 90% of the internet traffic usesCP T in both wireless and wire-line networks. In this dissertation, we employ application traffic measurement and packet analysis over a commercial Long Term Evolution (LTE) network combined with an in-depth LTE protocol simulation to identify three critical problems that may negatively affect the application performance and wireless network resource utilization: (i) impact of the wireless MAC protocol on the TCP throughput performance, (ii) impact of applications on network resource utilization, and (iii) impact of TCP on throughput performance over wireless networks.
    [Show full text]
  • Congestion Control Tuning of the QUIC Transport Layer Protocol Spring 2018
    Congestion Control Tuning of the QUIC Transport Layer Protocol Spring 2018 Wendi Qu Director: Llorenç Cerdà-Alabern Departament d'Arquitectura de Computadors Degree: Bachelor Specialization: Information Technologies Facultat d’Informatica de Barcelona (FIB) Universitat Politecnica de Catalunya (UPC) - BarcelonaTech April 2018 UNIVERSITAT POLITÈCNICA DE CATALUNYA (UPC) Abstract The QUIC protocol is a new type of reliable transmission protocol based on UDP. Its establishment is mainly to solve the problem of network delay. It is efficient, fast, and takes up less resources. The QUIC gathers the advantages of both TCP and UDP. The first part of this thesis studies the development background of the QUIC protocol in terms of characteristics and perspectives of what they can do and how they work. Because it adds the congestion control algorithm used by TCP based on the UDP protocol, we have conducted further research and analysis of the Cubic algorithm to investigate the impact of its parameters on the behavior. The second part includes performance and fairness tests for QUIC and TCP implementations. The simulation framework Mininet is used to perform these tests using controlled network properties. In this process we verified the reliability of the mininet. This work shows how Mininet builds a test system to analyze the implementation of the transport protocol. QUIC's tests show that the performance of QUIC has improved, and the test of fairness have identified specific areas that may require further analysis. In the third part, we test the influence of the parameter on the behavior of the algorithm in the congestion control algorithm. We present an initial experimental evaluation of the newly proposed Cubic-TCP algorithm.
    [Show full text]
  • Congestion Control
    What is congestion and why is it an important problem for CS 78 Computer Networks Internet? Congestion Control Andrew T. Campbell [email protected] How does the source Principles of Congestion Control determine congestion? Congestion: • informally: “too many sources sending too much data too fast for network to handle” • different from flow control! • manifestations: – lost packets (buffer overflow at routers) – long delays (queueing in router buffers) • Can be a serious problem Two approaches towards congestion Congestion Scenarios control - what’s the tradeoffs? H λ o s o u t t End-end congestion Network-assisted congestion A control control H o • routers provide feedback s • no explicit feedback t to end systems B from network – single bit indicating • congestion inferred congestion (SNA, from end-system DECbit, TCP/IP ECN, observed loss, delay ATM) • approach taken by TCP – explicit rate sender Another “cost” of congestion: should send at • when packet dropped, any “upstream transmission capacity used for that packet was wasted! 1 TCP’s end-to-end approach TCP congestion control: additive AIMD (Additive Increase, Multiplicative increase, multiplicative decrease Decrease) Algorithm • Approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs – additive increase: increase CongWin by 1 MSS every RTT until loss detected – multiplicative cdongeestcion rease: cut CongWin in half window after loss 24 Kbytes 16 Kbytes Saw tooth 8 Kbytes behavior: probing time for bandwidth time TCP Congestion
    [Show full text]