Michael Welzl

MulTFRC: providing weighted fairness for multimediaapplications (and others too!)

Dragana Damjanovic and Michael Welzl
Appears in: 
CCR July 2009

When data transfers to or from a host happen in parallel, users do not always consider them to have the same importance. Ideally, a transport protocol should therefore allow its users to manipulate the fairness among ows in an almost arbitrary fashion. Since data transfers can also include real-time media streams which need to keep delay - and hence buffers - small, the protocol should also have a smooth sending rate. In an effort to satisfy the above requirements, we present MulTFRC, a congestion control mechanism which is based on the TCP-friendly Rate Control (TFRC) protocol.

Public Review By: 
Darryl Veitch

This paper extends the derivation underlying the TCP Friendly Rate Control (TFRC) equation, resulting in a tunable version, ‘MulTFRC,’ capable of computing the appropriate TCP-friendly data rate of a flow that matches the throughput of N TCP flows.
Instead of naively multiplying the TFRC rate by the number of parallel streams being emulated, the scheme implicitly estimates the loss event rate that each flow would have received individually.
Much as MulTCP does for TCP, there are benefits to incorporating parallel TCP connections ‘natively,’ rather than actually running separate connections in parallel, including reduced overhead at the transport and application layers, and avoiding potentially nasty and variability inducing `self competition'.
Although the ideas in this paper are natural extensions of the existing literature rather than truly groundbreaking, this is work that seems like it `should' be done, and the authors have provided some convincing simulation and data-based evidence that the scheme works as one might hope. In particular they showed that its sending rate is quite smooth, and insensitive to the value of the tuning parameter N. A nice feature is that the N is not limited to integer values and can even be less than one, allowing for flexible use, and very friendly flows indeed.

An independent H-TCP implementation under FreeBSD 7.0: description and observed behaviour

Grenville Armitage, Lawrence Stewart, Michael Welzl, and James Healy
Appears in: 
CCR July 2008

A key requirement for IETF recognition of new TCP algorithms is having an independent, interoperable implementation. This paper describes our BSD-licensed implementation of H-TCP within FreeBSD 7.0, publicly available as a dynamically loadable kernel module. Based on our implementation experience we provide a summary description of the H-TCP algorithm to assist other groups build further interoperable implementations.

Public Review By: 
Jithendra Padye

In this paper the authors detail their experiences implementing H-TCP in FreeBSD 7.0.
Needless to say, the subject matter is not novel. Yet, the reviewers felt that the research community should encourage this type of work. Independent implementations and evaluations of proposed standards, while not glamorous, are vitally needed to ensure that new standards are specified correctly and work as promised under realistic conditions.
To recognize a new TCP variant, IETF requires an independent, interoperable implementation of the proposed variant. The authors go through the exercise of implementing H-TCP by looking only at the published standard.
The authors were generally successful in their endeavor, which is a testimony to the completeness of the H-TCP standard. But they had to contact the authors of the standard to obtain some clarifications, and some open issues remained (see sections 5.1 and 5.6), which is a testimony to the difficulty of translating a standard into an implementation.
Interoperability with other implementations and legacy code is a major concern for many IETF proposals. However, this is not a major concern for HTCP implementations since there is no change to any packet formats, or the basic TCP state machine.
Instead, the important question is what impact HTCP flows have on performance of other high-speed TCP flows and standard NewReno TCP flows. While this paper does offer some results to that effect, addressing this issue is not the main thrust of this paper.
In terms of results, the reviewers felt that a head-to-head comparison with another H-TCP implementation (perhaps one from the Hamilton institute) would have been very useful. Unfortunately, the paper does not include such a comparison. Instead, the authors focus on comparing H-TCP performance with NewReno, which has already been studied by others.

Syndicate content