- FLOWER Fuzzy Lower-than-Best-Effort Transport (...)
- An architecture to support explicit rate (...)
- Multipath Networking at Transport Layer
- DQN : DTN-routing over Quasi-Deterministic (...)
- New transport protocols for DTN and satellites
- STAMP : Server Topologic Analysis by Message (...)
- FavourQueue : a Stateless Active Queue (...)
- Chameleon Protocol
- TCED : TCP Congestion Event Detection (...)
- Traffic measurements
- DCCP for FreeBSD 6.1
Among the different transport protocols providing a LBE service, Low Extra Delay Background Transport (LEDBAT) is the most used. LEDBAT is a delay-based congestion control protocol that has been standardized by the Internet Engineering Task Force (IETF). LEDBAT aims to exploit the remaining capacity while limiting the queuing delay around a predefined target which may be set up to 100 ms according to RFC 6817. Consequently, LEDBAT flows limits the amount of queuing delay introduced in the network and thus lower their impact on best-effort flows such as TCP. Despite being a widely deployed protocol, the two main LEDBAT parameters (i.e., target and gain) have been revealed to be complex to determine as their tuning highly depends on the network conditions and not dynamically configurable. Indeed, LEDBAT may become more aggressive than TCP in case of misconfiguration.
Our protocol, FLOWER (Fuzzy LOWer-than-Best-EffoRt Transport Protocol), is a promising alternative of LEDBAT. With FLOWER, we aim to overcome the LEDBAT shortcomings while still fulfilling its goals. The principal difference with LEDBAT is that FLOWER replaces the linear P-type controller (proportional controller) of LEDBAT by a fuzzy controller to modulate the congestion window.
FLOWER code is based on LEDBAT and TCP Vegas ns-2 implementations and is available for ns-2 and GNU/Linux here :
This project proposes an architecture, called IP-ERN, which allows Explicit Rate Notification (ERN) protocols to be inter-operable with current IP-based networks. IP-ERN is based on the execution of both End-to-End (E2E) and ERN protocols at the end hosts. The resulting E2E-ERN protocol provides inter and intra protocol fairness and benefits from all ERN advantages when possible. We detail the principle of this novel architecture, which is compliant with every TCP feature, as well as IP-in-IP tunneling solutions. In particular, IP-ERN is an alternative to splitting Performance Enhancement Proxies.
- An architecture to support explicit rate signaling over End-to-End paths
- SatERN : a PEP-less solution for satellite communications
- Towards an incremental deployment of ERN protocols : a proposal for an E2E-ERN hybrid protocol
Conjointly with NICTA, we used to explore multipath transport protocols capabilities and in particular, we investigated possible enhancements in the CMT-SCTP protocol. This work is a part of the thesis of Golam Sarwar and a presentation of the thesis work is given in these slides.
This project proposed a novel DTN routing algorithm, called DQN, specifically designed for quasi-deterministic networks with an application to satellite constellations. A first study has demonstrated that DQN efficiently forwards the information over a satellite network derived from the Orbcomm topology while keeping a low replication overhead compare to all other well-known DTN routing schemes. This work has been done in the context of the PhD thesis of Rémi Diana. Check our publications for further details.
This work aims at studying DCCP/CCID3 and DCCP/CCID4 enhancements to efficiently carry out multimedia streaming and VoIP over long-delay links. This work is done in collaboration with NICTA. Together we are proposing new algorithms in order to fit media characteristics with application requirements. In a last work, we have proposed a solution to mitigate the performance degradation and corresponding Quality of Experience (QoE) reduction caused by packet reordering for multimedia applications which utilise unreliable transport protocols like the Datagram Congestion Control Protocol (DCCP). We have proposed a dynamically adjustable buffer in the transport protocol receiver which uses this optimum buffer size and demonstrated that our solution reduces the packet loss rate, increases the perceived bandwidth and does not increase jitter in the received applications packets while still being within the application’s delay limits, therefore resulting in an increased QoE of multimedia applications.
STAMP builds a weight and oriented graph from an email database, an email log or just a simple email header, that allows to analyse email paths. The objective of this tool is to automatically perform an analysis of the SMTP topology. As an extension, the returned graph might help to develop methods (from graph theory, statistical analysis, ...) to identifying problems occurred. For further details please read this.
STAMP code is available here :
The version of P-XCP ns-2 code of our paper Optimal Configuration for Satellite PEPs using a Reliable Service on Top of a Routers-Assisted Approach has been realized by Dino Lopez during his post-doc at ISAE and following this seminal paper : "P-XCP : A Transport Layer Protocol for Satellite IP Networks", Kaiyu Zhou et A., IEEE GLOBECOM 2004.
To install P-XCP inside your ns-2 simulator, replace tcp-newreno.cc, tcp-reno.cc, xcp-end-sys.cc, xcp-end-sys.h, xcp.cc, xcp.h, xcpq.cc, xcpq.h with the files provided here :
This code has been successfully tested with ns2.33.
FavourQueue is a novel active queue management (AQM) that aims to improve delay transfer of short lived TCP flows over a best-effort network. The idea is to dequeue in first packets that do not belong to a flow previously enqueued. The rationale is to mitigate the delay induced by long-lived TCP flows over the pace of short TCP data requests and to prevent dropped packets at the beginning of a connection and during recovery period. Although the main target of this AQM is to accelerate short TCP traffic, we have shown that FavourQueue does not only improve the performance of short TCP traffic but also improve the performance of all TCP traffic in terms of drop ratio and latency whatever the flow size. In particular, we have demonstrated that FavourQueue reduces the loss of a retransmitted packet, decrease the RTO recovery ratio and improves the latency up to 30% compared to DropTail.
The ns-2 code of our paper is available upon request.
Chameleon project aims at designing a reliable transport protocol based on the composition of the TCP-Friendly Rate congestion Control (TFRC) and the Selective ACKnowledgement (SACK) mechanism enhanced by cross-layer capabilities. See the Chameleon project webpage and our paper for details.
The ns-2 code is available here :
TCED is a graphical tool analysis for TCP connections. TCED allows the identification of TCP Congestion Event for metrology purpose such as TCP protocol behaviour analysis. The philosophy of TCED is somehow different from others existing softwares such as Tstat or TFStat in the way where TCED is not a TCP losses estimation tool. A Congestion Event is defined as a set of losses occurring on a TCP window which involves a TCP congestion adaptation (i.e. a decrease of the current sending window). TCED proposes a method (based on the LEAST (Mark Allman) and Benko-Veres algorithms) able to identify a congestion event at the border of an autonomous system. TCED can also be used to detect retransmissions, losses and congestion events of many flow. Check the TCED webpage for more details.
The ns-2 code of our paper Managing Congestion with a Kohonen-RED Queue is available here :
TSW-estimator gives a throughput estimation (based on the Time Sliding Window algorithm) of a TCP flow. The measured flow is identified by its destination port. You need libpcap in order to compile the code. The following version is *BSD compliant and is avaliable here :
You can find below two patches in order to use DCCP in FreeBSD 6.1 kernel. Both kernel patches are based on the FreeBSD implementation from Lulea University. The first one is an update of the original Lulea’s implementation : freebsd61-dccp-lulea-28.08.2006.patch. The second one integrates enhancements of Yoshifumi Nishida from Kame project : freebsd61-dccp-kame-28.08.2006.patch. The kame patch integrates only the code of CCID3 (from the dccp_tfrc.* files).
My contribution deals with the core DCCP stack (dccp_usrreq.c file) which has been rewritten to be conform with the FreeBSD6.1 kernel. To apply a patch, simply cd /usr/src and patch < freebsd61-dccp-XXXX-28.08.2006.patch. Look at the FreeBSD doc to rebuild the kernel. If you want to use it, you can generate traffic with the following DCCP traffic generator :
I got some problems with the Kame CCID3 code. So I try to integrate step by step the corrections of Yoshifumi and look at the Ian McDonald’s web page for the last enhancements.
If you want to test gTFRC mechanism, this following patch based on Lulea implementation contained it : freebsd61-gtfrc-dccp-lulea-01.09.2006.patch. (Special thanks to Sebastien Ardon) To use it, you need to add in the DCCP traffic generator this setsockopt option : setsockopt(socket, IPPROTO_DCCP, DCCP_GTFRC, &optval, sizeof(optval)) ;
All these patches are available here :
This work has been done at the National ICT Australia Ltd, NPC laboratory.