Retour au site du LAAS-CNRS

Abstract

Routers-assisted congestion control protocols, also known as Explicit Rate Notification (ERN) protocols, implement complex algorithms inside a router in order to provide both high link utilization and high fairness. Thus, routers-assisted approaches overcome most of the end-to-end protocols problems in large bandwidth-delay product networks. Today, routersassisted protocols cannot be deployed in heterogeneous networks (e.g., Internet) due to their non-compliance with current network protocols. Nevertheless, these approaches can be deployed in satellite networks in the context of splitting PEPs. In this work, as routers-assisted protocols can use TCP algorithms to enable reliability, we aim at understanding and providing a detailed view of the impact of such algorithms on the performance obtained by routers-assisted protocols over satellite links. In particular, we both study XCP and P-XCP proposals over long delay, lossy and asymmetric links and propose a ns-2 implementation of the P-XCP protocol to the satellite community. To the best of our knowledge, this study is the first one which tackles the impact of TCP internal mechanisms on top of XCP protocol. Our main conclusion is that TCP New Reno Slow But Steady variant on top of P-XCP is to date, the most optimal configuration for satellite proxies.

Abstract

TFRC protocol has not been designed to enable reliability. Indeed, the birth of TFRC results from the need of a congestion controlled and realtime transport protocol in order to carry multimedia traffic. Historically, and following the anarchical deployment of congestion control mechanisms implemented on top of UDP protocol, the IETF decided to standardize such protocol in order to provide to multimedia applications developers a framework for their applications. In this paper, we propose to design a reliable rate-based transport protocol based on TFRC. This design is motivated by finding an alternative to TCP where its oscillating behaviour is known to be counterproductive over certain networks such as VANET. However, we found interesting results partly inherited from the smooth behaviour of TFRC in the context of wired networks. In particular, we show that TFRC can realize shorter data transfer compare to TCP over a complex and realistic topology. We firstly detail and fully benchmark our protocol in order to verify that our resulting prototype inherits from the good properties of TFRC in terms of TCP-friendliness. As a second contribution, we also propose a ns-2 implementation for testing purpose to the networking community. Following these preliminary tests, we drive a set of non-exhaustive experiments to illustrate some interesting behaviour of this protocol in the context of wired networks.

Abstract

TFRC is a transport protocol specifically designed to carry multimedia streams. TFRC does not enable a reliable and in order data delivery services. However TFRC implements a congestion control algorithm which is friendly with TCP. This congestion control relies in a feedback mechanism allowing receivers to communicate to the senders an experienced drop rate. Although the current TFRC RFC states that there is little gain from sending a large number of feedback messages per RTT, recent studies have shown that in long-delay contexts, such as satellite-based networks, the performance of TFRC can be improved by increasing the feedback frequency. Nevertheless, currently it is not clear how and why this increase may improve the performance of TFRC. Therefore, in this paper, we aim at understanding the impact that multiple feedback per RTT may have (i) on the key parameters of TFRC (RTT and error rate) and (ii) on the network parameters (reactiveness, fairness and link utilization). We also provide a detailed description of the micromechanisms at the origin of the improvements of the TFRC behavior when multiple feedback per RTT are delivered, and determine the context where such feedback frequencies should be applied.

Abstract

We present experimental results for the performance of selected voice codecs using the Datagram Congestion Control Protocol (DCCP) with TCP-Friendly Rate Control (TFRC) congestion control mechanism over a satellite link. We evaluate the performance of both constant and variable data rate speech codecs (G.729, G.711 and Speex) for a number of simultaneous calls, using the ITU E-model and identify problem areas and potential for improvement. Our experiments are done on a commercial satellite service using a data stream generated by a VoIP application, configured with selected voice codecs and using the DCCP/CCID4 Linux implementation. We analyse the sources of packet losses which are a main contributor to reduced voice quality when using CCID4 and additionally analyse the effect of jitter which is one of the crucial parameters contributing to VoIP quality and has, to the best of our knowledge, not been considered previously in the published DCCP performance results. We propose modifications to the CCID4 algorithm and demonstrate how these improve the VoIP performance, without the need for additional link information other than what is already monitored by CCID4 (which is the case for Quick-Start). We also demonstrate the fairness of the proposed modifications to other flows. We identify the additional benefit of DCCP when used in VoIP admission control mechanisms and draw conclusions about the advantages and disadvantages of the proposed DCCP/ CCID4 congestion control mechanism for use with VoIP applications.

Abstract

Since the proposition of quality of service (QoS) architectures by the Internet Engineering Task Force (IETF), the interaction between TCP and the QoS services has been intensively studied. This paper proposes to look forward to the results obtained in terms of TCP throughput guarantee in the DiffServ assured forwarding (DiffServ/AF) service and to present an overview of the different proposals to solve the problem. It has been demonstrated that the standardized IETF DiffServ conditioners such as the token bucket color marker and the time sliding window color maker were not good TCP traffic descriptors. Starting with this point, several propositions have been made, and most of them present new marking schemes in order to replace or improve the traditional token bucket color marker. The main problem is that TCP congestion control is not designed to work with the AF service. Indeed, both mechanisms are antagonists. TCP has the property to share in a fair manner the bottleneck bandwidth between flows while DiffServ network provides a level of service that is controllable and predictable. In this paper, we build a classification of all the propositions made during the past few years and compare them. As a result, we will see that these conditioning schemes can be separated into three sets of action levels and that the conditioning at the network edge level is the most accepted one. We conclude that the problem is still unsolved and that TCP, conditioned or not conditioned, remains inappropriate for the DiffServ/AF service.

Mots-Clés / Keywords

Abstract

We propose modifications in the TCP-Friendly Rate Control (TFRC) congestion control mechanism from the Datagram Congestion Control Protocol (DCCP) intended for use with real-time traffic, which are aimed at improving its performance for long delay (primarily satellite) links. Firstly, we propose an algorithm to optimise the number of feedback messages per round trip time (RTT) rather than use the currently standard of at least one per RTT, based on the observed link delay. We analyse the improvements achievable with proposed modification in different phases of congestion control and present results from simulations with modified ns-2 DCCP and live experiments using the modified DCCP Linux kernel implementation. We demonstrate that the changes results in improved slow start performance and a reduced data loss compared to standard DCCP, while the introduced overhead remains acceptable.