DOCSLIB.ORG

TCP Congestion Control and Its Variants

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
TCP Congestion Control and Its Variants Advances in Computational Sciences and Technology ISSN 0973-6107 Volume 10, Number 6 (2017) pp. 1715-1723 © Research India Publications http://www.ripublication.com TCP Congestion Control and Its Variants Harjinder Kaur and Dr. Gurpreet Singh* CSE, GZSCCET, MRSPTU, Dabwali Road, Bathinda, Punjab, India, *Corresponding author Abstract Transmission Control Protocol provides reliability and end to end delivery of packets in the network. TCP was designed to handle the congestion collapse problem of the network. TCP has various improved versions, which were created time to time as per necessities. In this paper we worked on different TCP variants for instance TCP Reno, TCP New Reno, TCP SACK, TCP FACK and TCP Vegas. We present a comparative analysis of TCP variants on the basis of different parameters. Keywords: Reno; NewReno; SACK; FACK; Vegas. 1. INTRODUCTION TCP (Transmission Control Protocol) is mostly used Internet Protocol. The main feature of TCP is that it can handle the congestion. When the packet sending rate is increased than the receiving rate then congestion arises. TCP provides the reliable and connection oriented network. To deals with congestion, TCP provides different variants for example:- TCP Tahoe, TCP Reno, TCP New Reno, TCP Vegas, TCP SACK, TCP FACK, TCP Asym, TCP RBP, Full TCP, CUBIC etc. In this paper we work on a few of them using the NS-2 . Network Simulator (NS-2) is used for research and teaching that is evaluated in 1989. These variants basically used three algorithms, slow start, congestion avoidance and Fast Retransmit. TCP Reno uses an additional mechanism, fast recovery. It directly enters in congestion avoidance and skips the slow start, because in fast recovery threshold value and the new congestion window (CWND) is set as CWND= 1/ Current CWND. TCP New Reno is an extension of the TCP Reno. It has the same features like Reno 1716 Harjinder Kaur and Dr. Gurpreet Singh but it also has an advantage over Reno, it does not leave the fast recovery until the acknowledgment (ACK) of all packets not received. TCP SACK provides selective acknowledgment. SACK can detect multiple packet loss. TCP Vegas is mainly focused on congestion avoidance rather than congestion detection. It introduced three new mechanisms: - New Retransmit mechanism, congestion avoidance and modified slow start. A very important variant known as TCP FACK is working on the top of SACK options. FACK is modified version of SACK that comes with various new features. Actually, all TCP variants work same, but they are used different mechanism in congestion handling. We can say that the performances of TCP variants are affected by its congestion control mechanism. 2. LITERATURE SURVEY Md. Shohidul Islam et al: - In this research paper author discuss the “TCP Variants and Network Parameters: A Comprehensive Performance Analysis”. This research shows how TCP versions respond to various network parameters like propagation delay, bandwidth, time to live, round trip time, rate of packets sending and so on. In this authors select the best version of TCP in each parameter. Such analysis is helpful in selecting the suitable TCP for certain criteria [10]. Yuvaraju B N and Dr. Niranjan N Chiplunkar: - This paper is on “Scenario Based Performance Analysis of Variants of TCP Using NS2 – Simulator”. It evaluates the performance of TCP Tahoe, TCP Reno, TCP New Reno, TCP SACK, TCP FACK and TCP Vegas under different scenarios. After analyzing the performance this research found that TCP Vegas is better than other TCP variants for sending data and information [9]. Neha Bathla et al: -“Estimating Performance of TCP Alternatives in Wireless Environment” this paper compares TCP variants on the basis of different parameters using AODV routing protocol on NS-2. After obtaining results, it shown that TCP Vegas have higher efficiency and better performance than other TCP variants [3]. Subramanya P et al: - This paper is on “Performance Evaluation of High Speed TCP Variants in Dumbbell Network” and it uses dumbbells network for calculating the performance of TCP variants. According to this paper the performance of TCP variants depends on the congestion in the network and TCP New Reno performs very well for congestion control [6] [18]. Abhishek Sawarkar and Himanshu Saraswat: - In this paper authors discuss “Performance Analysis of TCP variants”. It contains the three experiments in terms of throughput, latency and packet dropped ratio. In the first experiment TCP Vegas performs best whenever apply T-test, variance, mean and simulation analysis. According to second experiment when two flows use the same TCP variant both are fair to each other. But when in different flows they, are not fair to each other in terms of bandwidth utilization. In experiment three, uses the Droptail and RED to get better TCP Congestion Control and Its Variants 1717 both throughput and latency because throughput increases whenever using Droptail queuing algorithm and latency when the RED queuing algorithm uses [1]. 3. TCP VARIANTS 3.1. TCP Reno It was introduced in 1990 by Van Jacobson. It has the same features like TCP Tahoe. We can also represent it as follows:- TCP Tahoe + Fast Recovery = TCP Reno [5] Fig.2. Behavior of TCP Reno In TCP Reno when three duplicate packets are received, then it is the sign of congestion. If congestion occurs, then TCP Reno retransmits the packets and enters a new mechanism that is fast recovery. The following shows the algorithm for TCP Reno:- if (cwnd<ssthresh) cwnd = cwnd + 1 # slow start else if (cwnd>= ssthresh) cwnd = cwnd + 1/cwnd# congestion avoidance if (duplicate ACK) If (duplicate ACK = = (1 || 2)) cwnd = ssthresh #packet delayed/ out-of-packet received 1718 Harjinder Kaur and Dr. Gurpreet Singh ssthresh = cwnd/2 else (duplicate ACK > 2) cwnd = cwnd + Number (ACK) # packet loss due to congestion ssthresh = cwnd/2 The algorithm shows if cwnd (congestion window) is less than the threshold value (that is represented using variable ssthresh) then congestion window is increment by one otherwise it enters the slow start. As in algorithm shows if one or two acknowledgments are received, then threshold value is set half of the congestion window, but if more than two acknowledgments are received then it indicates the congestion. For each duplicate acknowledgment received increase congestion window by 1. TCP Reno has a limitation that, it can detect only single packet loss [2] [7]. 3.2. TCP New Reno TCP New Reno is the extension of TCP Reno. It has some advantages over TCP Reno that can detect the multiple packet loss and it does not leave the fast recovery until it receives acknowledgment of all packets, present in the window [15]. The fast recovery phase proceeds as in TCP Reno, when a fresh acknowledgment is received then there are two cases:- (i) If it acknowledges all the packets which are outstanding when entered fast recovery, then it exits fast recovery and set cwnd to ssthresh and still continues congestion avoidance. (ii) If the acknowledgment is an incomplete acknowledgement, then it deduces that the next packet in line was lost and it retransmits that packet and sets the number of duplicate acknowledgment received on 0 [14]. We have some advantages of TCP New Reno these are given below:- It can detect multiple packet loss. Its congestion avoidance mechanism is very efficient and utilizes network resources much more efficiently. TCP New Reno has few retransmits because of its modified congestion avoidance and slow start. 3.3. TCP SACK TCP SACK or selective acknowledgement requires that packets should acknowledge selectively. It is an option enabling a receiver to tell the sender the range of non- contiguous packets received. Without SACK, the receiver can only tell the sender about sequentially received packets. The sender uses this information to retransmit TCP Congestion Control and Its Variants 1719 selectively only the lost packets. It uses a variable pipe to store outstanding data in the network, which is absent in TCP Reno and New Reno [13] [16]. When pipe < cwnd, then it sends data and Set pipe = pipe + 1. However, when the sender receives an acknowledgement from receiver then set pipe = pipe – 1. In this manner, the sender transmits all of the outstanding data in the network. When all the outstanding packets are acknowledged, then SACK exits fast recovery and enters next phase that is congestion avoidance. Fig.3. Selectively acknowledge packets 3.4. TCP FACK The development of TCP SACK with Forward Acknowledgement is called TCP FACK. It has some extra features over TCP SACK, to estimate the amount of data transmit it uses SACK options very efficiently and it also introduces a better way to ½ the window when congestion is detected. The goal of FACK is to perform precise congestion control and improve connection throughput during the recovery phase [8] [12]. 1720 Harjinder Kaur and Dr. Gurpreet Singh 3.5. TCP Vegas According to above mentioned research papers TCP Vegas is better than the other TCP variants. Like Reno, Vegas uses triple duplicate acknowledgments always result in packet retransmission. TCP Vegas introduced a new retransmission mechanism for lost packets. It uses fine-grained round trip time measurements for a compute timeout period of each packet [14]. If the timeout period of the oldest unacknowledgement packets has expired then, packet is retransmitted. Fine-grain timeouts enables faster detection of packet losses and recovery from multiple drops without restarting the slow start phase if the retransmission timer does not expire before. Thus, it solves the problem of multiple packet drops in the same window that we faced in TCP Reno. TCP Vegas also provide modified slow start and congestion avoidance. The original slow start and congestion avoidance need packet losses to realize the congestion, but the modified slow start finds the correct window size without incurring a loss.
Load more

Recommended publications
  • Modeling and Performance Evaluation of LTE Networks with Different TCP Variants Ghassan A
    World Academy of Science, Engineering and Technology International Journal of Electronics and Communication Engineering Vol:5, No:3, 2011 Modeling and Performance Evaluation of LTE Networks with Different TCP Variants Ghassan A. Abed, Mahamod Ismail, and Kasmiran Jumari Abstract—Long Term Evolution (LTE) is a 4G wireless Comparing the performance of 3G and its evolution to LTE, broadband technology developed by the Third Generation LTE does not offer anything unique to improve spectral Partnership Project (3GPP) release 8, and it's represent the efficiency, i.e. bps/Hz. LTE improves system performance by competitiveness of Universal Mobile Telecommunications System using wider bandwidths if the spectrum is available [2]. (UMTS) for the next 10 years and beyond. The concepts for LTE systems have been introduced in 3GPP release 8, with objective of Universal Terrestrial Radio Access Network Long-Term high-data-rate, low-latency and packet-optimized radio access Evolution (UTRAN LTE), also known as Evolved UTRAN technology. In this paper, performance of different TCP variants (EUTRAN) is a new radio access technology proposed by the during LTE network investigated. The performance of TCP over 3GPP to provide a very smooth migration towards fourth LTE is affected mostly by the links of the wired network and total generation (4G) network [3]. EUTRAN is a system currently bandwidth available at the serving base station. This paper describes under development within 3GPP. LTE systems is under an NS-2 based simulation analysis of TCP-Vegas, TCP-Tahoe, TCP- Reno, TCP-Newreno, TCP-SACK, and TCP-FACK, with full developments now, and the TCP protocol is the most widely modeling of all traffics of LTE system.
    [Show full text]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]