\theTitle \tnoteref{label1}
Olivier Mehani
We present enhancements to the TCP-Friendly Rate Control mechanism (TFRC) designed to better handle the intermittent connectivity occurring in mobility situations. Our aim is to quickly adapt to new network conditions and better support real-time applications for which the user-perceived quality depends on the immediate transmission rate. We propose to suspend the transmission before disconnections occur, in a way inspired by Freeze-TCP, and extend the solution by probing the network after reconnecting to enable full use of the newly available capacity. We first introduce a numerical model of TFRC's performance after a network handover and use it to evaluate the potential performance gains for realistic network parameters. We then describe a set of additions to TFRC to achieve these gains. Implementations within the Datagram Congestion Control Protocol (DCCP) for \ns-2 and Linux have been adapted to support these enhancements. Comparisons of experimental results for the original and modified DCCP are presented for a number of example mobility scenarios. We thus show how the proposed modifications enable faster recovery after disconnected periods as well as significantly improved adjustments to the newly available network conditions and an improvement in the quality of experience (QoE) for video-streaming applications.
2012mehani_rate_control_heterogeneous_handovers.tex
%% $Id: 2012mehani_rate_control_heterogeneous_handovers.tex 3535 2012-11-08 06:35:13Z omehani $
%\documentclass[peerreview,onecolumn,12pt]{IEEEtran} %IEEEtran
%\documentclass{IEEEtran}
%\documentclass[preprint,12pt,review]{elsarticle} %elsarticle
%\documentclass[final,5p,times,twocolumn]{elsarticle}
\documentclass[twocolumn]{nictatechreport} %techreport

% Comment all
 %s/^\([^%].*\(%IEEEtran\|%elsarticle\|%techreport\)\+\)$/%\1/

% Selectively uncomment
 %s/^%\(.*%IEEEtran\)/\1/
 %s/^%\(.*%elsarticle\)/\1/
 %s/^%\(.*%techreport\)/\1/

\newcommand{\theTitle}{Rate Control Adaptation for Heterogeneous Handovers}
\newcommand{\theAuthor}{Olivier Mehani, Roksana Boreli, Guillaume Jourjon and Thierry Ersnt}
\newcommand{\theKeywords}{TFRC, congestion control, vertical handover, cross-layer, DCCP, transport protocol}

\usepackage[pdftex, unicode, pdfstartview=FitV,
  colorlinks=true, linkcolor=black, citecolor=black, urlcolor=blue,
  pdftitle={\theTitle}, pdfauthor={\theAuthor}, pdfkeywords={\theKeywords}]{hyperref}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc} \usepackage{aeguill}

\usepackage{amssymb}

\usepackage{graphicx} \DeclareGraphicsRule{*}{pdf}{*}{}
\usepackage{mathtools}
\usepackage{booktabs}
\usepackage{multirow}
\usepackage{slashbox}
\usepackage{subfig}
\usepackage{textcomp}
\usepackage{colortbl}
\usepackage{xcolor}
\usepackage[style=ieee,backend=bibtex]{biblatex} \addbibresource{2012mehani_rate_control_heterogeneous_handovers.bib} %%IEEEtran%techreport
\usepackage{verbatim} % for the comment environment

\def\texturl{\begingroup\catcode`\:=11\relax\texturL}
\def\texturL#1{\texttt{\url{#1}}\endgroup}
%\newcommand{\email}[2]{\texttt{\href{mailto:#1}{#1}}} %IEEEtran%elsarticle

\newcommand{\fixme}[1]{\fbox{#1}}

\newcommand{\latinlocution}[1]{\textit{#1}}
\newcommand{\eg}{\latinlocution{e.g.}}
\newcommand{\ie}{\latinlocution{i.e.}}
%\newcommand{\apriori}{\latinlocution{a priori}}
%\newcommand{\aposteriori}{\latinlocution{a posteriori}}
%\newcommand{\adhoc}{\latinlocution{ad hoc}}
\newcommand{\perse}{\latinlocution{per se}}

\newcommand{\sysfun}[1]{\texttt{#1}}
\newcommand{\sysvar}[1]{\texttt{#1}}
\newcommand{\rwnd}{\sysvar{rwnd}}
\newcommand{\cwnd}{\sysvar{cwnd}}
\newcommand{\ssthresh}{\sysvar{ssthresh}}

\newcommand{\ns}{\textit{ns}}

%\journal{Computer Communications} %elsarticle


\begin{document}

%\begin{frontmatter} %elsarticle

%\title{\theTitle \tnoteref{label1}} %elsarticle
%\tnotetext[label1]{Parts of this article have been published at ACM MobiArch 2009} %elsarticle
\title{\theTitle} %IEEEtran%techreport
 
%\author[label2]{Olivier Mehani} \ead{olivier.mehani@nicta.com.au} %elsarticle
%\author[label2,label3]{Roksana Boreli}\ead{roksana.boreli@nicta.com.au} %elsarticle
%\author[label2]{Guillaume Jourjon}\ead{guillaume.jourjon@nicta.com.au} %elsarticle
%\author[label4,label5]{Thierry Ernst}\ead{thierry.ernst@inria.fr} %elsarticle
%\address[label2]{NICTA, Sydney, NSW, Australia} %elsarticle
%\address[label3]{University of New South Wales, Sydney, NSW, Australia} %elsarticle
%\address[label4]{Mines ParisTech, France,} %elsarticle
%\address[label5]{Inria, Imara Project-Team, France} %elsarticle

%\author{Olivier Mehani, \IEEEmembership{Member,~IEEE,} Roksana Boreli, Guillaume Jourjon and Thierry Ernst% %IEEEtran
%\thanks{O. Mehani, G. Jourjon and R. Boreli are with Nicta; R. Boreli is also with the University of New South Wales; T. Ernst is with Mines ParisTech and Inria.}} %IEEEtran

\author{Olivier Mehani,\textsuperscript{1,$\star$} Roksana Boreli\textsuperscript{1,2} %techreport
Guillaume Jourjon,\textsuperscript{1} and Thierry Ernst\textsuperscript{3,4}}  %techreport
\affiliation{$^\star$Corresponding author: \email{olivier.mehani@nicta.com.au}\\ %techreport
\textsuperscript1Nicta, Sydney. Eveleigh, NSW, Australia, \email{first.last@nicta.com.au} \\ %techreport
\textsuperscript2University of New South Wales, Sydney, Australia \\ %techreport
\textsuperscript3Mines ParisTech, Paris, France \\ %techreport
\textsuperscript4Inria, Rocquencourt, Paris, France, \email{thierry.ernst@inria.fr}} %techreport

%\submitdate{8 November 2012 to \textit{Computer Communications} (extended version)} %techreport
\reportnumber{6163} %techreport

%\maketitle %IEEEtran

\frontmatter %techreport
\begin{abstract}

We present enhancements to the TCP-Friendly Rate Control mechanism (TFRC)
designed to better handle the intermittent connectivity occurring in mobility
situations. Our aim is to quickly adapt to new network conditions and better
support real-time applications for which the user-perceived quality depends on
the immediate transmission rate. We propose to suspend the transmission before
disconnections occur, in a way inspired by Freeze-TCP, and extend the solution by
probing the network after reconnecting to enable full use of the newly available
capacity.

We first introduce a numerical model of TFRC's performance after a network
handover and use it to evaluate the potential performance gains for realistic
network parameters.  We then describe a set of additions to TFRC to achieve
these gains.  Implementations within the Datagram Congestion Control Protocol
(DCCP) for \ns-2 and Linux have been adapted to support these enhancements.
Comparisons of experimental results for the original and modified DCCP are
presented for a number of example mobility scenarios.

We thus show how the proposed modifications enable faster recovery after
disconnected periods as well as significantly improved adjustments to the newly
available network conditions and an improvement in the quality of experience
(QoE) for video-streaming applications.

\end{abstract}

\begin{keyword} %elsarticle%techreport
%\newcommand{\sep}{} %IEEEtran
%\begin{keywords} %IEEEtran
TFRC\sep congestion control \sep vertical handover \sep cross-layer \sep DCCP
\sep transport protocol

%\MSC 20.010 \sep 20.070 \sep 20.100 %els article

%\end{keywords} %IEEEtran
\end{keyword} %elsarticle%techreport


%\IEEEpeerreviewmaketitle %IEEEtran

%\end{frontmatter} %elsarticle
\mainmatter %techreport

\section{Introduction}
\label{sec:intro}

In recent years, there has been a shift towards increased use of mobile devices
for Internet access and the use of real-time applications such as multimedia
streaming, VoIP and video conferencing in mobile environments.  This has been in
line with the increased capacity and widespread coverage of wireless
technologies, primarily cellular mobile (3--4G) and Wi-Fi. The vast majority of
today's mobile devices, in fact, include both 3G and Wi-Fi access options.
Mobility support for moving between either the same technology (horizontal
handovers) or cross-technology networks (vertical handovers) is supported by
technologies such as Mobile IP~\cite{rfc6275}.  However, the supporting
transport protocols used for the emerging applications are still those
which carried traffic for wired devices.

In this work, we consider \emph{break-before-make} (also sometimes called
\emph{hard}) handovers between networks with heterogeneous characteristics. In
our generic scenario,
%
depicted in \figurename~\ref{fig:heterogeneous}, %techreport
%
a wireless mobile node (MN) moves between two or more networks while having
established sessions with fixed correspondent nodes (CN) in the Internet. The
handover can be between two access points of the same technology, that is,
\emph{horizontal}, or \emph{vertical}, between heterogeneous wireless networks
such as 3G to Wi-Fi.  Even though network mobility schemes hide most of the
complexity of roaming from the upper layers, cross-technology handovers usually
result in short, predictable disconnections during which network packets are
bound to be lost. As most available congestion control mechanisms interpret such
losses as an indication of congestion, they do not adapt
well~\cite{2002tsaoussidis_tcp_mobility_open_issues}.

%\begin{comment} %IEEEtran%elsarticle
\begin{figure}[hb] %techreport
  \centering 
  \resizebox{.85\columnwidth}{!}{\input{heterogeneous.pdftex_t}}
  
  \caption[Generic use-case scenario]{Generic use-case scenario: vertical hand
  overs between a number of access networks with different characteristics.}

  \label{fig:heterogeneous}
\end{figure} %techreport
%\end{comment} %IEEEtran%elsarticle

UDP is currently often used to carry real-time traffic. As it does not provide
congestion control, it is not subject to this type of problem. However, it is
argued in~\cite{1999floyd_end2end_congestion_control} that congestion control
mechanisms should always be used in a shared internet.  TCP is not a viable
option for this type of content as retransmitted packets may already have gone
past their usefulness deadline by the time they reach the receiver.  To bridge
this gap, the Datagram Congestion Control Protocol
(DCCP)~\cite{2006kohler_dccp,rfc4340} has been proposed as a non-reliable but
congestion-aware transport protocol. DCCP can make use of the TCP-Friendly Rate
Control mechanism
(TFRC)~\cite{2000floyd_equation-based_unicast,2003widmer_equation-based_unicast_multicast,rfc5348},
which replicates TCP's response to adjust to the network capacity.  As it mimics
TCP's congestion control response, TFRC experiences similar
problems~\cite{2004gurtov_tfrc_vertical_handovers}.

In this article, we study the behaviour of TFRC over heterogeneous handovers and
propose mobility-aware enhancements.  We first analytically model the effects of
handovers on TFRC in order to quantitatively derive the potential for
improvement. This model details a complete handover and allows to evaluate the
number of lost packets during the disconnection to estimate the under-usage of
the newly available network capacity after the reconnection. It is validated
through \ns-2 simulations.  We then present an end-to-end solution to better
cope with such events.  This solution results in the extension of the TFRC
protocol which we implement and evaluate both in \ns-2 simulations, and
experiments using our Linux code. 

Some other solutions to the handover problem have been proposed in the
literature. However, to the best of our knowledge, no fully integrated solution
handles changes in the path characteristics after a ``lossy'' handover.  Our
disconnection-tolerant modification of TFRC shares similarities in concept with
Freeze-TCP~\cite{2000goff_freezetcp} but has different target applications and
introduces further enhancements.  This solution also relies on explicit handover
notifications (in a way similar
to~\cite{2006montavont_mipv6_link-network_interaction} on link triggers) to be
informed of mobility events, but the end-to-end path characteristics are then
discovered uniquely at the transport layer.

The main benefits of our proposal include preventing unnecessary rate reductions
by the transport protocol, both by avoiding false congestion detection and
adapting faster to the newly available capacity after vertical or horizontal
handovers. The proposal also enables either side of the connection to suspend
traffic entirely for the duration of the handovers. Thus, the resulting
Freeze-DCCP/TFRC is a disconnection-tolerant congestion-controlled protocol for
datagrams. The use of standard header fields and options makes our proposal
backward compatible with existing implementations of DCCP. 

Our Linux implementation allows us to show that this solution is well suited for
real-time traffic while coping with heterogeneous mobile handovers with
predictable disconnections.  In particular, we focus on the quality of
experience (QoE)~\cite{2008kilkki_qoe} in the form of PSNR~\cite{2001ansi_psnr}
for video streaming. This performance evaluation has been done over an
OMF-enabled testbed~\cite{2010rakotoarivelo_omf}, allowing for reproducibility
and verification of the experiments.

This article is structured as follows: Section~\ref{sec:related} presents some
related work and background information.  Section~\ref{freezetfrc:disconnection}
uses simulations to highlight the impact of mobility-induced disconnections on
TFRC, then introduces and validates a numerical model of its behaviour, allowing
to estimate possible performance gains. Section~\ref{freezetfrc:freezing}
presents the proposed TFRC protocol modifications and their implementation into
Freeze-DCCP/TFRC; \ns-2 simulations and experimental results with a Linux
implementation are presented in section~\ref{freezetfrc:performance}.  Finally,
in Section~\ref{freezetfrc:conclusion}, we summarise this work and present
future research directions.

\section{Related Work}
\label{sec:related}

The research literature contains a large number of contributions to deal with
node mobility, at all the layers of the TCP/IP
stack~\cite{2007nazir_mobility-enabled_stack}, as well as discussion about their
validity~\cite{2004eddy_layer_mobility}. At the transport layer, the proposals
address the problem of sessions surviving the change of address of the
endpoints. Though some generic work address wireless issues, only a few works
focus on adaptation to inherently heterogeneous paths in vertical mobility
handovers.  Here, we remind the reader to the state of the art of
congestion control mechanisms for the Internet. We also summarise the problems
which arise in mobile and wireless environments, and review the proposed
mitigation techniques.

\subsection{Congestion-Controlled Transport Protocols}

It is important to fairly share the
resource. It is therefore recommended to always use congestion-controlled
transport protocols~\cite{1999floyd_end2end_congestion_control}. TCP is the
epitome of such mechanisms. Its standard mechanism~\cite{rfc5681,rfc3782}
(comprising a slow-start and a congestion avoidance phase based on AIMD) is most
notably based on a \emph{congestion window} (\cwnd) tracking the number of bytes
that can be in flight and a \emph{receiver window} (\rwnd) manipulated by the
receiver to provide flow control. TCP's congestion control is currently the
standard of fair sharing on the
Internet~\cite{1999floyd_end2end_congestion_control,rfc5166}.  There is however
some contention with respect to how this fairness should be
assessed~\cite{2007briscoe_fairness}.

The Stream Control Transmission Protocol (SCTP)~\cite{rfc4960} has been designed
to offer a more flexible choice of feature combinations than the all-or-nothing
dichotomy of TCP and UDP. It implements an AIMD-based congestion control
similarly to TCP, but provides transport for datagrams rather than byte streams.
One of its salient features is its capability to register multiple address for
the session's endpoints to provide a failover mechanism if the primary path were
to fail.  It has been leveraged for handovers
management~\cite{2008han_sctpfx,2009han_sctpmx}.

The Datagram Congestion Control Protocol (DCCP)~\cite{2006kohler_dccp,rfc4340}
has been proposed to provide congestion-controlled datagrams streams.  However,
contrary to SCTP, it does not enforce delivery reliability. This makes it
a well suited transport for application such as real-time multimedia streaming,
where timeliness of data arrival is more important than reliability.  DCCP has
been designed with modularity in mind, and several congestion control mechanisms
(identified by their \emph{Congestion Control Identifier}, CCID) can be chosen.
A TCP-like congestion control algorithm, CCID~2~\cite{rfc4341}, follows TCP's
\cwnd-based mechanism made of slow-start and AIMD.  CCID~3~\cite{rfc4342} uses
TFRC (see below). CCID~4~\cite{rfc5622} has also been proposed as a variant of
CCID~3 for small packets such as used for VoIP.

The TCP-Friendly Rate Control (TFRC) is not a transport protocol \perse, but an
equation-based rate control
mechanism~\cite{2000floyd_equation-based_unicast,2003widmer_equation-based_unicast_multicast,rfc5348}.
It uses network-gathered metrics like RTTs, number of lost packets (more
precisely, the \emph{loss event rate}) and the data rate observed by the
receiver to compute the allowed sending rate, following a model equation of the
throughput of TCP\ Reno %~\cite{rfc2581}
%
under the same
conditions~\cite{1998padhye_tcp_model}. Its operation is described in more
details in Section~\ref{freezetfrc:standard}. The use of an equation-based rate
control makes the rate changes smoother, which is more appropriate for the
streaming of multimedia content than the abrupt changes introduced by
AIMD~\cite{rfc5348}. It has also been argued
in~\cite{2004chen_rate-based_ad-hoc} that such class of rate controls tends to
be more resilient to wireless losses.

\subsection{Wireless Issues and Proposed Solutions}

In a well maintained wired-only network, the \emph{only} possible source of
losses is a router dropping packets due to its queue being full, that is, a
congestion. In this context, packet losses can clearly be considered to be fully
equivalent to congestion events, as the aforementioned congestion control
mechanisms assume.  Wireless links, however, can experience losses for other
reasons such as those related to propagation impairments or collisions at the receiver.

TCP's AIMD does not handle such losses well, as it interprets them as signs of
congestion.  New update laws for \cwnd\ have therefore been proposed to overcome
this problem. TCP Westwood~\cite{2001mascolo_westwood} and
Westwood+~\cite{2004grieco_westwood-plus_comparison} estimate the end-to-end
capacity  based on the rate of acknowledgements (ACKs) and adapt the \cwnd\ to
match this estimate.

It is noted in~\cite{1997balakrishnan_comparison_improvements_tcp_wireless} that
multiple layer-2 mitigating solutions have also been proposed. Some standardised
MAC protocols implement mechanisms to remediate or even avoid these losses.  For
example \emph{Request to send/Clear to
send} (RTS/CTS) mechanisms can be used to reserve the channel between both
nodes and mitigate the hidden node problem.  Most MAC mechanisms also adjust the
physical data rate depending on the channel conditions to ensure the majority of
the packets can be successfully received.

These MAC techniques are however not entirely transparent to the upper layers
and, if they successfully recover from a link-layer loss, it is at the price of
an increased delay to transmit the packet or an overall rate reduction. Several
studies have confirmed the performance degradation of TCP on these wireless
media~\cite{2001xylomenos_tcp_issues_wireless,2003pilosof_tcp_fairness_wlan,2004benekos_tcp_measurements_802.11b,2005franceschinis_tcp_wifi_measurement}.

To alleviate the impact of serious degradations of the wireless channel on the
TCP congestion control, an enhancement named
Freeze-TCP~\cite{2000goff_freezetcp} attempts to detect such situations at the
receiver and to suspend temporarily (``freeze'') the sender. To this end, it
leverages the window-based flow control mechanism of TCP by advertising a null
\rwnd\ (\emph{zero-window advertisement}) when the wireless channel fades away.
When the channel is restored to a usable level, the receiver sends a non
zero-window advertisement, therefore resuming the sender's operation with the
same congestion window.  It was extended to address predictable fadings in
vehicular networks~\cite{2006baig_freezetcp_on-board_performance} or mitigate
the impact of case of vertical handovers~\cite{2009park_freezetcpv2}

As for TCP, losses due to contention in wireless LANs disrupt TFRC's rate
estimation~\cite{2008zhang_cross-layer_congestion-control_wlans}.
The authors of these works identify the specific case where TFRC's natural rate
increase during loss-less periods leads to the wireless medium being saturated.
The thus-created losses lead TFRC to reduce its rate, and eventually results in
an oscillating behaviour. The authors therefore suggest to limit the transport
protocol's sending rate control law to the data rate currently achievable by the
underlying wireless link. They further extend the proposal by adding a similar
constraint in order to fairly share the wireless link with other users.

\subsection{Adapatability to Changes of Network Characteristics}

Congestion control mechanisms usually rely on estimates of the network
characteristics aggregated over time. In vertical handovers, it is not unlikely
that the new network characteristics are very different from the previous one's.
It will however take some time for the internal estimates to converge to the new
values, and properly adapt the rate.

To address this problem, SCTP is extended,
in~\cite{2008shieh_sctp_vertical_handover}, with a packet-pair probing of the
failover path prior to switching traffic. Similarly,
MBTFRC~\cite{2006lin_mbtfrc} as well as the work
in~\cite{2006chen_link_capacity_tfrc_probe}, have been proposed to implicitely
identify changes in the network characteristics, and react to them adequately.
Packet-pair techniques are however questionned as to their ability to adequately
estimate the capacity of a loaded path~\cite{2001dovrolis_packet-pair}.
High-to-low capacity changes are addressed in
\cite{2001bansal_slowly_responsive_congestion_control} which proposes some
self-clocking \textit{à la} TCP to avoid overloading a slow or congested link. A
more aggressive extension is also proposed
in~\cite{2008li_improving_tfrc_bandwidth_handover}. To accomodate for
intermitent traffic without unduly limiting the rate, a faster restart has also
been proposed for TFRC~\cite{draft-ietf-dccp-tfrc-faster-restart-06}, which
probes the network more aggressively under the assumption that its condition
might not have changes much since the last estimate.

Our proposal differs from the approaches above in that it is an integrated
transport-level solution which addresses both high-to-low and low-to-high
handovers and adjusts the rate accordingly through in-band techniques. Moreover,
it also targets break-before-make events (of which \emph{make-before-breaks} are
a subset) and the resulting packet losses during the disconnected period.
Finally, it relies on explicit notifications (the only cross-layer information
needed), which allows for a more timely and accurate knowledge of path changes.

\section{Behaviour of TFRC During a Disconnection}
\label{freezetfrc:disconnection}

In this section, we investigate the issues TFRC faces when used in mobile
scenarios with heterogeneous handovers. We first describe the operation of TFRC
as standardised by~\cite{rfc5348}.
%
%\begin{comment} %IEEEtran%elsarticle
%
We then provide an example simulation highlighting some of the issues.
%
%\end{comment} %IEEEtran%elsarticle
%
%Its behaviour during handovers %elsarticle%IEEEtran
%
 The behaviour illustrated here  %techreport
%
is then modelled in order to quantify the
performance issues.

\subsection{Operation of Standard TFRC}
\label{freezetfrc:standard}

Based on feedback from the receiver, a standard TFRC sender controls its rate
$X$ following a model of TCP's throughput under the same
conditions~\cite{1998padhye_tcp_model},
\begin{gather}
  \label{eq:tfrc-ca}
  X_\mathrm{Bps} = T(p,R) = \frac{s}{R\sqrt{\frac{2p}3} + t_{RTO}\left( 3\sqrt{\frac{3p}8}
  \right)p\left( 1+32p^2 \right)}, \\
  \label{eq:tfrc-update-x}
  X \leftarrow \min(X_\mathrm{Bps},2X_\mathrm{recv})
\end{gather}
where $s$ is the packet size, $R$ the RTT, and $t_{RTO}$ the retransmit timeout
(usually $4R$, measured by the \verb#nofeedback# timer).  Parameters $p$ and
$X_\mathrm{recv}$ are reported by the receiver roughly every RTT and are,
respectively, the loss event rate and the current received rate. If no report
from the receiver is seen before $t_\mathrm{RTO}$ expires, the sender reduces
its allowed sending rate by halving the last used $X_\mathrm{recv}$.

As for TCP, a slow-start phase is also present to first adapt the rate
to the network path's capacity. During this phase, the sender updates its rate
once per RTT following
\begin{gather}
  X \leftarrow \min(2X, 2X_\mathrm{recv}),
  \label{eq:tfrc-ss}
\end{gather}
until the first loss is observed.  When the first loss occurs, the TFRC receiver
reports a loss event rate $p$ which reflects its observed throughput
$X_\mathrm{recv}$ before the loss. The value of $p$ is initialised by inverting
\eqref{eq:tfrc-ca}.\footnote{It is not specified in~\cite{rfc5348} how this
inversion should be done. Most implementations use a binary search, but
\cite{2007jourjon_tfrc_initialization} suggests a more CPU efficient method
based on a Newton search.}

When further losses are observed, the TFRC receiver computes $p$ as the
inverse of the weighted average of the lengths of the $n$ most recent loss
intervals $i_0,\ldots,i_{n-1}$. The length of a loss interval is measured in
number of packets successfully received. The average is computed using a vector
of decreasing weights $\vec w = [w_0,\ldots,w_{n-1}]$ as $S_0 =
\sum_{i=0}^{n-1}w_ii_i$.  The TFRC receiver actually keeps a history $\vec i =
[i_0,\ldots,i_{n}]$ of the last $n+1$ loss intervals.  This slightly larger
buffer is designed to avoid overly increasing the loss event rate when one of
these events has just happened. Indeed, when losses have just been experienced,
the size of the current loss interval $i_0$ starts increasing from 0. At first,
$i_0$ is so small that it would incorrectly drive $p$ up and needlessly reduce
the rate $X_\mathrm{Bps}=T(p,R)$. It is therefore ignored and the reported loss
event rate is still based on the previous $i_1,\ldots,i_n$ intervals. As these
values do not change anymore, $p$ is stationary during this period.  Taking $S_1
= \sum_{i=0}^{n-1}w_ii_{i+1}$, $p$ is computed in~\cite{rfc5348} as
\begin{gather}
  \label{eq:ImeanP}
  p = \frac1{i_\mathrm{mean}} = \frac{\sum_{i=0}^{n-1}w_i}{\max(S_0, S_1)}.
\end{gather}
Computing $p$ this way only considers the duration of loss-less periods and
is not related to that of those during which all packets are lost,
even if they span several RTTs.

As~\eqref{eq:tfrc-ca} has an inverse relation with the loss event rate $p$, TFRC
is not fit to work on networks with loss-inducing disconnections.  A temporary
break in the end-to-end path would indeed have several consequences.  First,
packets will needlessly use parts of the network path's capacity before being
dropped, resulting in losses. The sending rate will then gradually be reduced as
the \verb#nofeedback# timer expires. Upon reconnection, the transport protocol's
rate will therefore not match the network's characteristics and need some time
to re-adapt. We illustrate this behaviour in the next section.

Moreover, as the computation of the loss event rate is based on a history of
several loss events, TFRC reacts slowly to immediate decreases in $p$. In the
case of a cross-technology hand-off to an access networks with larger capacity,
it will therefore take a much longer time to adjust the rate to the newly
available capacity.

%\begin{comment} %IEEEtran%elsarticle
\subsection{Simulation of Mobile Handovers}
\label{sec:freezetfrc-mobile-handovers}

To present an example of the adverse consequences of disconnections on the
sending rate of DCCP/TFRC in mobility situations, we ran several simulations
with \ns-2~\cite{2009vint_ns_manual}.  The simulation scenario consists of a
landscape of $800\times1600$\,m where a Mobile IPv6 (MIPv6, \cite{rfc3775})
mobile node (MN) moves between the coverage of three access routers (AR).
\figurename~\ref{fig:systematic_simulation} presents the simulated environment,
consisting of one backbone router and the three ARs providing adjacent but
non-overlapping wireless connectivity to the MN receiving traffic.  Simulations
were also run with the second base station disabled in order to observe the
behaviour of the data stream in the case of a more sporadically available
network coverage. 

\begin{figure}[tb]
  \centering 
  \resizebox{.85\columnwidth}{!}{\input{systematic_simulation.pdftex_t}}
  
  \caption[DCCP/TFRC mobility simulation scenario]{The basic simulation
  scenario. A mobile node (MN) moves back and forth between three adjacent (but
  not overlapping) wireless networks with different prefixes. The correspondent
  node (CN) sends a constant stream of data to the MN's home address (HoA) using
  DCCP/TFRC. For simplicity, the MN's home agent (HA) is set to be the access
  router (AR) of the first access network.  Addresses are expressed in \ns-2
  format.}

  \label{fig:systematic_simulation}
\end{figure}

\ns-2 was configured to simulate a regular single-rate 11\,Mbps 802.11b wireless
channel. Some parameters had to be adjusted to obtain the desired simulation
conditions: the wireless reception threshold has been fine-tuned to simulate a
400\,m Wi-Fi range. \tablename~\ref{tab:ns80211} summarises these configuration
changes.  We have also ported the MobiWan MIPv6 support~\cite{2001ernst_mobiwan}
and DCCP module~\cite{2004mattsson_dccp_ns2} to version 2.33 of this simulator,
and updated these to the latest versions (at the time) of their respective
specifications~\cite{rfc3775,rfc5348}.\footnote{These updated patch-sets are
available at \url{http://www.nicta.com.au/people/mehanio/nsmisc/}.} All kinds of
route optimisations for MIPv6 were disabled.

\begin{table}[tb]
  \centering

  \caption[Simulations parameters adjusted from \ns-2's defaults]{Parameters
  adjusted from \ns-2's defaults.}

  \label{tab:ns80211}
  \begin{tabular}{cc}
    \toprule
    \textbf{\ns-2 parameter} & \textbf{Value} \\
    \midrule
    \multicolumn{2}{c}{\textbf{11\,Mbps 802.11b channel}} \\
    \midrule
    \verb#Phy/WirelessPhy bandwidth_# & \verb#11Mb# \\
    \verb#Phy/WirelessPhy freq_# & \verb_2.472e9_ \\
    \verb#Mac/802_11 dataRate_# & \verb_11Mb_ \\
    \verb#Mac/802_11 basicRate_# & \verb_1Mb_ \\
    \midrule
    \multicolumn{2}{c}{\textbf{Miscellaneous}} \\
    \midrule
    \verb#Phy/WirelessPhy RXThresh_# & \verb_5.57346e-11_ \\
    \verb#Agent/MIPv6/MN bs_forwarding_# & \verb_0_ \\
    \verb#Agent/MIPv6/MN rt_opti_# & \verb_0_ \\
    \bottomrule
  \end{tabular}
\end{table}

In the first scenario, the MN moves back and forth at constant speed between all
three ARs (from adjacent Wi-Fi networks), losing connectivity with the current
one, associating with the new one, and re-establishing its mobility bindings
with its HA. \figurename~\ref{fig:sys-dccp-3bs} shows that, in addition to the
delay to associate with the new AR and re-establish the bindings when the
previous link breaks, there is a delay between the time when a care-of address
(CoA, the locator in the current access network) is fully configured on the new
access network, and when the rate of TFRC is reinstated: 100\,ms until it
restarts, but 500\,ms until it is fully restored.
\figurename~\ref{fig:sys-dccp-2bs} shows the results for a similar scenario
where the second access point has been disabled, thus creating a period of
complete lack of connectivity.  The previous delay effect becomes much larger,
up to 50\,s in this case.

\begin{figure}[tb]
  \centering
  \includegraphics[width=.75\columnwidth]{sys-dccp-3bs}

  \caption[DCCP/TFRC data flow moving through adjacent Wi-Fi access
  networks]{DCCP/TFRC data flow moving through adjacent Wi-Fi access
  networks. Labels on the top axis represent the time when the new CoA has
  been configured and is fully usable.}
  
  \label{fig:sys-dccp-3bs}

\end{figure}

\begin{figure}[tb]
  \centering
  \includegraphics[width=.75\columnwidth]{sys-dccp-2bs}

  \caption[DCCP/TFRC data flow moving through non-adjacent Wi-Fi access
  networks]{DCCP/TFRC data flow moving through non-adjacent Wi-Fi access
  networks.}

  \label{fig:sys-dccp-2bs}
\end{figure}

In the next section, we model this behaviour in order to evaluate the performance
issues in terms of lost packets, delay until restart and ``wasted'' capacity.

%\end{comment} %IEEEtran%elsarticle

\subsection{Numerical Model of TFRC's Behaviour}
\label{sec:model}

%\begin{comment} %IEEEtran%elsarticle
%
In order to confirm the generality of the example of the previous section, and
quantify the highlighted impact, we
%
%\end{comment} %IEEEtran%elsarticle
%
%We now %IEEEtran%elsarticle
%
introduce a model of TFRC's behaviour when a disconnection occurs. This model is
used to derive the number of packets that are lost during the disconnection, the
delay before TFRC resumes sending after a reconnection, the available capacity
and the time it takes to adapt to the new characteristics. After validating it
with \ns-2 simulations, we evaluate these metrics for various typical horizontal
and vertical handover scenarios. This shows that there is ample room for better
management of these events. A summary of the symbols used throughout this
section is given in \tablename~\ref{tab:notations}.

\begin{table}[tb]
  \centering

  \caption[Notations for TFRC modelling]{Notations used for the analysis of
  TFRC.}

  \label{tab:notations}
  \addtolength{\tabcolsep}{-1ex}
  \begin{tabular}{cp{7.5cm}}
    \toprule
    \textbf{Sym.} & \hfill\textbf{Meaning}\hfill\strut \\
    \midrule
    \multicolumn{2}{c}{\textbf{During disconnection}} \\
    \cmidrule{1-2}
    $t_\mathrm{RTO}^i$ & Duration of NFI $i$ \\
    $X^i$ & Sender rate during NFI $i$ ($X_d = X^0$) \\
    $i_x$ & First NFI so that $X^{i_x} = s/t_\mathrm{mbi}$ \\
    $i_t$ & First NFI so that $t_\mathrm{RTO}^{i_t}$ starts increasing \\
    $n_\mathrm{lost}$ & Number of packets lost during the disconnection \\
    \cmidrule{1-2}
    \multicolumn{2}{c}{\textbf{After reconnection}} \\
    \cmidrule{1-2}
    %$p_r$ & Loss event rate upon reconnection,  entirely based on the previous %network \\ %techreport%IEEEtran 
%    $p_r$ & Loss event rate upon reconnection \\ %elsarticle
    %$X_\mathrm{max}$ & Maximal TFRC sender rate the new network can support \\ %%techreport%IEEEtran
%    $X_\mathrm{max}$ & New maximum supported TFRC sender rate \\ %elsarticle
    $t_\mathrm{idle}$ & Time before the first packet is sent after reconnection\\
    %$X_r^i$ & Sender rate during RTT $i$ after the reconnection ($X_c = X_r^0$) %\\ %techreport%IEEEtran
%    $X_r^i$ & Sender rate during RTT $i$ after the reconnection \\ %elsarticle
    %$R_r^i$ & Sender's estimation of the RTT of the new network \\ %techreport%IEEEtran
%    $R_r^i$ & Sender's estimation of the new network's RTT \\ %elsarticle
    $n_R^\varepsilon$ & Number of RTTs on the new network before $R_r^i$ is within $\varepsilon$ of $R_\mathrm{new}$ \\
    $n_\mathrm{pkts}^i$ & Total number of packets sent after RTT $i$ on the new network \\
    %$t_*$ & Times to recover from the disconnection and adapt to the new %capacity\\ %techreport%IEEEtran
%    $t_*$ & Times to recover and adapt \\ %elsarticle
    $n_\mathrm{wasted}^*$ & Number of packets that could have been sent \\
    \bottomrule
  \end{tabular}
\end{table}

\subsubsection{During the Disconnection}

During the disconnection, the TFRC senders keeps transmitting packets. However,
no feedback from the receiver can be received, and the sending rate is
gradually reduced. Here, we evaluate this rate, and the number of packets which
get sent but cannot be received.

\paragraph{Evolution of Internal Parameters} We evaluate the changes in sender
rate $X$ during a disconnection, as well as the \verb#nofeedback# timer's
period, $t_\mathrm{RTO}$. Both values have an impact on the number of packets
lost during the disconnection and the rate recovery after the reconnection.
\figurename~\ref{fig:regular-tfrc-internal} represents the evolution of these
parameters.

Just before the disconnection occurs, at $T_d$, the sender sends at rate $X=X_d$.
In the following, this is assumed to be the nominal TFRC rate that the
underlying link can support. Consequently, the receiver measures and reports an
$X_\mathrm{recv}$ roughly equal to $X_d$.  Thus, \eqref{eq:tfrc-update-x}
is limited by $X_\mathrm{Bps}$.

In the absence of feedback, the TFRC sender halves its allowed sending rate
every time the \verb#nofeedback# timer expires by reducing its local estimate of
$X_\mathrm{recv}$. When $X$ becomes small, $t_\mathrm{RTO}$ is increased to
cover the transmission of at least two packets.

For convenience, we segment the disconnected period into \emph{no feedback
intervals} (NFI). An NFI is the interval between two consecutive expirations of
the \verb#nofeedback# timer.%
\footnote{An NFI is the same concept as the NFT of \cite{draft-ietf-dccp-tfrc-faster-restart-06}.}%techreport
 NFIs are indexed starting at
$i=0$. The first expiration of the \verb#nofeedback# timer marks the end of NFI
0. Hence, the effects of this timeout start at the beginning of NFI 1.  The rate
then gradually decreases until it reaches its minimum value during NFI $i_x$.

Every NFI, the sender halves the value of $X_\mathrm{recv}$, which then
drives~\eqref{eq:tfrc-update-x}. In the worst situation, $X$ can reduce to the
minimal value of one packet every 64 seconds ($s/t_\mathrm{mbi}$).  Taking $i_x$
as the NFI during which $2X_\mathrm{recv}^{i_x}$ drops below $s/t_\mathrm{mbi}$,
the sender rate can be expressed as
\begin{gather}
  X^i = \begin{cases}
    \frac{X_d}{2^{i}} & \text{if $0 \leq i < i_x$,} \\
    \frac{s}{t_\mathrm{mbi}} & \text{otherwise,}
  \end{cases}
  \label{eq:numerical-x-i} \text{ with } 
  i_x =  \left\lceil \log_2\frac{X_d\cdot t_\mathrm{mbi}}s \right\rceil,
  %\label{eq:numerical-ix}
\end{gather}
where $\lceil\cdot\rceil$ is the ceiling operator.

Additionally, the \verb#nofeedback# timer, initially set to
$t_\mathrm{RTO}^0=4R$, increases when the sending rate becomes smaller than
$2s/4R$. Assuming $X_d\ge2s/4R$ and taking $i_t$ as the NFI during which
$2s/X^{i_t}$ becomes larger than $4R$, the duration of NFI $i$ is then
\begin{gather}
  t_\mathrm{RTO}^i = \begin{cases}
    4R & \text{if $i < i_t$,} \\
    \frac{2s}{X^i} & \text{otherwise,}
  \end{cases}
  \label{eq:numerical-trto-i} \text{ with }
  i_t =  \left\lceil \log_2\frac{2R\cdot X_d}s \right\rceil.
  %\label{eq:numerical-it}
\end{gather}
Note that~\eqref{eq:numerical-trto-i} is only valid for $R<t_\mathrm{mbi}/2$, in
which case $i_t \le i_x$. Otherwise, $4R$ is larger than the time to send 2
packets at the lowest rate, and $i_t$ is considered to be $+\infty$.

\paragraph{Packet Losses}

Though the number of losses happening during the single loss event of the
handover does not directly impact TFRC's sender rate, they are an unnecessary
burden on the rest of the network which could be better used for other traffic,
for which data can actually be delivered to the destination. It is interesting
to quantify this charge on the network in the form of the number of packets
which will be lost during the disconnected period.

\figurename~\ref{fig:regular-tfrc} shows the evolution of the sender rate during
a handover. Two cases are represented, for different reconnection times $T_c$
and $T_c^\prime$. They respectively occur before and after the sender's
estimation of the receiver rate has reduced to less than one packet per RTT.

Time $t_D = T_c - T_d$ is the length of the disconnected period.  All the
packets sent during this period are lost.  The number of lost packets when the
reconnection occurs, after $n_D$ NFI (such that
$\sum_{i=0}^{n_D}t_\mathrm{RTO}^i \ge t_D$), can be estimated using
\begin{gather}
  \label{eq:numerical-packet-losses}
  n_\mathrm{lost} = \begin{cases}
    \left\lfloor \frac{t_DX^0}s \right\rfloor & \text{if $t_D \le t_\mathrm{RTO}^0$,} \\
      \left\lfloor \frac{t_\mathrm{RTO}^0X^0}s + \sum_{i=1}^{i_D} \frac{t_\mathrm{RTO}^iX^i}s \right\rfloor & \text{otherwise,}\\
  \end{cases}
\end{gather}
where $i_D=n_D-1$ is the index of the $n_D^\mathrm{th}$ NFI and
$\lfloor\cdot\rfloor$ is the floor operator.


\begin{figure*}[tb]
  \subfloat[Internal parameters]{
    \resizebox{.32\textwidth}{!}{
      \input{regular_tfrc_internal.pdftex_t}
    }
    \label{fig:regular-tfrc-internal}
  }
  \subfloat[Rate behaviour]{
    \resizebox{.32\textwidth}{!}{
      \input{regular_tfrc.pdftex_t}
    }
    \label{fig:regular-tfrc}
  }
  \subfloat[Larger capacity]{
    \resizebox{.32\textwidth}{!}{
      \input{regular_tfrc_bigger.pdftex_t}
    }
    \label{fig:regular-tfrc-bigger}
  }

  \caption[TFRC sender's internal parameters and rate behaviours.]{TFRC sender's
  internal parameters and rate behaviours.
  \subref{fig:regular-tfrc-internal}~Evolution of internal parameters after a
  disconnection. \subref{fig:regular-tfrc}~Rate behaviour in a period with no
  connectivity. Two cases are shown, with different times of reconnection: at
  $T_c$, a period $t_D$ has elapsed which is short enough that TFRC's rate did
  not reach its minimum (red) and at $T_c^\prime$, when the time $t_D^\prime$
  elapsed since the disconnection was sufficient for $X$ to reduce to
  $s/t_\mathrm{mbi}$ (blue); an additional delay $t_\mathrm{idle}$ is present in
  the latter case before TFRC starts restoring its rate.
  \subref{fig:regular-tfrc-bigger}~After a reconnection, TFRC does not adapt
  quickly to higher capacities. It slowly uses more capacity as $p$ decreases.}

\end{figure*}

\subsubsection{After the Reconnection}
\label{sec:after-reco}

After having reconnected, packets and feedback messages can be exchanged again,
but some waiting time due to exponential backoff may delay this restart.  The
loss event rate $p$ gets updated on the first feedback message, then so is the
rate. When the rate can increase again, it will however reflect the parameters
observed on the previous network path, which may be inappropriate for the new
access network.

\paragraph{Variation of the Loss Event Rate}

The losses will only be noticed by the receiver after reconnecting.  In
\cite{rfc5348}, the authors specify that the expected arrival time of a lost
packet is interpolated using those of both packets received directly before and
after the loss. Multiple losses over the disconnected period will then be
considered part of the same loss event starting in the middle of the
disconnected period.

Following the procedure described in Section~\ref{freezetfrc:standard}, the
evolution of $p$ can be in three different phases depending on $S_0$ and $S_1$
(defined in that section):
\begin{description}
  \item[no loss] when $S_0\ge S_1$, $p$ gradually decreases as the number of
    received packets, in $i_0$, increases;
  \item[first loss observed] makes $S_0<S_1$ which stabilises $p$ until the current loss
    interval $i_0$ becomes large enough that the inequality is reversed;
  \item[new loss observed] when $S_0<S_1$, $\vec i$ gets shifted which increases
    $p$ as~\eqref{eq:ImeanP} now has a smaller denominator.
\end{description}

In the congestion avoidance state, the variation of loss event rate ($\Delta p$) can be in different
ranges depending which of the three phases the sender is in.
\begin{gather}
  \begin{cases}
    \Delta p = 0, \qquad \text{after the first loss has been observed,} \\
    \Delta p > 0, \qquad \text{when more losses are observed,} \\
    \Delta p_\mathrm{min}(\Delta n_\mathrm{pkts},p_\mathrm{prev}) \le \Delta p < 0, \qquad \text{otherwise (no loss).}
  \end{cases}
  \label{eq:numerical-p-variation}
\end{gather} 
The lower bound of $\Delta p=p-p_\mathrm{prev}$ when no losses occur can be derived
using~\eqref{eq:ImeanP} to estimate $p$. If all
$\Delta n_\mathrm{pkts}$ packets sent since the last feedback, which reported
$p_\mathrm{prev}$, have been received and taken into account in the receiver's
next feedback, the reduction in $p$ will be the lower-bound
\begin{gather}
  \Delta p_\mathrm{min}(\Delta n_\mathrm{pkts},p_\mathrm{prev}) = 
  \underbrace{\frac{\sum_{i=0}^{n-1}w_i}{w_0\Delta n_\mathrm{pkts} +
  (\sum_{i=0}^{n-1}w_i)/p_\mathrm{prev}}}_{p=1/i_\mathrm{mean}}-p_\mathrm{prev}.
  \label{eq:numerical-delta-p}
\end{gather}

\paragraph{Event Timing}

While the time base of changes of the disconnected sender are regulated by the
length of its retransmit timeout, feedback from the receiver takes on this role
once reconnected. The receiver sends periodic feedback messages at least once
per RTT. For the rest of this section, time will then be segmented in units of
RTTs. Indices $i$ now refer to how many of those have elapsed since the
reconnection, rather than NFI as previously.

The periodicity of sender-side events triggered by these feedback messages will
follow the RTT of the visited network.  While this value is mostly
stationary for a given network, the sender does not use it directly for its
computations, most notably that of the sending rate. To ensure a smooth
evolution, it uses an exponentially weighted moving average of the past samples
to estimate the RTT. After feedback message $i$ allowing to sample RTT
$R_\mathrm{new}$ of the new network, the sender's estimate of the RTT is
%\begin{gather}
  $R_r^i = q R_r^{i-1} + (1-q) R_\mathrm{new},$
%\end{gather}
with $0<q<1$ ($q=0.9$ in~\cite{rfc5348}).  Just after the reconnection, before
the first feedback message has been received, the estimate completely reflects
the RTT of the previous network, $R_r^0 = R_\mathrm{old}$.
Expanding the series, this estimate can be expressed as
\begin{align}
  \label{eq:Rri}
  R_r^i &= (1-q)R_\mathrm{new}\underbrace{\sum_{j=0}^{i-1}q^j}_{\frac{q^0 - q^i}{1-q}} + q^i R_r^0 
  = \left(1-q^i\right)R_\mathrm{new} + q^iR_\mathrm{old}.
\end{align}
It will then evolve from a value representing of the RTT on the previous
network, $R_\mathrm{old}$, to that of the new network. Depending on the
difference ratio between these two values, a variable number of samples will be
needed for the sender to have an accurate estimate of $R_\mathrm{new}$. The
number of samples, denoted $n_R^\varepsilon$, needed to have an estimate within
$\varepsilon$ of the actual value, that is,  $\left| R_r^{n_R^\varepsilon} -
R_\mathrm{new} \right| \le \varepsilon$, is
\begin{gather}
  \label{eq:iRvarepsilon}
  n_R^\varepsilon = \left\lceil\frac{\ln\varepsilon - \ln\left| R_\mathrm{old}-R_\mathrm{new} \right|}{\ln q}\right\rceil.
\end{gather}
Assuming that the order of magnitude can vary from the millisecond to the second
depending on the network technology and load, it can take up to almost 30 RTTs
on the new network for the estimate to be accurate within a 5\,\% margin.

It is important to note that the TFRC equation~\eqref{eq:tfrc-ca} is directly
dependent on this estimate. Given a static $p=p_r$ after the reconnection, as
per~\eqref{eq:numerical-p-variation}, successive samples of the new RTT will
refine the estimate which will in turn impact $X_\mathrm{Bps}$. As
$t_\mathrm{RTO}=4R$, $X_\mathrm{Bps}$ can be expressed as a function of any of
its previous values $T(p_r, R^\prime)$ and the associated RTT estimate $R^\prime$
\begin{align} 
  \label{eq:XiBps}
  X_\mathrm{Bps}^i &= T(p_r, R_r^i) = \frac{R^\prime}{R_r^i} T(p_r, R^\prime).
\end{align}
The most useful such relation involves $X_d=T(p_r,R_\mathrm{old})$:
$X_\mathrm{Bps}^i = (R_\mathrm{old}/R_r^i)X_d$; upon reconnection, the new
TFRC rate, as compared to that before the disconnection, is thus only
dependent on the ratio of the current and previous estimations of the RTT, as
$p_r$ is computed from $S_1$.

\paragraph{Number of Sent Packets}

When the connection is re-established and the TFRC sender restarts sending
packets, it goes through a few phases before being able to resume a rate
appropriate to the current network. Depending on the differences between the
previous and the current networks' characteristics, the duration (or existence)
of these phases will vary. An important factor impacting theses phases is the
number of packets that have been sent since the reconnection. In the following,
it will be expressed as
%\begin{gather}
%  n_\mathrm{pkts}^i = \frac1{s}\sum_{j=0}^i R_r^jX_r^j,
  $n_\mathrm{pkts}^i = 1/s\sum_{j=0}^i R_r^jX_r^j$,
%  \label{eq:numerical-npkts}
%\end{gather} 
where $i$ is the RTT at the end of which the packets are counted and $X_r^i$
is the sending rate during that RTT, as detailed below.

\paragraph{Unused Capacity}

When connectivity is re-established, two factors can prevent the TFRC sender
from fully utilising the available capacity instantaneously.  First, when
feedback is received, the sending rate is not resumed directly, but through a
phase similar to slow-start (\eg, at $T_c$ in
\figurename~\ref{fig:regular-tfrc}).  Second, the sender is not directly aware
of the reappearance of connectivity. It has to wait for a packet to be
acknowledged by the receiver. As the sending rate has been gradually reduced,
said packet may not be immediately sent (\eg, $t_\mathrm{idle}$ after
$T^\prime_c$ in \figurename~\ref{fig:regular-tfrc}). 

If the sending rate when reconnecting, $X_c=X^{n_D}$, is small, the delay
$s/X_c$ between the transmission of two subsequent packets becomes significant.
When connectivity is recovered, it can take up to this delay before the first
packet is sent. The average idle time after reconnecting can be expressed as
%\begin{gather}
%  t_\mathrm{idle} = \frac{s}{2X_c}.
%  \label{eq:numerical-idle-time}
%\end{gather}
$t_\mathrm{idle} = s/2X_c$.

After this delay, the sender eventually starts increasing the rate. Packets are
first sent at rate $X_c$. Every RTT, a feedback is received with the current
value of $X_\mathrm{recv}$. According to~\eqref{eq:tfrc-update-x}, the rate can
then be updated to twice this value until $X_r^i$ reaches the rate allowed by
the TFRC equation, $X_\mathrm{Bps}^i = (R_\mathrm{old}/R_r^i)X_d$. During
the slow-start RTT $i$, the sender rate is
\begin{gather}
  \label{eq:numerical-xrss}
  X_r^i = 2^i X_c.
\end{gather}
Assuming the new network provides the same capacity as the previous one, the
average number of packets that could additionally be sent is 
\begin{gather}
  n_\mathrm{wasted} = \frac1s\left(t_\mathrm{idle} \cdot X_d + \sum_{i=0}^{n_\mathrm{ss}} R_\mathrm{new}
  \left( X_d - X_r^i \right)\right).
  \label{eq:numerical-packets-wasted}
\end{gather}
Parameter $n_\mathrm{ss}$ is such that $X_r^{n_\mathrm{ss}} \ge
X_\mathrm{Bps}^{n_\mathrm{ss}}$. The development of this inequality
using~\eqref{eq:Rri}, \eqref{eq:XiBps} and~\eqref{eq:numerical-xrss} leads to
\begin{gather}
  \frac{R_\mathrm{new}}{R_\mathrm{old}}2^{n_{ss}} + \left(1-\frac{R_\mathrm{new}}{R_\mathrm{old}}\right)(2q)^{n_{ss}} > \frac{X_d}{X_c},
  \label{eq:numerical-nss}
\end{gather}
which is not linear in $n_\mathrm{ss}$. It thus cannot be solved in a purely
analytical fashion. In our implementation of the model, we used the
Newton-Raphson method%
%
%. %IEEEtran%elsarticle
%\begin{comment}%IEEEtran%elsarticle
~\cite{1995ypma_newton-raphson} with 
\begin{gather}
  f(n_{ss}) = \frac{R_\mathrm{new}}{R_\mathrm{old}}2^{n_{ss}} + \left(1-\frac{R_\mathrm{new}}{R_\mathrm{old}}\right)(2q)^{n_{ss}} - \frac{X_d}{X_c}\quad\text{and} \\
  f^\prime(n_{ss}) = \frac{R_\mathrm{new}}{R_\mathrm{old}}2^{n_{ss}}\ln2 + \left(1-\frac{R_\mathrm{new}}{R_\mathrm{old}}\right)(2q)^{n_{ss}}\ln2q.
\end{gather}
%\end{comment} %IEEEtran%elsarticle
This allowed us to solve~\eqref{eq:numerical-nss} for $n_{ss}$ in only a few
iterations starting from an arbitrary $n_{ss0} = 10$, regardless of the network
parameters.

\paragraph{Networks with Larger Capacity} The estimate of the loss event rate
$p$ is designed to evolve smoothly. This may cause an additional under-usage of
the available capacity in case the MN connects to a network with a higher
capacity, $X_\mathrm{max}$, than the previous link.  Depending on the difference
in capacity from said previous network, it may take an unacceptably long time
for the sender to eventually occupy the full available capacity.
\figurename~\ref{fig:regular-tfrc-bigger} shows how TFRC slowly adapts to the
new network capacity.

This adaptation time can be split into two periods.  First, once the
slow-start phase has finished, the sender rate may not immediately start
increasing above $X_c$. Indeed, if there has not been enough packets sent during
the slow-start for $S_0$ to be larger than $S_1$ in~\eqref{eq:ImeanP}, $p$
will not decrease. During the loss recovery time, $X_\mathrm{Bps}$ is kept at
value $X_r^i=(R_\mathrm{old}/R_r^i) X_d$. After $t_\mathrm{recov}$, when enough
packets have been received, $p$ will start decreasing again. During this phase,
the sending rate slowly adapts to the available capacity, which is eventually
reached after $t_\mathrm{grow}$. In addition of
$n_\mathrm{wasted}$, a further $n_\mathrm{wasted}^\prime$ packets could be sent.
We develop a formulation of this extra capacity wastage below.

The loss recovery time, until the current loss interval contains enough packets
not to be ignored in~\eqref{eq:ImeanP}, is such that $0 < S_0 - S_1$ that is,
\begin{align}
  0 &< w_0 \underbrace{i_0}_{n_\mathrm{pkts}^{n_\mathrm{recov}}} +
  \sum_{n=1,\ldots,i-1} (w_n - w_{n-1}) i_n - w_{i-1} i_i.
  \label{eq:numerical-nrecov-imean-diff-generic}
\end{align}

To ``compete in the global Internet with TCP,'' it is recommended
in~\cite{rfc5348} to take $n=8$ and the weight vector as $\vec w = [1, 1, 1, 1,
0.8, 0.6, 0.4, 0.2]$. The formulation
of~\eqref{eq:numerical-nrecov-imean-diff-generic} can thus be simplified as
\begin{align}
  0 < n_\mathrm{pkts}^{n_\mathrm{recov}} - 0.2 \sum_{n=4}^8i_n \quad\rightarrow\quad &
  n_\mathrm{pkts}^{n_\mathrm{recov}} > 0.2 \sum_{n=4}^8i_n.
  \label{eq:numerical-npktsrecov-rfc5348}
\end{align}
When $n_\mathrm{pkts}^{n_\mathrm{recov}}$ packets have been sent since the reconnection,
$p$, driven by~\eqref{eq:ImeanP}, starts decreasing. It is difficult to estimate the
$i_n$ as they are dependent on the previous network conditions and specific
history. However, assuming a relatively stable network, all $i_n$ would be
similar and close to the inverse of $p_r$, the loss event rate of the previous
network. Thus, an estimate of the number of packets that need to be sent before
$p$ starts to adapt to the new network conditions can be written as
%\begin{gather}
%  n_\mathrm{pkts}^{n_\mathrm{recov}} = \frac1{p_r}.
%  \label{eq:numerical-npktsrecov}
%\end{gather}
$n_\mathrm{pkts}^{n_\mathrm{recov}} = 1/p_r$.

This estimation allows to evaluate the duration of the recovery period,
$t_\mathrm{recov}$, which exists only if
$n_\mathrm{pkts}^{n_\mathrm{recov}}>n_\mathrm{pkts}^{n_\mathrm{ss}}$%
%
 (that is $t_\mathrm{recov}>0$) %techreport
%
,
\begin{gather}
%  n_\mathrm{pkts}^{n_\mathrm{recov}} = n_\mathrm{pkts}^{n_\mathrm{ss}} + \frac{Xd}{s}t_\mathrm{recov}\notag\\
  t_\mathrm{recov} = \frac{s}{Xd}\left( n_\mathrm{pkts}^{n_\mathrm{recov}} - n_\mathrm{pkts}^{n_\mathrm{ss}} \right) = \frac{s}{Xd}\left( 1/p_r - n_\mathrm{pkts}^{n_\mathrm{ss}} \right).
  \label{eq:trecov}
\end{gather}

The additional amount of wasted capacity can be estimated as 
\begin{gather}
    \label{eq:numerical-rate-bigger}
    n_\mathrm{wasted}^\prime = \begin{multlined}[t]
      \frac1s (X_\mathrm{max} - X_d) \left( t_\mathrm{idle} + t_\mathrm{ss} + t_\mathrm{recov} \right) + \\
      \frac{R_\mathrm{new}}s \sum_{i=0}^{n_\mathrm{grow}} \left(X_\mathrm{max} - X_r^i \right)
    \end{multlined} \\
  \intertext{with}
  X_r^i = \begin{cases}
    X_d & \text{if $i=0$,}\\
    \min\left(X_\mathrm{Bps} \left( p_\mathrm{r} + \Delta p(n_\mathrm{pkts}^{i-1}, p_\mathrm{r}),R^i_r \right), 2X_r^{i-1} \right) & \text{otherwise.}
  \end{cases}
\end{gather}
Similarly to ~\eqref{eq:numerical-packets-wasted}, $n_\mathrm{grow}$ is the
number of RTTs needed to have $X^{n_\mathrm{grow}} \ge
X_\mathrm{max}$.

\subsection{Model Validation}

We now verify the model of the previous section by comparing numerical
results to \ns-2 simulations for a wide range of network parameters and
disconnection durations.

To check the behaviour of TFRC during the disconnected
period---\eqref{eq:numerical-x-i} and \eqref{eq:numerical-trto-i}---as well as
the resulting number of lost packets~\eqref{eq:numerical-packet-losses}, 60\,s
disconnections are introduced after a variable amount of time, for link
capacities of 10, 54 and 100\,Mbps and for a range of delays (1--100\,ms).  The
number of packets sent after the disconnections is then counted in the
simulation trace file.  \figurename~\ref{fig:model-check-disco-nlost-nwasted}
shows a comparison of simulation results with predictions from the model for
$R=1$\,ms. It confirms that our model exactly predicts the values of the internal
parameters of the TFRC sender, and accurately estimates the number of losses.

\begin{figure}[tb]
  \begin{center}
    \includegraphics[width=\columnwidth]{model-check-disco-nlost-nwasted}
  \end{center}

  \caption[TFRC model validation (internal parameters, lost packets and wasted
  capacity)]{Comparison of simulated TFRC's internal parameters, and number of
  lost packets during disconnections with the model's predictions. Results shown
  for $X=10$\,MBps and $R=2$\,ms.}

  \label{fig:model-check-disco-nlost-nwasted}
\end{figure}

The number of wasted packets, as determined
by~\eqref{eq:numerical-packets-wasted} and~\eqref{eq:numerical-rate-bigger}
cannot be derived in the same way from the \ns-2 trace files. Detecting the end
of the adaptation periods $t_\mathrm{ss}$ and $t_\mathrm{grow}$ relies on
comparing the current rate to $X_\mathrm{max}$, for which it is impossible to
obtain a ground truth from the simulations. It is therefore impossible to
identify over which period to count the additional packets which could have
potentially been sent, and the results vary depending on the estimate taken for
$X_\mathrm{max}$. In the following, we take $X_\mathrm{max} = X_\mathrm{recv}$
(from \tablename~\ref{tab:stationary-params} below); the order of magnitude of the
resulting numbers for the wasted capacity are coherent, but the reported value
is only indicative, and should not be used in further derivations.

Even though the presented model does not encompass all the details of the
behaviour of a real TFRC sender, it has proven to have sufficient prediction
accuracy to be used in estimating potential performance gains.

\subsection{Potential for Improvement}

We use our numerical model to determine the performance improvements that can be
expected from a better handling of disconnections. The input parameters ($X_d$
and $R$ of both links) for the model are those observed by TFRC when the
stationary state has been reached. These are summarised in
\tablename~\ref{tab:stationary-params} (based on network characteristics
presented later in~\tablename~\ref{tab:characteristics}). 

\begin{table}[tb]
  \centering
  \caption[Network parameters as observed by the \textit{ns}-2 TFRC sender]{Network
  parameters as observed by the \ns-2 TFRC sender in the stationary phase,
  reached at $T_\mathrm{stat}$.}
  \label{tab:stationary-params}
  \begin{tabular}{cccc}
    \toprule
    \textbf{Link type} & \textbf{$X_\mathrm{recv}$ [MBps]} & \textbf{$R$ [s]} & \textbf{$T_\mathrm{stat}$ [s]} \\
    \midrule
    UMTS & 	0.044 & 	0.96 & 	660.54 \\
    802.16 & 	1.10 & 	0.17 & 	264.14 \\
    802.11b & 	1.27 & 	0.05 & 	50.69 \\
    802.11g & 	4.82 & 	0.04 & 	21.67 \\
    \bottomrule
  \end{tabular}
\end{table}

MIPv6 relies on message exchanges over the network to update the binding
with the HA.\footnote{Fast handovers~\cite{2001koodli_fast_handover_context_transfer} could be used to reduce
the disconnection duration. However, packets arriving during the hand-off are
buffered at the new access router, which is not desirable for real-time traffic
as this would create latency at the application layer upon completion of the
handover.} Therefore, handover delays will vary depending on the characteristics of
the current link. The RTT on the new access network is particularly important
as it affects the delay until the MIPv6 binding updates are received.
In~\cite{2004lee_mipv6_handoff_analysis}, the authors thus proposed to use $t_\mathrm{ho} = 2.5
+ R$ as the time to complete the handover, and during which packets cannot be
successfully transmitted to the MN. We use this model as $t_D = t_\mathrm{ho}$.

An estimate of the stationary phase value for RTT on the new link is used for
$R$ in $t_\mathrm{ho}$. It is an over-estimation as the RTT is likely not to be
as high upon reconnection as when the full rate is established. Therefore, the
presented results should be considered an upper bound for the packet loss and
lower bound for the wasted capacity.

The number of lost packets and the available capacity wasted during a MIPv6
handover, as predicted by the model, are shown on
\tablename~\ref{tab:model-mip-nlost-nwasted}.  These results confirm that the
behaviour of TFRC can be improved. We intend to provide such improvement in
the next section.

\begin{table}
  \centering

  \caption[Losses and wasted capacity during a handover]{Predicted packet losses and
  wasted available capacity expected during a MIPv6 handover.}

  \label{tab:model-mip-nlost-nwasted}
  \begin{tabular}{ccccc}
    \toprule
    \multirow{2}{*}{\backslashbox{\textbf{from}}{\textbf{to}}} & \multirow{2}{*}{UMTS} & \multirow{2}{*}{802.16} & \multicolumn{2}{c}{802.11} \\
    & & & b & g \\
    \midrule
    \multicolumn{5}{c}{\textbf{Packet losses}} \\
    \midrule
    \input{model-mip-nlost}
    \midrule
    \multicolumn{5}{c}{\textbf{Wasted capacity [Number of 500\,B packets]}} \\
    \midrule
    \input{model-mip-nwasted-magnitude}
    \bottomrule
  \end{tabular}
\end{table}

\section{Freezing the DCCP/TFRC Transmission Upon Disconnections}
\label{freezetfrc:freezing}

In this section, we present an enhancement and its implementations to approach
the possible improvement made apparent above.  This modification relies on two
main additional stages. The sender's state is first frozen just before a
hand-off so as not to disrupt its performance, and transmission is suspended.
When the handover is complete, the sender is unfrozen. Then, with assistance
from the receiver it restores its previous rate and, if possible, probes the new
network path for a larger usable capacity.  Though this work primarily addresses
break-before-make handovers, a subset can also apply to make-before-break
events. In these cases, only the probing phase is needed.

The rationale for restoring the previous rate comes from
Freeze-TCP~\cite{2000goff_freezetcp}, where only wireless fading or horizontal
handovers were considered. Another advantage of this approach is that this rate
is known without dependence any external information source. In the case of
vertical hand-offs, as we consider them here, other approaches could also be
envisionned.  Some additional cross-layer interaction would allow the
application or some management element to specify another restart point based on
requirements or external knowledge of the expected
%
capacity~\cite[\eg,][]{1999balakrishnan_integrated_congestion_control,2011mehani_multihomed_flow_management}.%%elsarticle%techreport
%
%capacity~\cite{1999balakrishnan_integrated_congestion_control,2011mehani_multihomed_flow_management}.%IEEEtran
%
However, it would be important to ensure that the selected rate is not so high
as to cause overly excessive congestion on the new path during the first RTT.
In the following, we only consider previous-state restoration.

\subsection{Rationale of the Improvements}

Beyond the packet losses and under-usage of the available capacity, a reduction
in the immediate rate is quite detrimental to real-time applications. As
previously shown in Section~\ref{sec:after-reco}, it can take
up to several seconds to restore the rate after the completion of a handover.
During this period, applications observe high error rates as they cannot fit the
required amount of data units in the rate allowed by the transport protocol,
which results in bad QoE.  In such a situation, restarting from the rate
achieved before the handover would enable the application to drastically reduce
this period of bad quality.

Considering a communication involving video, the user's experience can be
further improved if the new access network has better characteristics, such as a
larger capacity. In the new network, the video codec could use a higher encoding
rate which would increase the overall QoE. Including a mechanism to probe the
new network path can make the new available path capacity available much faster
to the application. It could then take advantage of this larger capacity to
enhance the overall user experience.

Finally, having information about upcoming handovers, it is also possible to
limit, or even nullify, the number of lost packets. Doing so also has the
advantage of avoiding the unnecessary use of the old network path to send data
which would never be received as the receiver has moved.

When a hand-off is imminent (as detected through %
, \eg, IEEE 802.21~\cite{2009piri_80221} or %techreport
control frameworks
%
%such as outlined in%elsarticle
%
~\cite{2011mehani_multihomed_flow_management}), we thus propose to
temporarily suspend the evolution of specific internal parameters. The sender
keeps an estimate of the current stationary parameters of the network used to
derive the sending rate offered to the application. Further packet transmission
is also prevented as the path from the sender to the receiver is known to be
temporarily cut.  When connectivity is available anew, the rate is restored
immediately and adapted as soon as possible to the new network conditions. The
congestion control algorithm first allows packets to be sent at the same rate as
before. If no error is reported, the sender then tries to probe the network path
by increasing its rate. In a way similar to the initial slow-start, the sending
rate doubles every RTT until the capacity of the new network has been reached.

\subsection{New States to Support the Freezing Mechanism}

We implement our proposed enhancement to TFRC within DCCP's CCID~3. The
operation of the resulting Freeze-DCCP/TFRC is separated into three phases:
\emph{Frozen}, \emph{Restoring} and \emph{Probing}. New states are implemented
into the TFRC sender and receiver to support these phases. Additionally, new
DCCP options are introduced to enable the required freeze/unfreeze signalling,
while state transition and synchronisation is done purely through TFRC options.

\figurename~\ref{fig:freeze-states} shows the proposed Freeze-DCCP/TFRC state
diagram. The sender has three new states, shown in
\figurename~\ref{fig:freeze-states:sender}.  As most of Freeze-DCCP's operation
is driven by the sender, its states are directly named after the three phases.
The receiver has two ``active'' states: \emph{Restoration} and \emph{Probed}.
Both \emph{Recovery} states are transient and used to ensure synchronisation.
These are shown in \figurename~\ref{fig:freeze-states:receiver}.

\begin{figure*}[tb]
  \centering
  \subfloat[Freeze-DCCP/TFRC sender]{\resizebox{.95\columnwidth}{!}{
  \input{freeze_sender.pdftex_t}
  \label{fig:freeze-states:sender}
  }}
  \hfill
  \subfloat[Freeze-DCCP/TFRC receiver]{\resizebox{.95\columnwidth}{!}{
  \input{freeze_receiver.pdftex_t}
  \label{fig:freeze-states:receiver}
  }}

  \caption[Additional states and option exchanges to support
  Freeze-DCCP/TFRC]{Additional states and option exchanges to support
  Freeze-DCCP/TFRC (transitions are labelled as Condition/Action).  The
  sender~\subref{fig:freeze-states:sender} can be instructed to freeze or
  unfreeze either locally or by the remote peer. The
  receiver~\subref{fig:freeze-states:receiver} does not have to enter a Frozen
  state, but must perform some specific tasks during the Restoration and Probed
  phases.  Options can signal both/either the remote sender and/or receiver.}

  \label{fig:freeze-states}
\end{figure*}

The following sub-sections detail the signalling options and the evolution of the
states, as well as their specific actions throughout the Freeze-DCCP/TFRC phases.

\subsection{Additional Signalling}

Though window-based flow-control mechanisms have been proposed for
TFRC~\cite{2010lochin_chameleon}, they have not been included in the standard.
Thus, unlike Freeze-TCP~\cite{2000goff_freezetcp}, it is not possible to freeze
a DCCP/TFRC sender by simply reporting a specific value in a feedback message.
Additionally, it is desirable to be able to locally suspend the sender. To fully
support freezing on both sides, it is necessary to introduce new signalling
options, to be carried in the DCCP or TFRC packet headers. Our proposal does
not, however, change or extend the format of these headers; the options will be
gracefully ignored by standard implementations.

In a generic typical case, a mobile node, both sending and receiving over the
same DCCP connection, will detect or be informed that it is about to lose its
current connectivity. In this proposal, packets with an \verb#OPT_FREEZE#
DCCP-level option will be sent to the remote peer to suspend its sender
operation, then the local sender will be frozen. As the packets carrying the
option have to make it to the remote sender, the transport layer has to be
informed about upcoming disconnection a short while before it is to happen. A
minimum of one RTT is usually considered a reasonable
value~\cite{2000goff_freezetcp}. This delay is enough for signalling packets to
arrive on time (1/2 RTT later) to prevent the transmission of messages which
would have arrived after the disconnection (another 1/2 RTT later).

When connectivity becomes available again, the mobile node can restart its
traffic and instruct its peer to act similarly by sending packets with
an \verb#OPT_UNFREEZE# option.

Additional TFRC-level options are used to support further signalling during the
unfreezing phases. The sender uses \verb#OPT_PROBING# and \verb#OPT_RESTORING#
to indicate its current state, while the receiver sends an \verb#OPT_UNFROZEN#
to signal that it is ready for the Probing phase.

As DCCP is an unreliable protocol, option-carrying packets can be silently
lost. Extra care must be taken to ensure both peers are synchronised. This can
be done by exchanging options in a redundant manner. The naive approach of
adding those to every outgoing packet is chosen here. Depending on the
application, this however risks consuming too much capacity and reduction of the
option frequency could be considered. As for the \verb#OPT_FREEZE# and
\verb#OPT_UNFREEZE# options, an implementation should take care of repeating
them on several packets (three in our implementations).

\subsection{Frozen Phase}

When instructed to freeze, either locally or by the remote peer, the sender
enters the Frozen state. In this state, all data transmission ceases. This
ensures that no packet will be lost. It in turn guarantees that the loss event
rate calculated by the receiver will be kept unmodified. The receiver does not
need any specific state for this phase.

The disconnection may however not happen right after freezing, and additional
feedback from the receiver may arrive at the sender. Parameters such as the
RTT $R$, or the receiver rate $X_\mathrm{recv}$ risk being updated. Thus,
while in the Frozen state, the sender ignores all feedback messages. When
entering this state, it also saves the value of $X_\mathrm{recv}$ as it will be
locally modified on every expiration of the \verb#nofeedback# timer.

To efficiently address longer disconnection periods, and provide some sort of
DTN support, it is advisable to additionally increase the connection timeout.
Indeed, disconnections longer than 8 minutes may result in the frozen socket
being prematurely closed.\footnote{According to \cite{rfc4340}, a socket in the
\emph{Respond} state waits a maximum of four Maximum (TCP) Segment Life for
packets before resetting the connection. The Linux 2.6 implementation
generalises this idle timeout to the entire lifespan of the socket.}

\subsection{Restoring Phase}

After receiving a local unfreeze instruction or the \verb#OPT_UNFREEZE# option,
the sender enters the Restoring state. It first restores $X_\mathrm{recv}$.  The
send timer is then reset to resume packet transmission.  As the parameters are
the same as before the disconnection, the sending rate will be restored to its
previous value.

At the same time, it is no longer necessary to completely ignore feedback from
the receiver. It is however needed to keep ignoring the $X_\mathrm{recv}$
reports. Indeed, the receiver rate is measured over at least one RTT. The first
feedback packets are likely to cover part of the disconnected period resulting
in an incorrectly low value for $X_\mathrm{recv}$. Using such value may create
instabilities in the sending rate as it is bound by $2X_\mathrm{recv}$ as
per~\eqref{eq:tfrc-update-x}.

When in the Restoring state, the sender adds an \verb#OPT_RESTORING# option to
all its outgoing packets to put the receiver into the Restoration state.  The
Restoring phase ends when the loss event rate increases or an
\verb#OPT_UNFROZEN# option is received. This option is added by the receiver
after a complete RTT has elapsed, thus signalling that it is no longer
necessary to ignore the value of $X_\mathrm{recv}$ as it will now correctly
reflect the receiver rate.

\subsection{Probing Phase} 

Standard TFRC quickly reacts to a reduction in the available capacity by
responding promptly to an increase in the loss event rate. The
\verb!conservative_! mode outlined by
\cite{2001bansal_slowly_responsive_congestion_control} further increases this
response. Conversely, after idle periods, it is proposed
in~\cite{draft-ietf-dccp-tfrc-faster-restart-06} to increase the sending rate
back to the previously supported maximum at an increased pace by quadrupling the
rate every RTT.\footnote{This draft proposal considers application-limited rates
rather than disconnections; it also does not restore the rate at once as our
Restoring phase does.} There is however no mechanism to quickly adapt to
\emph{better} network conditions. In the Probing state, our sender checks for
such improvement in the new network. This is done only if no loss has occurred
during the Restoring phase. The sender uses the \verb#OPT_PROBING# option to
inform the receiver of its new state. Upon receiving this option, the receiver
enters the Probed state.

This phase is similar to a slow-start. Every RTT, the sending rate is
doubled.  When a loss is detected while it is in the Probed state, the receiver
reinitialises its loss history to match the last measured rate. It first
computes a packet loss rate $p$ equivalent to the observed receiver rate
$X_\mathrm{recv}$. It then reinitialises a complete history of $n$ loss
intervals of the calculated size.

As $p$ is completely recomputed by the receiver on the first loss, it can be
larger, lower or even equal to its previous value. The exit criterion for the
probing phase is therefore based on the expected evolution of the reported loss
event rate, as derived as~\eqref{eq:numerical-p-variation} in
Section~\ref{sec:model}. In a loss-less period, $p$ will never increase. With a
growing loss interval, it will however keep decreasing slightly. The sender
should thus exit the Probing state if
%\begin{gather}
  $\Delta p \notin \left] \Delta p_\mathrm{min}(X_\mathrm{Bps} \cdot R, p_\mathrm{prev}); 0 \right[$, 
%\end{gather}
following~\eqref{eq:numerical-delta-p}. Missing \verb#OPT_PROBING#
options on new packets then takes the receiver out of the Probed state.

It may happen that the sender-recomputed $p$ lies in the acceptable range of
variation. In this case, the sender cannot detect that the Probing phase should
be ended. Some more losses will however be generated during the next RTT. These
losses will prevent $p$ from changing during the next report, thus properly
ending the Probing phase as per the previous criterion.

\section{Performance Evaluation}
\label{freezetfrc:performance}

This section  presents an evaluation of the enhancements proposed in the
previous section. It first compares, in \ns-2 simulations, the behaviour of
Freeze-DCCP/TFRC with that of the unmodified version. It then demonstrates that
the proposed mechanism still retains a satisfying level of fairness to TCP
flows.  Finally, a real experiment, based on a Linux implementation, shows that
our proposal is well suited to improve the QoE of a live video stream
experiencing multiple handovers between heterogeneous technologies.

\subsection{Realistic Handover Simulations}
\label{realistic}

Simulations were run with \ns-2.33. Additional modifications have been made to
the TFRC sender of the DCCP module%
~\cite{2004mattsson_dccp_ns2} %techreport
to implement
the clarified loss average calculation of~\cite{rfc5348}. The
\verb#DCCP/TFRC/Freeze# agent has been implemented by deriving the DCCP/TFRC
C++ class to add the freezing mechanisms described above.

As the impact of disconnections is only relevant to our study at the transport
layer, the underlying wireless technologies are not simulated as such. Rather,
simple wired topologies are used, as suggested by
\cite{2004gurtov_modelling_wireless}. All wireless links are modelled as duplex
links, even the wireless ones. This may not be correct for bi-directional data
scenarios. Such scenarios, however, are not considered here. The
characteristics of the various technologies used in these simulation are taken
from the respective standards and measurement-based literature, and summarised in
\tablename~\ref{tab:characteristics}.

\begin{table}
  \caption{Characteristics of the wireless networks used for
  evaluation purposes.}
  \label{tab:characteristics}
  \centering
  \begin{tabular}{ccc}
    \toprule
    \textbf{Technology} & \textbf{D/L capacity [bps]} & \textbf{Avg. RTT [s]} \\
    \midrule
    UMTS & 384\,k & 250\,m~\cite{2005vacirca_umts_grprs_rtt_measurements} \\
    802.11b/g & 11\,M/54\,M & 20\,m~\cite{2005karapantelakis_ad-hoc_delay_experiments} \\
    802.16 & 9.5\,M~\cite{2007grondalen_wimax_measures} & 80\,m~\cite{2008halepovic_tcp_wimax} \\
    %HSPAs~\cite{2009prokkola_hspa_performance_live_networks} & 2.80\,M &	1.30\,M & 40--46 \\
    \bottomrule
  \end{tabular}
\end{table}

A router is placed between the sender and the receiver. Such a topology allows
to transparently disconnect the link between the router and the receiver without
preventing the sender from trying to transmit packets during the disconnections.
\verb#DropTail# queues with the default buffer size (50 packets) are used.

Disconnections are simulated by manipulating the routing model of \ns-2 with the
\verb#$ns_ rtmodel-at# function. The time of the hand-offs is chosen, once the
system is in a stationary state, from a uniformly distributed variable over a
time period of four RTTs. The generic behaviour of both standard TFRC and our
variant is thus captured. Link characteristics are modified using the
%
\verb#$ns_ bandwidth#
%
and \verb#$ns_ delay# commands.  The simulations were ended after the rates had
settled on the new network. The result have been averaged over 20
runs.

The Freeze-DCCP agent is instructed to suspend its connection locally (\ie, not
using the \verb#OPT_FREEZE# and \verb#OPT_UNFREEZE# options).  The \verb#freeze#
command is given one RTT  before the disconnection is scheduled to happen (as
suggested by~\cite{2000goff_freezetcp}). The \verb#unfreeze# instruction is
given 0.1\,ms after the network link is reconnected.

The number of losses upon reconnection, as well as the wasted capacity, are shown
on \tablename~\ref{tab:sim-mip-nlost-nwasted}. As Freeze-DCCP/TFRC did not
lose any packet, this information is omitted.  The wasted capacity has
been estimated by comparing TFRC's actual rate $X$ to what is achievable in the
steady state (\tablename~\ref{tab:stationary-params}), then converted in number
of 500\,B packets. \figurename~\ref{fig:sim-realistic} illustrates these
figures by comparing how both regular DCCP and the Freeze-enabled version
perform in key example scenarios.

\begin{table}[tb]
  \centering

  \caption[Comparison of DCCP/TFRC and Freeze-DCCP/TFRC in simulated MIPv6
  handovers]{Simulated MIPv6 handovers performance impact for DCCP/TFRC
  and Freeze-DCCP/TFRC (grey).}

  \addtolength{\tabcolsep}{-.5ex}
  \label{tab:sim-mip-nlost-nwasted}
  \begin{tabular}{ccccc}
    \toprule
    \multirow{2}{*}{\backslashbox{\textbf{from}}{\textbf{to}}} & \multirow{2}{*}{UMTS} &
    \multirow{2}{*}{802.16} & \multicolumn{2}{c}{802.11} \\
    & & & b & g \\
    \midrule
    \multicolumn{5}{c}{\textbf{Packet losses (DCCP/TFRC only)}} \\
    \midrule
    \input{real-sim-regular-nlost.double}
    \midrule
    \multicolumn{5}{c}{\textbf{Wasted capacity [Number of 500\,B packets]}} \\
    \midrule
    \input{real-sim-nwasted}
    \bottomrule
  \end{tabular}
\end{table}

\begin{figure}[tb]
  \begin{center}
    \includegraphics[width=\columnwidth]{comparison}
  \end{center}

  \caption[Comparison of the rate of DCCP/TFRC\ and the Freeze-enabled version
  in typical examples of MIPv6 horizontal or vertical handovers]{Comparison of
  the rate of DCCP/TFRC and the Freeze-enabled version in typical examples
  of MIPv6 horizontal or vertical handovers.}
  
  \label{fig:sim-realistic}
\end{figure}

Two cases stand out in \tablename~\ref{tab:sim-mip-nlost-nwasted} where the
average amount of wasted capacity is larger with our proposal than with standard
TFRC. These correspond to pathological cases for our \ns-2 implementation where
either the Recovery or the Probing phase experiences losses too early. The rate
reported by the receiver does not cover a full RTT (802.11 g to 802.16), or the
probing phase terminates before having discovered the network capacity (UMTS to
802.11 b). Future work should address this type of situation by using other or
additional metrics, rather than just losses, to drive the Restoration/Probing
phases.

Overall, Freeze-DCCP/TFRC quickly restores an acceptable rate for the
application, and greatly reduces the overall under-usage of the available
capacity upon reconnection. It also prevents traffic after the hand-off to
unnecessarily use the rest of the network.

\subsection{Fairness to TCP Flows}

TFRC was designed to quickly respond to reductions of the capacity. The
restoring and probing features of Freeze-DCCP/TFRC, however, aggressively test
and use the network. TCP-friendliness is however a key property of TFRC, which
it is desirable to retain. It is therefore important to check that our additions
do not make the protocol too greedy. Though~\cite{2007briscoe_fairness} argues
that usage fairness should not be based on rate comparisons, such an approach is
still commonly accepted, and we use it here.

The criterion to evaluate TCP-fairness is the ratio of the average capacity
occupation of Freeze-DCCP/TFRC to that of concurrent TCP flows. The samples, taken
after the reconnection, have been averaged over 100\,s, discarding the initial
rate settlement period.

\tablename~\ref{tab:tcpfairness} compares the average fairness of a
\mbox{(Freeze-)DCCP/TFRC} flow to a concurrent TCP stream, as observed after the
reconnection for the studied handover scenarios. The proposed improvement appears
to be reasonably fair to TCP flows in various scenarios including vertical
handovers to technologies with higher or lower capacities. In some cases it is
even too fair, not competing aggressively enough for the network. A similar
behaviour is however also observed for the regular DCCP/TFRC, and is not a
result of our changes.

\begin{table}
  \centering

  \caption[Fairness comparison of (Freeze-)DCCP/TFRC to TCP after a
  handover]{Fairness comparison of both standard TFRC and the Freeze-enabled
  proposal to TCP after a handover (taking network parameters from
  \tablename~\ref{tab:characteristics}). Values in the range $[0.5;2]$ are
  considered ``reasonably fair''~\cite{rfc5348}.}

  \label{tab:tcpfairness}
  \begin{tabular}{ccccc}
    \toprule
    \multirow{2}{*}{\backslashbox{\textbf{from}}{\textbf{to}}} & \multirow{2}{*}{UMTS} & \multirow{2}{*}{802.16} & \multicolumn{2}{c}{802.11} \\
    & & & b & g \\
    \midrule
    \multicolumn{5}{c}{\textbf{Standard DCCP/TFRC}} \\
    \cmidrule{1-5}
    \input{fairness-regular}
    \midrule
    \multicolumn{5}{c}{\textbf{Freeze-DCCP/TFRC}} \\
    \cmidrule{1-5}
    \input{fairness-freeze}
    \bottomrule
  \end{tabular}
\end{table}

\subsection{QoE of Mobile Video Streaming}

To explore the actual performance improvements of our proposal, we used an OMF
testbed~\cite{2010rakotoarivelo_omf} to emulate vertical handovers and observe
the impact on the quality of a video stream.  An implementation of
Freeze-DCCP/TFRC was developed in the Linux kernel\footnote{%
%
We used the Net:DCCP tree %techreport
(\url{http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=summary}),%techreport
forked off of vanilla version 2.6.34-rc5, as a starting point. %techreport
%
A Git branch containing these modifications is available at
\url{http://github.com/shtrom/linux-2.6/tree/freezedccp}.} and used here.

The scenario is depicted in
\figurename~\ref{fig:freezetfrc_psnr_scenario}.\footnote{The OMF scripts are
available at
\url{http://omf.mytestbed.net/projects/omf-case-studies/wiki/FreezeDccpQoE}.} A
user, initially at home ($t_0$), receives a video stream on their mobile
terminal connected to their home Wi-Fi network connected to their DSL link
(1\,Mbps).  They decide to get a coffee from the corner shop. On the way there,
the mobile terminal loses its connectivity to the home network, and hands off to
a shared 3G network ($t_1$; 500\,kbps). The coffee shop has a public wireless network
(\eg, a shared Internet access, offering 700\,kbps of capacity), to which the
device connects when it arrives in range ($t_2$).  With their coffee in hand,
the user then heads back home, losing connectivity to the public Wi-Fi network
and performing a new handover to 3G at $t_3$ before finally reconnecting to
their home network at $t_4$.  Throughout the streaming period, the device thus
goes through several handovers between various wireless networks with different
capacities and delays.

\begin{figure}[tb]
  \centering

  \resizebox{.75\columnwidth}{!}{\input{freezetfrc_psnr_scenario.pdftex_t}}

  \caption[Scenario for the evaluation of Freeze-DCCP/TFRC improvements on
  application quality]{Scenario for the evaluation of Freeze-DCCP/TFRC
  improvements on application quality. A user viewing a video stream on their
  mobile device goes out for a coffee then comes back home. In the process,
  networks with heterogeneous characteristics are visited.}

  \label{fig:freezetfrc_psnr_scenario}
\end{figure}

In this experiment, a video file, encoded and packetised using the H.264 codec
with a 1\,Mbps bit-rate, is sent using a specially patched version of
Iperf%
~\cite{2004gates_iperf2}%techreport
\footnote{This version, supporting both DCCP and
OML, is available from
\url{http://www.nicta.com.au/people/mehanio/freezedccp\#iperf-dccp-oml}.} to a
custom receiver application. Both endpoints provide information about the
sending or receiving rates. The custom receiver identifies lost packets and
computes a moving average of the PSNR over 24 frames ($\simeq1$\,s), 
%
%as the $\log$ of the mean square error between the image and its reference. %IEEEtran%elsarticle
%
%\begin{comment} %IEEEtran%elsarticle
%
using the \sysfun{compare} tool of the ImageMagick
package~\cite{2005still_imagemagick}.\footnote{This tool computes the PSNR as
the $\log$ of the mean square error between an image and its reference.}
%
%\end{comment} %IEEEtran%elsarticle
%
Both sender and receiver have been instrumented with the OML
toolkit~\cite{2013mehani_instrumentation_framework}. This allows them to report
readings of these metrics in real time for analysis or display.

Our OMF testbed currently only supports 802.11-based wireless networks.
However, only a limited set of parameters of the underlying network is relevant
at the transport layer. Therefore, as for the previous section, we follow the
suggestion of~\cite{2004gurtov_modelling_wireless} and emulate the conditions of
wireless technologies in different networks by shaping the available
capacity using Linux' traffic control tools~\cite{2004lartc_howto},  and
regulating forwarding delays using NetEm%
~\cite{2005hemminger_netem}%techreport
.

The results, averaged over 8 runs of our scenario, comparing the PSNR of the
video stream when using Freeze-DCCP/TFRC to that with the standard version, are
shown in \figurename~\ref{fig:freezetfrc_psnr}. They show that the use of
Freeze-DCCP/TFRC results in a reduced but stable QoE when on those networks
which cannot support 1\,Mbps streams, as our proposal is able to adapt much
faster and use close to the full available path capacity to carry application
data. In comparison, the PSNR of a video stream supported by the regular
DCCP/TFRC reduces to a minimum (a PSNR of 7\,dB is that of a purely random
image), and takes a long time (up to the complete visit duration of a network)
to restore to a better level. In addition, Freeze-DCCP/TFRC does not suffer from
the oscillations which appear for the standard version when visiting the Café's
Wi-Fi network. We hypothesise that it is due to the probing mechanism finding
the capacity of the new network more accurately, and its estimates not being
biased by measurements from the previous network. It might be interesting to
instrument the kernel code of DCCP (\eg, TFRC's loss history) in order to
investigate this further.

\begin{figure}[tb]
  \centering
  \includegraphics[width=.75\columnwidth]{freezetfrc_psnr}
  \caption[PSNR comparison for a video stream using TFRC or Freeze-TFRC in
  mobility situations]{PSNR comparison for a video stream using TFRC or
  Freeze-TFRC in mobility situations. Averages over 8 runs; error bars
  indicate the standard error.}
  \label{fig:freezetfrc_psnr}
\end{figure}



\section{Conclusion and Future Work}
\label{freezetfrc:conclusion}

In this article, we have first identified the issues that TFRC faces in
mobility situations.  We have numerically modelled the losses and subsequent
under-usage of the available capacity that it experiences in those cases. This
model allowed us to evaluate the performance improvements that could be expected
from a system with a better awareness and handling of disconnections.  We thus
proposed Freeze-DCCP/TFRC, an extension of the TFRC congestion control
mechanism used by DCCP, to approach these possible performance gains. This
proposal is aimed at uses of DCCP in situations where network connectivity may
periodically not be available for varying periods of time, and the access
networks' characteristics may widely vary between disconnections.

Freeze-DCCP/TFRC was both implemented in \ns-2 and Linux. Simulation results
have shown that it is possible to prevent handover-induced losses, to restore
the rate faster when reconnecting to a link with lower or similar capacities and
to adapt more quickly to higher capacities.  Additionally, we confirmed that our
proposal maintains the important TFRC's property of being fair to concurrent TCP
flows.  We have also experimentally shown that our proposal can significantly
improve the performance quality of streaming applications when disconnections
are predictable, for example, for IP mobility or.  Though the proposed
modifications were designed with real-time applications over DCCP in mind, we
believe they are versatile enough in terms of rate adaptation and packet loss
avoidance to also benefit other types of traffic.

Additional work may however be needed for the proposed extension to be used in
real deployments.  First, it would be desirable to decouple the freezing
mechanism, which caters for hand-off-induced disconnections, and the probing
phase, which deals with heterogeneous paths. Indeed, only the latter is needed
for make-before-break handovers. Second, the current probing mechanism assumes
packets are lost only when the capacity of the new network is reached.  Other
methods of detecting that the current rate matches the available path capacity
should be explored.  Both in-band solutions, such as MBTFRC, and out-of-band
ones could be considered.

%\bibliographystyle{model1-num-names} %elsarticle
%\bibliography{2012mehani_rate_control_heterogeneous_handovers} %elsarticle
\printbibliography %IEEEtran%techreport

\end{document}

fairness-freeze.tex
UMTS	& 0.6	& 0.3	& 0.2	& 0.1	\\
802.16	& 1.6	& 1.3	& 1.1	& 0.9	\\
802.11b	& 1.3	& 1	& 0.9	& 0.7	\\
802.11g	& 1.5	& 1.2	& 1	& 1.1	\\

fairness-regular.tex
UMTS	& 1.3	& 0.7	& 0.4	& 0.3	\\
802.16	& 1.1	& 1	& 0.9	& 0.8	\\
802.11b	& 1.2	& 1	& 1	& 0.8	\\
802.11g	& 1.3	& 1.1	& 1	& 1.1	\\

model-mip-nlost.tex
UMTS	& 306	& 236	& 226	& 224	\\
802.16	& 2760	& 2614	& 2614	& 2614	\\
802.11b	& 1080	& 1078	& 1078	& 1078	\\
802.11g	& 2909	& 2907	& 2907	& 2907	\\

model-mip-nwasted-magnitude.tex
UMTS	& 0	& $8\times10^4$	& $3\times10^2$	& $1\times10^5$	\\
802.16	& 0	& $5\times10^2$	& $2\times10^2$	& $1\times10^3$	\\
802.11b	& 0	& 0	& $1\times10^3$	& $5\times10^4$	\\
802.11g	& 0	& 0	& 0	& $5\times10^3$	\\

real-sim-nwasted.tex
UMTS & 50.5	& 54018.05	& 2190.45	& 92156.1	\\
\rowcolor{gray!20} --- & 13.4	& 3607.9	& 9342.75	& 89328.6	\\
802.16 & 12.45	& 1827.95	& 603.05	& 4185.75	\\
\rowcolor{gray!20} --- & 5	& 591.15	& 150.9	& 1520.35	\\
802.11b & 150.45	& 28314	& 2101.75	& 57970.65	\\
\rowcolor{gray!20} --- & 0	& 15278	& 47.45	& 1045.05	\\
802.11g & 42.5	& 2104.3	& 943.4	& 4313	\\
\rowcolor{gray!20} --- & 0	& 7172.75	& 46.5	& 188.45	\\

real-sim-regular-nlost.double.tex
UMTS	& 253.3	& 269.8	& 273.6	& 275.4	\\
802.16	& 1732.3	& 1734.6	& 1734.6	& 1734.6	\\
802.11b	& 856	& 855.5	& 855.3	& 855.3	\\
802.11g	& 2470.9	& 2470.4	& 2470.2	& 2470.1	\\

2012mehani_rate_control_heterogeneous_handovers.bbl
% $ biblatex auxiliary file $
% $ biblatex version 2.2 $
% Do not modify the above lines!
%
% This is an auxiliary file used by the 'biblatex' package.
% This file may safely be deleted. It will be recreated as
% required.
%
\begingroup
\makeatletter
\@ifundefined{ver@biblatex.sty}
  {\@latex@error
     {Missing 'biblatex' package}
     {The bibliography requires the 'biblatex' package.}
      \aftergroup\endinput}
  {}
\endgroup

\entry{rfc6275}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Johnson}{J.}%
     {David~B.}{D.~B.}%
     {}{}%
     {}{}}%
    {{}%
     {Perkins}{P.}%
     {Charles~E.}{C.~E.}%
     {}{}%
     {}{}}%
    {{}%
     {Arkko}{A.}%
     {Jari}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{ietf, ipv6, mipv6, mobility, rfc}
  \strng{namehash}{JDBPCEAJ1}
  \strng{fullhash}{JDBPCEAJ1}
  \field{abstract}{%
  This document specifies Mobile IPv6, a protocol that allows nodes to remain
  reachable while moving around in the IPv6 Internet. Each mobile node is
  always identified by its home address, regardless of its current point of
  attachment to the Internet. While situated away from its home, a mobile node
  is also associated with a care-of address, which provides information about
  the mobile node\\x27s current location. IPv6 packets addressed to a mobile
  node\\x27s home address are transparently routed to its care-of address. The
  protocol enables IPv6 nodes to cache the binding of a mobile node\\x27s home
  address with its care-of address, and to then send any packets destined for
  the mobile node directly to it at this care-of address. To support this
  operation, Mobile IPv6 defines a new IPv6 protocol and a new destination
  option. All IPv6 nodes, whether mobile or stationary, can communicate with
  mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]%
  }
  \field{howpublished}{Internet Requests for Comment}
  \field{issn}{2070-1721}
  \field{number}{6275}
  \field{title}{Mobility Support in {IP}v6}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc6275.txt
  \endverb
  \field{type}{RFC}
  \field{month}{07}
  \field{year}{2011}
\endentry

\entry{2002tsaoussidis_tcp_mobility_open_issues}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Tsaoussidis}{T.}%
     {Vassilis}{V.}%
     {}{}%
     {}{}}%
    {{}%
     {Matta}{M.}%
     {Ibrahim}{I.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, energy, mobility, tcp, wireless}
  \strng{namehash}{TVMI1}
  \strng{fullhash}{TVMI1}
  \field{abstract}{%
  We discuss the design principles of TCP within the context of heterogeneous
  wired/wireless networks and mobile networking. We identify three shortcomings
  in TCP's behavior: (i) the protocol's error detection mechanism, which does
  not distinguish different types of errors and thus does not suffice for
  heterogeneous wired/wireless environments, (ii) the error recovery, which is
  not responsive to the distinctive characteristics of wireless networks such
  as transient or burst errors due to handoffs and fading channels, and (iii)
  the protocol strategy, which does not control the tradeoff between
  performance measures such as goodput and energy consumption, and often
  entails a wasteful effort of retransmission and energy expenditure. We
  discuss a solution-framework based on selected research proposals and the
  associated evaluation criteria for the suggested modifications. We highlight
  an important angle that did not attract the required attention so far: the
  need for new performance metrics, appropriate for evaluating the impact of
  protocol strategies on battery-powered devices.%
  }
  \verb{doi}
  \verb 10.1002/wcm.30
  \endverb
  \field{issn}{1530-8677}
  \field{number}{1}
  \field{pages}{3\bibrangedash 20}
  \field{title}{Open Issues on {TCP} for Mobile Computing}
  \verb{url}
  \verb http://dx.doi.org/10.1002/wcm.30
  \endverb
  \field{volume}{2}
  \field{journaltitle}{Wireless Communications and Mobile Computing}
  \field{month}{02}
  \field{year}{2002}
\endentry

\entry{1999floyd_end2end_congestion_control}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Fall}{F.}%
     {Kevin}{K.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, end2end, internet, transport}
  \strng{namehash}{FSFK1}
  \strng{fullhash}{FSFK1}
  \field{abstract}{%
  This paper considers the potentially negative impacts of an increasing
  deployment of non-congestion-controlled best-effort traffic on the Internet.
  These negative impacts range from extreme unfairness against competing TCP
  traffic to the potential for congestion collapse. To promote the inclusion of
  end-to-end congestion control in the design of future protocols using
  best-effort traffic, we argue that router mechanisms are needed to identify
  and restrict the bandwidth of selected high-bandwidth best-effort flows in
  times of congestion. The paper discusses several general approaches for
  identifying those flows suitable for bandwidth regulation. These approaches
  are to identify a high-bandwidth flow in times of congestion as unresponsive,
  ” not TCP-friendly”, or simply using disproportionate bandwidth. A flow
  that is not ” TCP-friendly” is one whose long-term arrival rate exceeds
  that of any conformant TCP in the same circumstances. An unresponsive flow is
  one failing to reduce its offered load at a router in response to an
  increased packet drop rate, and a disproportionate-bandwidth flow is one that
  uses considerably more bandwidth than other flows in a time of congestion%
  }
  \verb{doi}
  \verb 10.1109/90.793002
  \endverb
  \field{issn}{1063-6692}
  \field{number}{4}
  \field{pages}{458\bibrangedash 472}
  \field{title}{Promoting the Use of End-to-end Congestion Control in the
  Internet}
  \verb{url}
  \verb http://icir.org/floyd/papers/collapse.may99.pdf
  \endverb
  \field{volume}{7}
  \field{journaltitle}{IEEE/ACM Transactions on Networking}
  \field{month}{08}
  \field{year}{1999}
\endentry

\entry{2006kohler_dccp}{article}{}
  \name{author}{3}{}{%
    {{}%
     {Kohler}{K.}%
     {Eddie}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Handley}{H.}%
     {Mark}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, dccp, tcp-like, tfrc, transport}
  \strng{namehash}{KEHMFS1}
  \strng{fullhash}{KEHMFS1}
  \field{abstract}{%
  Fast-growing Internet applications like streaming media and telephony prefer
  timeliness to reliability, making TCP a poor fit. Unfortunately, UDP, the
  natural alternative, lacks congestion control. High-bandwidth UDP
  applications must implement congestion control themselves-a difficult task-or
  risk rendering congested networks unusable. We set out to ease the safe
  deployment of these applications by designing a congestion-controlled
  unreliable transport protocol . The outcome, the Datagram Congestion Control
  Protocol or DCCP, adds to a UDP-like foundation the minimum mechanisms
  necessary to support congestion control. We thought those mechanisms would
  resemble TCP's, but without reliability and, especially, cumulative
  acknowledgements, we had to reconsider almost every aspect of TCP's design.
  The resulting protocol sheds light on how congestion control interacts with
  unreliable transport, how modern network constraints impact protocol design,
  and how TCP's reliable bytestream semantics intertwine with its other
  mechanisms, including congestion control.%
  }
  \verb{doi}
  \verb 10.1145/1151659.1159918
  \endverb
  \field{howpublished}{SIGCOMM 2006, Proceedings of the Conference on
  Applications, Technologies, Architectures, and Protocols for Computer
  Communication}
  \field{issn}{0146-4833}
  \field{number}{4}
  \field{pages}{27\bibrangedash 38}
  \field{title}{Designing {DCCP}: Congestion Control Without Reliability}
  \verb{url}
  \verb http://www.cs.ucla.edu/~kohler/pubs/kohler06designing.pdf
  \endverb
  \field{volume}{36}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{10}
  \field{year}{2006}
\endentry

\entry{rfc4340}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Kohler}{K.}%
     {Eddie}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Handley}{H.}%
     {Mark}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, dccp, ietf, rfc, transport}
  \strng{namehash}{KEHMFS1}
  \strng{fullhash}{KEHMFS1}
  \field{abstract}{%
  The Datagram Congestion Control Protocol (DCCP) is a transport protocol that
  provides bidirectional unicast connections of congestion-controlled
  unreliable datagrams. DCCP is suitable for applications that transfer fairly
  large amount sof data and that can benefit from control over the tradeoff
  between timeliness and reliability.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{4340}
  \field{title}{Datagram Congestion Control Protocol ({DCCP})}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc4340.txt
  \endverb
  \field{type}{RFC}
  \field{month}{03}
  \field{year}{2006}
\endentry

\entry{2000floyd_equation-based_unicast}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Handley}{H.}%
     {Mark}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Padhye}{P.}%
     {Jitendra}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Widmer}{W.}%
     {J\"{o}rg}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, equationbased, ratebased, tfrc, transport}
  \strng{namehash}{FSHMPJ+1}
  \strng{fullhash}{FSHMPJWJ1}
  \field{abstract}{%
  This paper proposes a mechanism for equation-based congestion control for
  unicast traffic. Most best-effort traffic in the current Internet is
  well-served by the dominant transport protocol, TCP. However, traffic such as
  best-effort unicast streaming multimedia could find use for a TCP-friendly
  congestion control mechanism that refrains from reducing the sending rate in
  half in response to a single packet drop. With our mechanism, the sender
  explicitly adjusts its sending rate as a function of the measured rate of
  loss events, where a loss event consists of one or more packets dropped
  within a single round-trip time. We use both simulations and experiments over
  the Internet to explore performance.%
  }
  \verb{doi}
  \verb 10.1145/347057.347397
  \endverb
  \field{howpublished}{SIGCOMM 2000, Proceedings of the Conference on
  Applications, Technologies, Architectures, and Protocols for Computer
  Communication}
  \field{isbn}{1-58113-223-9}
  \field{issn}{0146-4833}
  \field{number}{4}
  \field{pages}{43\bibrangedash 56}
  \field{title}{Equation-Based Congestion Control for Unicast Applications}
  \verb{url}
  \verb http://www.icir.org/tfrc/tcp-friendly.pdf
  \endverb
  \field{volume}{30}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{10}
  \field{year}{2000}
\endentry

\entry{2003widmer_equation-based_unicast_multicast}{thesis}{}
  \name{author}{1}{}{%
    {{}%
     {Widmer}{W.}%
     {J\"{o}rg}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, equationbased, ratebased, tfrc}
  \strng{namehash}{WJ1}
  \strng{fullhash}{WJ1}
  \field{abstract}{%
  We believe that the emergence of congestion control mechanisms for
  relatively-smooth congestion control for unicast and multicast traffic can
  play a key role in preventing the degradation of end-to-end congestion
  control in the public Internet, by providing a viable alternative for
  multimedia flows that would otherwise be tempted to avoid end-to-end
  congestion control altogether. The design of good congestion control
  mechanisms is a hard problem, even more so for multicast environments where
  scalability issues are much more of a concern than for unicast. In this
  dissertation, equation-based congestion control is presented as an
  alternative form of congestion control to the well-known TCP protocol. We
  focus on areas of equation-based congestion control which were not yet well
  understood and for which no adequate solutions existed. Starting from a
  unicast congestion control mechanism which in contrast to TCP provides smooth
  rate changes, we extend equation-based congestion control in several ways. We
  investigate how it can work together with applications which can only operate
  in a very limited region of available bandwidth and whose rate can thus not
  be adapted to the network conditions in the usual way. Such a congestion
  control mechanism can also complement conventional equation-based congestion
  control in regimes where available bandwidth is too low for further rate
  reduction. When extending unicast congestion control to multicast, it is of
  paramount importance to ensure that changes in the network conditions
  anywhere in the multicast tree are reported back to the sender as quickly as
  possible to allow the sender to adjust the rate accordingly. A scalable
  feedback mechanism that allows timely congestion feedback in the face of
  potentially very large receiver sets is one of the contributions of this
  dissertation. But also other components of a congestion control protocol,
  such as the rate increase/decrease policy or the slow-start mechanism, need
  to be adjusted to be able to use them in a multicast environment. Our
  resulting multicast congestion control protocol was implemented in a
  simulation environment for extensive protocol testing and turned into a
  library for the use in real-world applications. In addition, a simple video
  transmission tool was built for test purposes that uses this congestion
  control library.%
  }
  \field{title}{Equation-Based Congestion Control for Unicast and Multicast
  Data Streams}
  \verb{url}
  \verb http://icapeople.epfl.ch/widmer/files/Widmer2003a.pdf
  \endverb
  \field{type}{phdthesis}
  \field{month}{05}
  \field{year}{2003}
\endentry

\entry{rfc5348}{report}{}
  \name{author}{4}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Handley}{H.}%
     {Mark}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Padhye}{P.}%
     {Jitendra}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Widmer}{W.}%
     {J\"{o}rg}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, ietf, rfc, tfrc, transport}
  \strng{namehash}{FSHMPJ+1}
  \strng{fullhash}{FSHMPJWJ1}
  \field{abstract}{%
  This document specifies TCP Friendly Rate Control (TFRC). TFRC is a
  congestion control mechanism for unicast flows operating in a best- effort
  Internet environment. It is reasonably fair when competing for bandwidth with
  TCP flows,but has a much lower variation of throughput over time compared
  with TCP, making it more suitable for applications such as streaming media
  where a relatively smooth sending rate is of importance. This document
  obsoletes RFC 3448 and updates RFC 4342.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{5348}
  \field{title}{{TCP} Friendly Rate Control ({TFRC}): Protocol Specification}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc5348.txt
  \endverb
  \field{type}{RFC}
  \field{month}{09}
  \field{year}{2008}
\endentry

\entry{2004gurtov_tfrc_vertical_handovers}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Gurtov}{G.}%
     {Andrei}{A.}%
     {}{}%
     {}{}}%
    {{}%
     {Korhonen}{K.}%
     {Jouni}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{handoff, mobility, tfrc, transport, wireless}
  \strng{namehash}{GAKJ1}
  \strng{fullhash}{GAKJ1}
  \field{abstract}{%
  An intersystem or vertical handover is a key enabling mechanism for next
  generations of mobile communication systems. A vertical handover can cause an
  abrupt change of up to two orders of magnitude in link bandwidth and latency.
  It is hard for end-to-end congestion control to adapt promptly to such
  changes. This is especially a concern for slowly responsive congestion
  control algorithms, such as TCP-Friendly Rate Control (TFRC). TFRC is
  designed to provide a smooth transmission rate for real-time applications
  and, therefore, is less responsive to changes in network conditions than TCP.
  Using measurements and simulation, we show that TFRC has significant
  difficulties adapting after a vertical handover. TFRC receives only a
  fraction of TCP throughput over a fast link, but can be grossly unfair to
  concurrent TCP flows after handover to a slow link. We show that two
  proposals based on overbuffering and an explicit handover notification are
  effective solutions to these problems. Using them, TFRC can quickly adapt to
  new link characteristics after a handover, while otherwise maintaining a
  smooth transmission rate.%
  }
  \verb{doi}
  \verb 10.1145/1031483.1031494
  \endverb
  \field{issn}{1559-1662}
  \field{number}{3}
  \field{pages}{73+}
  \field{title}{Effect of Vertical Handovers on Performance of {TCP}-Friendly
  Rate Control}
  \verb{url}
  \verb http://www.cs.helsinki.fi/u/gurtov/papers/vho.pdf
  \endverb
  \field{volume}{8}
  \field{journaltitle}{SIGMOBILE Mobile Computing and Communications Review}
  \field{month}{07}
  \field{year}{2004}
\endentry

\entry{2000goff_freezetcp}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Goff}{G.}%
     {Tom}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Moronski}{M.}%
     {James}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Phatak}{P.}%
     {Dhananjay~S.}{D.~S.}%
     {}{}%
     {}{}}%
    {{}%
     {Gupta}{G.}%
     {Vipul}{V.}%
     {}{}%
     {}{}}%
  }
  \keyw{freezetcp, mobility, tcp, transport, wireless}
  \strng{namehash}{GTMJPDS+1}
  \strng{fullhash}{GTMJPDSGV1}
  \field{abstract}{%
  Optimizing TCP (transport layer) for mobility has been researched
  extensively. We present a brief summary of existing results which indicates
  that most schemes require intermediaries (such as base stations) to monitor
  the TCP traffic and actively participate in flow control in order to enhance
  performance. Although these methods simulate end-to-end semantics, they do
  not comprise true end-to-end signaling. As a result, these techniques are not
  applicable when the IP payload is encrypted. For instance IPSEC, which is
  expected to be standard under IPv6, encrypts the entire IP payload making it
  impossible for intermediaries to monitor TCP traffic unless those entities
  are part of the security association. In addition, these schemes require
  changes (in the TCP/IP code) at intermediate nodes making it difficult for
  the mobile clients to inter-operate with the existing infrastructure. In this
  paper we explore the ” freeze-TCP” mechanism which is a true end-to-end
  scheme and does not require the involvement of any intermediaries (such as
  base stations) for flow control. Furthermore, this scheme does not require
  any changes on the ” sender side” or intermediate routers; changes in TCP
  code are restricted to the mobile client side, making it possible to fully
  inter-operate with the existing infrastructure. We then outline a method
  which integrates the best attributes of freeze-TCP and some existing
  solutions. Performance results highlight the importance of pro-active
  action/signaling by the mobile-host. The data indicate that in most cases,
  simply reacting to disconnections tends to yield lower performance than
  pro-active mechanisms such as freeze-TCP%
  }
  \field{booktitle}{INFOCOM 2000}
  \verb{doi}
  \verb 10.1109/INFCOM.2000.832552
  \endverb
  \field{isbn}{0-7803-5880-5}
  \field{pages}{1537\bibrangedash 1545}
  \field{title}{Freeze-{TCP}: A True End-to-end {TCP} Enhancement Mechanism for
  Mobile Environments}
  \verb{url}
  \verb http://www.cs.umbc.edu/~phatak/publications/ftcp.pdf
  \endverb
  \field{volume}{3}
  \field{journaltitle}{INFOCOM 2000. Nineteenth Annual Joint Conference of the
  IEEE Computer and Communications Societies. Proceedings. IEEE}
  \field{month}{03}
  \field{year}{2000}
\endentry

\entry{2006montavont_mipv6_link-network_interaction}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Montavont}{M.}%
     {Nicolas}{N.}%
     {}{}%
     {}{}}%
    {{}%
     {No\"{e}l}{N.}%
     {Thomas}{T.}%
     {}{}%
     {}{}}%
  }
  \keyw{cross-layer, handoff, ipv6, mobility}
  \strng{namehash}{MNNT1}
  \strng{fullhash}{MNNT1}
  \field{abstract}{%
  The evolution of both Internet and cellular networks tends toward an IP
  mobility scheme for data and voice communication. Mobile IPv6 has the general
  purpose of managing mobility between IPv6 networks and it does not focus on
  optimizing heterogeneous interfaces usage. Yet, new handled devices usually
  come with more than one means of connecting to the network. We therefore
  propose the establishment of a strong interaction between link and network
  layers which would enable anticipation of both vertical and horizontal
  handover. We also present results from innovative scenarios for all of the
  mechanisms we propose.%
  }
  \verb{doi}
  \verb 10.1016/j.pmcj.2006.02.001
  \endverb
  \field{issn}{1574-1192}
  \field{number}{3}
  \field{pages}{233\bibrangedash 261}
  \field{title}{Stronger Interaction Between Link Layer and Network Layer for
  an Optimized Mobility Management in Heterogeneous {IP}v6 Networks}
  \verb{url}
  \verb http://dx.doi.org/10.1016/j.pmcj.2006.02.001
  \endverb
  \field{volume}{2}
  \field{journaltitle}{Pervasive and Mobile Computing}
  \field{month}{09}
  \field{year}{2006}
\endentry

\entry{2008kilkki_qoe}{article}{}
  \name{author}{1}{}{%
    {{}%
     {Kilkki}{K.}%
     {Kalevi}{K.}%
     {}{}%
     {}{}}%
  }
  \keyw{qoe}
  \strng{namehash}{KK1}
  \strng{fullhash}{KK1}
  \field{abstract}{%
  Communications ecosystem covers a huge area from technical issues to business
  models and human behaviour. Due to this extreme diversity various societies
  need to discuss with each other, each of them using their own language.
  Engineers talk about network performance and quality of service, business
  people talk about average revenue per user and customer churn while
  behavioural scientists talk about happiness and experiences. Thus, everyone
  who wants to understand, or even analyze, the whole ecosystem, has to deal
  with all these diverse issues. In addition to the apparent communication
  problems, the main challenges of ecosystem analysis are to realistically
  model human behaviour, and to efficiently combine the models developed for
  different domains. A central concept when solving these problems is quality
  of experience (QoE). This paper sheds light on the role of QoE by means of a
  common framework that covers the whole communications ecosystem.
  Additionally, a research agenda for a holistic ecosystem analysis is
  outlined.%
  }
  \field{number}{5}
  \field{pages}{615\bibrangedash 624}
  \field{title}{Quality of Experience in Communications Ecosystem}
  \verb{url}
  \verb http://www.jucs.org/jucs_14_5/quality_of_experience_in/jucs_14_05_0615_
  \verb 0624_kilkki.pdf
  \endverb
  \field{volume}{14}
  \field{journaltitle}{Journal of Universal Computer Science}
  \field{month}{03}
  \field{year}{2008}
\endentry

\entry{2001ansi_psnr}{report}{}
  \name{author}{1}{}{%
    {{}%
     {{ANSI T1.TR.74-2001}}{A.}%
     {}{}%
     {}{}%
     {}{}}%
  }
  \keyw{ansi, metrics, psnr, video}
  \strng{namehash}{A1}
  \strng{fullhash}{A1}
  \field{abstract}{%
  This document provides a draft of the technical report for measuring the
  peak-signal-to-noise-ratio (PSNR) of one-way video signals.%
  }
  \field{howpublished}{Draft technical report}
  \field{number}{T1.TR.74-2001}
  \field{title}{Objective Video Quality Measurement Using a
  Peak-Signal-to-Noise-Ratio ({PSNR}) Full Reference Technique}
  \verb{url}
  \verb http://webstore.ansi.org/RecordDetail.aspx?sku=T1.TR.74-2001
  \endverb
  \field{type}{techreport}
  \field{year}{2001}
\endentry

\entry{2010rakotoarivelo_omf}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Rakotoarivelo}{R.}%
     {Thierry}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Ott}{O.}%
     {Maximilian}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Jourjon}{J.}%
     {Guillaume}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Seskar}{S.}%
     {Ivan}{I.}%
     {}{}%
     {}{}}%
  }
  \keyw{experiment, federation, network, omf, oml, testbed}
  \strng{namehash}{RTOMJG+1}
  \strng{fullhash}{RTOMJGSI1}
  \field{abstract}{%
  Networking testbeds are playing an increasingly important role in the
  development of new communication technologies. Testbeds are traditionally
  built for a particular project or to study a specific technology. An
  alternative approach is to federate existing testbeds to a) cater for
  experimenter needs which cannot be fullled by a single testbed, and b)
  provide a wider variety of environmental settings at different scales. These
  heterogenous settings allow the study of new approaches in environments
  similar to what one finds in the real world.%
  }
  \verb{doi}
  \verb 10.1145/1713254.1713267
  \endverb
  \field{issn}{0163-5980}
  \field{number}{4}
  \field{pages}{54\bibrangedash 59}
  \field{title}{{OMF}: A Control and Management Framework for Networking
  Nestbeds}
  \verb{url}
  \verb http://www.nicta.com.au/research/research_publications/show?id=2155
  \endverb
  \field{volume}{43}
  \field{journaltitle}{SIGOPS Operating Systems Review}
  \field{month}{01}
  \field{year}{2010}
\endentry

\entry{2007nazir_mobility-enabled_stack}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Nazir}{N.}%
     {Fawad}{F.}%
     {}{}%
     {}{}}%
    {{}%
     {Seneviratne}{S.}%
     {Aruna}{A.}%
     {}{}%
     {}{}}%
  }
  \keyw{mobility, network, stack, wireless}
  \strng{namehash}{NFSA1}
  \strng{fullhash}{NFSA1}
  \field{abstract}{%
  Future wireless networks have two widely accepted characteristics. Firstly,
  they will be based on all-IP based network architecture and secondly they
  will integrate heterogeneous wireless access technologies. As a result, there
  exist today a multitude of solutions aimed at managing these imminent
  challenges. These solutions are at varying stages of deployment, from purely
  analytical research, to experimentally validated proposals, right through to
  fully standardised and commercially available systems. In this paper we
  discuss the meaning, requirements, responsibilities and solutions for
  mobility management on all seven layers of the OSI communication stack. We
  identify internet mobility requirements and perform valuable three
  dimensional analyses between internet mobility requirements, mobility
  management protocols and layers of OSI communication stack. We also quantify
  types of mobilites possible in the future wireless networks and associate
  them with the responsible layers. In the end we conclude that no single layer
  in the OSI stack is responsible to completely address all the internet
  mobility requirements and support all the mobility types. We strongly believe
  that every layer has its own responsibilities in order to support mobility.
  Therefore in order to deal with mobility challenge we should have a ”
  Mobility Enabled Protocol Stack” instead of mobility management solution on
  a specific layer. We argue that the best approach to build a complete
  mobility enabled protocol stack for future wireless networks is based on the
  concept of Co-Existence of mobility management protocols proposed on
  different layers, in a way that we get best out of each. In the end, in order
  to support our arguments, we propose a novel mobility enabled protocol stack,
  naming mechanism and wireless network architecture for the future wireless
  networks.%
  }
  \field{number}{4}
  \field{title}{Towards Mobility Enabled Protocol Stack for Future Wireless
  Network}
  \verb{url}
  \verb http://www.ubicc.org/abstract.aspx?id=63
  \endverb
  \field{volume}{2}
  \field{journaltitle}{Ubiquitous Computing and Communication Journal}
  \field{month}{08}
  \field{year}{2007}
\endentry

\entry{2004eddy_layer_mobility}{article}{}
  \name{author}{1}{}{%
    {{}%
     {Eddy}{E.}%
     {Wesley~M.}{W.~M.}%
     {}{}%
     {}{}}%
  }
  \keyw{layer, mobility, network, stack}
  \strng{namehash}{EWM1}
  \strng{fullhash}{EWM1}
  \field{abstract}{%
  Internetworking is a complex problem, traditionally tackled by splitting
  responsibilities between several layers of protocols arranged in a stack. A
  shortcoming of the current Internet suite's layers is that the
  responsibilities of individual layers are somewhat ill defined. The result is
  that frequently a feature may cause problems for higher layers when it
  unexpectedly exists lower in the stack, or may be unnecessarily and
  inefficiently implemented in multiple layers. Mobility is one such feature
  with no well defined place in classical protocol stacks. If a link layer
  hands over between two distinctly administered networks, a network layer
  protocol will likely need to acquire a new address. Similarly, if mobility is
  implemented at the network layer, such as with mobile IP, transport layer
  protocols must be prepared to deal with a slew of problems (rapid changes in
  available capacity and delay, the asymmetry of triangle routes, and security
  policies, to name a few). Code for higher-level protocols (above transport)
  is less frequently reused, so higher-layer mobility schemes fail to leverage
  the large base of TCP sockets code. We discuss the various strengths and
  weaknesses of implementing mobility at three different layers of the protocol
  stack, concluding that a transport layer mobility scheme is likely to suit
  today's mobile Internet users best, and that ideally there should be more
  communication between layers to avoid conflict and inefficiency.%
  }
  \verb{doi}
  \verb 10.1109/MCOM.2004.1341274
  \endverb
  \field{issn}{0163-6804}
  \field{number}{10}
  \field{pages}{155\bibrangedash 159}
  \field{title}{At What Layer Does Mobility Belong?}
  \verb{url}
  \verb http://dx.doi.org/10.1109/MCOM.2004.1341274
  \endverb
  \field{volume}{42}
  \field{journaltitle}{IEEE Communications Magazine}
  \field{month}{10}
  \field{year}{2004}
\endentry

\entry{rfc5681}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Allman}{A.}%
     {Mark}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Paxson}{P.}%
     {Vern}{V.}%
     {}{}%
     {}{}}%
    {{}%
     {Blanton}{B.}%
     {Ethan}{E.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, ietf, network, protocol, rfc, tcp, transport}
  \strng{namehash}{AMPVBE1}
  \strng{fullhash}{AMPVBE1}
  \field{abstract}{%
  This document defines TCP's four intertwined congestion control algorithms:
  slowstart, congestion avoidance, fast retransmit, and fast recovery. In
  addition,the document specifies how TCP should begin transmission after a
  relatively longidle period, as well as discussing various acknowledgment
  generation methods.This document obsoletes RFC 2581.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{5681}
  \field{title}{{TCP} Congestion Control}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc5681.txt
  \endverb
  \field{type}{RFC}
  \field{month}{09}
  \field{year}{2009}
\endentry

\entry{rfc3782}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Henderson}{H.}%
     {Tom}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Gurtov}{G.}%
     {Andrei}{A.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, ietf, newreno, reno, rfc, tcp, transport}
  \strng{namehash}{FSHTGA1}
  \strng{fullhash}{FSHTGA1}
  \field{abstract}{%
  The purpose of this document is to advance NewReno TCP\\x27s Fast Retransmit
  and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track
  status. The main change in this document relative to RFC 2582 is to specify
  the Careful variant of NewReno\\x27s Fast Retransmit and Fast Recovery
  algorithms. The base algorithm described in RFC 2582 did not attempt to avoid
  unnecessary multiple Fast Retransmits that can occur after a timeout.
  However, RFC 2582 also defined%
  }
  \field{howpublished}{Internet Requests for Comment}
  \field{issn}{2070-1721}
  \field{number}{3782}
  \field{title}{The {N}ew{R}eno Modification to {TCP}'s Fast Recovery
  Algorithm}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc3782.txt
  \endverb
  \field{type}{RFC}
  \field{month}{04}
  \field{year}{2004}
\endentry

\entry{rfc5166}{report}{}
  \name{author}{1}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{aqm, congestioncontrol, delay, design, evaluation, fairness, ietf,
  metrics, rfc, tcp, throughput, transport}
  \strng{namehash}{FS1}
  \strng{fullhash}{FS1}
  \field{abstract}{%
  This document discusses the metrics to be considered in an evaluation of new
  ormodified congestion control mechanisms for the Internet. These include
  metricsfor the evaluation of new transport protocols, of proposed
  modifications to TCP,of application-level congestion control, and of Active
  Queue Management (AQM)mechanisms in the router. This document is the first in
  a series of documentsaimed at improving the models that we use in the
  evaluation of transportprotocols.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{5166}
  \field{title}{Metrics for the Evaluation of Congestion Control Mechanisms}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc5166.txt
  \endverb
  \field{type}{RFC}
  \field{month}{03}
  \field{year}{2008}
\endentry

\entry{2007briscoe_fairness}{article}{}
  \name{author}{1}{}{%
    {{}%
     {Briscoe}{B.}%
     {Bob}{B.}%
     {}{}%
     {}{}}%
  }
  \keyw{fairness, noeditor, opinion, rate, transport}
  \strng{namehash}{BB1}
  \strng{fullhash}{BB1}
  \field{abstract}{%
  Resource allocation and accountability keep reappearing on every list of
  requirements for the Internet architecture. The reason we never resolve these
  issues is a broken idea of what the problem is. The applied research and
  standards communities are using completely unrealistic and impractical
  fairness criteria. The resulting mechanisms don't even allocate the right
  thing and they don't allocate it between the right entities. We explain as
  bluntly as we can that thinking about fairness mechanisms like TCP in terms
  of sharing out flow rates has no intellectual heritage from any concept of
  fairness in philosophy or social science, or indeed real life. Comparing flow
  rates should never again be used for claims of fairness in production
  networks. Instead, we should judge fairness mechanisms on how they share out
  the \^{a}cost' of each user's actions on others%
  }
  \verb{doi}
  \verb 10.1145/1232919.1232926
  \endverb
  \field{issn}{0146-4833}
  \field{number}{2}
  \field{title}{Flow Rate Fairness: Dismantling a Religion}
  \verb{url}
  \verb http://bobbriscoe.net/projects/2020comms/refb/fair_ccr.pdf
  \endverb
  \field{volume}{37}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{04}
  \field{year}{2007}
\endentry

\entry{rfc4960}{report}{}
  \name{author}{1}{}{%
    {{}%
     {Stewart}{S.}%
     {Randall~R.}{R.~R.}%
     {}{}%
     {}{}}%
  }
  \keyw{ietf, rfc, sctp, transport}
  \strng{namehash}{SRR1}
  \strng{fullhash}{SRR1}
  \field{abstract}{%
  This document specifies an Internet standards track protocol for the Internet
  community, and requests discussion and suggestions for improvements. Please
  refer to the current edition of the "Internet Official Protocol Standards"
  (STD 1) for the standardization state and status of this protocol.
  Distribution of this memo is unlimited.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{issn}{2070-1721}
  \field{number}{4960}
  \field{title}{Stream Control Transmission Protocol}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc4960.txt
  \endverb
  \field{type}{RFC}
  \field{month}{09}
  \field{year}{2007}
\endentry

\entry{2008han_sctpfx}{inproceedings}{}
  \name{author}{2}{}{%
    {{}%
     {Han}{H.}%
     {Yunsop}{Y.}%
     {}{}%
     {}{}}%
    {{}%
     {Teraoka}{T.}%
     {Fumio}{F.}%
     {}{}%
     {}{}}%
  }
  \keyw{cross-layer, handoff, handover, ipv6, mipv6, mobility, multihoming,
  sctp, sctpfx, transport}
  \strng{namehash}{HYTF2}
  \strng{fullhash}{HYTF2}
  \field{abstract}{%
  This paper proposes SCTPfx, a fast failover mechanism in SCTP multihoming.
  For data communication, SCTP uses a single path among multiple available
  paths in an association. This path is called the primary path. If the primary
  path fails, failover procedure is carried out, i.e., one of the secondary
  path is engaged as the new primary. However, it takes more than 30 sec for
  failover because SCTP detects primary path failure by timeouts of several
  data chunks. To solve this problem, SCTPfx employs a cross-layer architecture
  called CEAL. CEAL can quickly notify SCTP of primary path failure caused by
  an event in the link layer or the network layer, e.g., the Ethernet cable was
  unplugged by accident, the IP address of the interface became unavailable due
  to timeout, or an ICMP unreach message was received. SCTPfx also supports
  fast recovery, i.e., when the original primary path recovers after failover,
  it is quickly engaged as the new primary again. SCTPfx was implemented on
  FreeBSD. As a result of measurements in our test network, SCTPfx achieves
  failover in 40 msec.%
  }
  \field{booktitle}{AINTEC 2008}
  \verb{doi}
  \verb 10.1145/1503370.1503399
  \endverb
  \field{isbn}{978-1-60558-127-9}
  \field{pages}{113\bibrangedash 122}
  \field{title}{{SCTPfx}: A Fast Failover Mechanism Based on Cross-layer
  Architecture in {SCTP} Multihoming}
  \verb{url}
  \verb http://dx.doi.org/10.1145/1503370.1503399
  \endverb
  \field{month}{11}
  \field{year}{2008}
\endentry

\entry{2009han_sctpmx}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Han}{H.}%
     {Yunsop}{Y.}%
     {}{}%
     {}{}}%
    {{}%
     {Terakoa}{T.}%
     {Fumio}{F.}%
     {}{}%
     {}{}}%
  }
  \keyw{cross-layer, handoff, handover, hasref, ipv6, mipv6, mobility,
  multihoming, sctp, sctpmx, transport}
  \strng{namehash}{HYTF1}
  \strng{fullhash}{HYTF1}
  \field{abstract}{%
  Recently, SCTP is attracting attention to support mobility in the Internet
  because it does not require additional equipment such as the Home Agent of
  Mobile IP. This paper focuses on an SCTP fast handover mechanism using a
  single interface because it is assumed that small mobile devices have a
  single interface per communication medium such as IEEE802.11b due to hardware
  limitations. The proposed mechanism called SCTPmx employs a cross layer
  control information exchange system called LIES to predict handover. LIES was
  originally designed to achieve network layer fast handover and then it was
  extended by adding the network layer primitives for efficient interaction
  among the link layer, the network layer, and the transport layer. Prior to
  handover, SCTPmx can generate a new address that will be used after handover
  and can execute duplicate address detection of IPv6. SCTPmx can suppress the
  delay caused by channel scanning at the link layer by employing selective
  background scanning mechanism which allows to continue data communication
  during channel scanning. In addition, SCTPmx can notify the correspondent
  node of the new address before handover. SCTPmx was implemented on FreeBSD.
  SCTPmx achieved better than 25 times lower handover latency (100 msec) and 2
  times higher throughput than previous proposals.%
  }
  \field{issn}{1745-1345}
  \field{number}{9}
  \field{pages}{2864\bibrangedash 2873}
  \field{title}{{SCTPmx}: An {SCTP} Fast Handover Mechanism Using a Single
  Interface Based on a Cross-Layer Architecture}
  \verb{url}
  \verb http://search.ieice.org/bin/summary.php?id=e92-b_9_2864&category=B&year
  \verb =2009&lang=E&abst=
  \endverb
  \field{volume}{E.92B}
  \field{journaltitle}{IEICE Transactions on Communications}
  \field{month}{09}
  \field{year}{2009}
\endentry

\entry{rfc4341}{report}{}
  \name{author}{2}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Kohler}{K.}%
     {Eddie}{E.}%
     {}{}%
     {}{}}%
  }
  \keyw{ccid, congestioncontrol, dccp, ietf, rfc, tcp-like, transport}
  \strng{namehash}{FSKE1}
  \strng{fullhash}{FSKE1}
  \field{abstract}{%
  This document contains the profile for Congestion Control Identifier 2 (CCID
  2),TCP-like Congestion Control, in the Datagram Congestion Control Protocol
  (DCCP).CCID 2 should be used by senders who would like to take advantage of
  the available bandwidth in an environment with rapidly changing conditions,
  and who are able to adapt to the abrupt changes in the congestion window
  typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion
  control.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{4341}
  \field{title}{Profile for Datagram Congestion Control Protocol ({DCCP})
  Congestion Control {ID} 2: {TCP}-like Congestion Control}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc4341.txt
  \endverb
  \field{type}{RFC}
  \field{month}{03}
  \field{year}{2006}
\endentry

\entry{rfc4342}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Kohler}{K.}%
     {Eddie}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Padhye}{P.}%
     {Jitendra}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{ccid, congestioncontrol, dccp, ietf, rfc, tfrc, transport}
  \strng{namehash}{FSKEPJ1}
  \strng{fullhash}{FSKEPJ1}
  \field{abstract}{%
  This document contains the profile for Congestion Control Identifier 3,
  TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol
  (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending
  rate, possibly with Explicit Congestion Notification (ECN), while minimizing
  abrupt rate changes.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{4342}
  \field{title}{Profile for Datagram Congestion Control Protocol ({DCCP})
  Congestion Control {ID} 3: {TCP}-Friendly Rate Control ({TFRC})}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc4342.txt
  \endverb
  \field{type}{RFC}
  \field{month}{03}
  \field{year}{2006}
\endentry

\entry{rfc5622}{report}{}
  \name{author}{2}{}{%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Kohler}{K.}%
     {Eddie}{E.}%
     {}{}%
     {}{}}%
  }
  \keyw{ccid, congestioncontrol, dccp, ietf, rfc, tfrc-sp, transport}
  \strng{namehash}{FSKE1}
  \strng{fullhash}{FSKE1}
  \field{abstract}{%
  The Datagram Congestion Control Protocol (DCCP) is a transport protocol that
  provides bidirectional unicast connections of congestion-controlled
  unreliable datagrams. DCCP is suitable for applications that transfer fairly
  large amounts of data and that can benefit from control over the trade off
  between timeliness and reliability.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{5622}
  \field{title}{Profile for Datagram Congestion Control Protocol ({DCCP})
  Congestion {ID} 4: {TCP}-Friendly Rate Control for Small Packets ({TFRC-SP})}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/draft-ietf-dccp-ccid4.txt
  \endverb
  \field{type}{RFC}
  \field{month}{08}
  \field{year}{2009}
\endentry

\entry{1998padhye_tcp_model}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Padhye}{P.}%
     {Jitendra}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Firoiu}{F.}%
     {Victor}{V.}%
     {}{}%
     {}{}}%
    {{}%
     {Towsley}{T.}%
     {Don}{D.}%
     {}{}%
     {}{}}%
    {{}%
     {Kurose}{K.}%
     {Jim}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{analysis, experiment, measurement, model, newreno, ns, simulation, tcp,
  tcpdump, tcptrace, throughput, transport}
  \strng{namehash}{PJFVTD+1}
  \strng{fullhash}{PJFVTDKJ1}
  \field{abstract}{%
  In this paper we develop a simple analytic characterization of the steady
  state throughput, as a function of loss rate and round trip time for a bulk
  transfer TCP flow, i.e., a flow with an unlimited amount of data to send.
  Unlike the models in [6, 7, 10], our model captures not only the behavior of
  TCP's fast retransmit mechanism (which is also considered in [6, 7, 10]) but
  also the effect of TCP's timeout mechanism on throughput. Our measurements
  suggest that this latter behavior is important from a modeling perspective,
  as almost all of our TCP traces contained more time-out events than fast
  retransmit events. Our measurements demonstrate that our model is able to
  more accurately predict TCP throughput and is accurate over a wider range of
  loss rates.%
  }
  \verb{doi}
  \verb 10.1145/285243.285291
  \endverb
  \field{howpublished}{SIGCOMM 1998, Proceedings of the Conference on
  Applications, Technologies, Architectures, and Protocols for Computer
  Communication}
  \field{issn}{0146-4833}
  \field{number}{4}
  \field{pages}{303\bibrangedash 314}
  \field{title}{Modeling {TCP} Throughput: A Simple Model and Its Empirical
  Validation}
  \verb{url}
  \verb http://dx.doi.org/10.1145/285243.285291
  \endverb
  \field{volume}{28}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{10}
  \field{year}{1998}
\endentry

\entry{2004chen_rate-based_ad-hoc}{inproceedings}{}
  \name{author}{3}{}{%
    {{}%
     {Chen}{C.}%
     {Kai}{K.}%
     {}{}%
     {}{}}%
    {{}%
     {Nahrstedt}{N.}%
     {Klara}{K.}%
     {}{}%
     {}{}}%
    {{}%
     {Vaidya}{V.}%
     {Nitin~H.}{N.~H.}%
     {}{}%
     {}{}}%
  }
  \keyw{ad-hoc, congestioncontrol, ratebased, transport}
  \strng{namehash}{CKNKVNH1}
  \strng{fullhash}{CKNKVNH1}
  \field{abstract}{%
  Flow control in a mobile ad hoc network (MANET) must face many new challenges
  such as frequent rerouting and bandwidth variation of the wireless links.
  TCP's implicit AIMD flow control performs poorly in this environment, because
  it often cannot keep up with the dynamics of the network. This paper explores
  the potential utility of explicit flow control in the MANET domain. To this
  end, we propose an end-to-end rate-based flow control scheme (called EXACT),
  where a flow's allowed rate is explicitly conveyed from intermediate routers
  to the end-hosts in each data packet's special control header. As a result,
  EXACT reacts quickly and precisely to re-routing and bandwidth variation,
  which makes it especially suitable for a dynamic MANET network and also
  discusses several supporting mechanisms required for such a scheme at the MAC
  and the transport layers. By ns-2 simulations, we show that EXACT outperforms
  TCP in terms of fairness and efficiency, especially in a highly dynamic MANET
  environment.%
  }
  \field{booktitle}{WCNC 2004}
  \verb{doi}
  \verb 10.1109/WCNC.2004.1311847
  \endverb
  \field{isbn}{0-7803-8344-3}
  \field{issn}{1525-3511}
  \field{pages}{1921\bibrangedash 1926}
  \field{title}{The Utility of Explicit Rate-Based Flow Control in Mobile Ad
  Hoc Networks}
  \verb{url}
  \verb http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1311847
  \endverb
  \field{volume}{3}
  \field{month}{03}
  \field{year}{2004}
\endentry

\entry{2001mascolo_westwood}{inproceedings}{}
  \name{author}{5}{}{%
    {{}%
     {Mascolo}{M.}%
     {Saverio}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Casetti}{C.}%
     {Claudio}{C.}%
     {}{}%
     {}{}}%
    {{}%
     {Gerla}{G.}%
     {Mario}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Sanadidi}{S.}%
     {M.~Yahya}{M.~Y.}%
     {}{}%
     {}{}}%
    {{}%
     {Wang}{W.}%
     {Ren}{R.}%
     {}{}%
     {}{}}%
  }
  \keyw{bandwidth, congestioncontrol, tcp, transport, westwood, wireless}
  \strng{namehash}{MSCCGM+1}
  \strng{fullhash}{MSCCGMSMYWR1}
  \field{abstract}{%
  TCP Westwood (TCPW) is a sender-side modification of the TCP congestion
  window algorithm that improves upon the performance of TCP Reno in wired as
  well as wireless networks. The improvement is most significant in wireless
  networks with lossy links, since TCP Westwood relies on end-to-end bandwidth
  estimation to discriminate the cause of packet loss (congestion or wireless
  channel effect) which is a major problem in TCP Reno. An important
  distinguishing feature of TCP Westwood with respect to previous wireless TCP
  ” extensions” is that it does not require inspection and/or interception
  of TCP packets at intermediate (proxy) nodes. Rather, it fully complies with
  the end-to-end TCP design principle. The key innovative idea is to
  continuously measure at the TCP source the rate of the connection by
  monitoring the rate of returning ACKs. The estimate is then used to compute
  congestion window and slow start threshold after a congestion episode, that
  is, after three duplicate acknowledgments or after a timeout. The rationale
  of this strategy is simple: in contrast with TCP Reno, which ” blindly”
  halves the congestion window after three duplicate ACKs, TCP Westwood
  attempts to select a slow start threshold and a congestion window which are
  consistent with the effective bandwidth used at the time congestion is
  experienced. We call this mechanism faster recovery . The proposed mechanism
  is particularly effective over wireless links where sporadic losses due to
  radio channel problems are often misinterpreted as a symptom of congestion by
  current TCP schemes and thus lead to an unnecessary window reduction.
  Experimental studies reveal improvements in throughput performance, as well
  as in fairness. In addition, friendliness with TCP Reno was observed in a set
  of experiments showing that TCP Reno connections are not starved by TCPW
  connections. Most importantly, TCPW is extremely effective in mixed wired and
  wireless networks where throughput improvements of up to 550\% are observed.
  Finally, TCPW performs almost as well as localized link layer approaches such
  as the popular Snoop scheme, without incurring the O/H of a specialized link
  layer protocol.%
  }
  \field{booktitle}{MobiCom 2001}
  \verb{doi}
  \verb 10.1145/381677.381704
  \endverb
  \field{isbn}{1-58113-422-3}
  \field{pages}{287\bibrangedash 297}
  \field{title}{{TCP} {W}estwood: Bandwidth Estimation for Enhanced Transport
  Over Wireless Links}
  \verb{url}
  \verb http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_papers/2001-mobicom-0.pdf
  \endverb
  \field{month}{07}
  \field{year}{2001}
\endentry

\entry{2004grieco_westwood-plus_comparison}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Grieco}{G.}%
     {Luigi~A.}{L.~A.}%
     {}{}%
     {}{}}%
    {{}%
     {Mascolo}{M.}%
     {Saverio}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{tcp, transport}
  \strng{namehash}{GLAMS1}
  \strng{fullhash}{GLAMS1}
  \field{abstract}{%
  TCP congestion control has been designed to ensure Internet stability along
  with fair and efficient allocation of the network bandwidth. During the last
  decade, many congestion control algorithms have been proposed to improve the
  classic Tahoe/Reno TCP congestion control. This paper aims at evaluating and
  comparing three control algorithms, which are Westwood+, New Reno and Vegas
  TCP, using both Ns-2 simulations and live Internet measurements. Simulation
  scenarios are carefully designed in order to investigate goodput, fairness
  and friendliness provided by each of the algorithms. Results show that
  Westwood+ TCP is friendly towards New Reno TCP and improves fairness in
  bandwidth allocation whereas Vegas TCP is fair but it is not able to grab its
  bandwidth share when coexisting with Reno or in the presence of reverse
  traffic because of its RTT-based congestion detection mechanism. Finally
  results show that Westwood+ remarkably improves utilization of wireless links
  that are affected by losses not due to congestion.%
  }
  \verb{doi}
  \verb 10.1145/997150.997155
  \endverb
  \field{issn}{0146-4833}
  \field{number}{2}
  \field{pages}{25\bibrangedash 38}
  \field{title}{Performance Evaluation and Comparison of {W}estwood+, {N}ew
  {R}eno, and {V}egas {TCP} congestion control}
  \verb{url}
  \verb http://dx.doi.org/10.1145/997150.997155
  \endverb
  \field{volume}{34}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{04}
  \field{year}{2004}
\endentry

\entry{1997balakrishnan_comparison_improvements_tcp_wireless}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Balakrishnan}{B.}%
     {Hari}{H.}%
     {}{}%
     {}{}}%
    {{}%
     {Padmanabhan}{P.}%
     {Venkata~N.}{V.~N.}%
     {}{}%
     {}{}}%
    {{}%
     {Seshan}{S.}%
     {Srinivasan}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Katz}{K.}%
     {Randy~H.}{R.~H.}%
     {}{}%
     {}{}}%
  }
  \keyw{eln, experiment, newreno, sack, tcp, transport, wireless}
  \strng{namehash}{BHPVNSS+1}
  \strng{fullhash}{BHPVNSSKRH1}
  \field{abstract}{%
  Reliable transport protocols such as TCP are tuned to per-form well in
  traditional networks where packet losses occurmostly because of congestion.
  However, networks withwireless and other lossy links also suffer from
  significantlosses due to bit errors and handoffs. TCP responds to alllosses
  by invoking congestion control and avoidance algo-rithms, resulting in
  degraded end-to-end performance inwireless and lossy systems. In this paper,
  we compare sev-eral schemes designed to improve the performance of TCPin such
  networks. We classify these schemes into threebroad categories: end-to-end
  protocols, where loss recoveryis performed by the sender; link-layer
  protocols, that pro-vide local reliability; and split-connection protocols,
  thatbreak the end-to-end connection into two parts at the basestation. We
  present the results of several experiments per-formed in both LAN and WAN
  environments, usingthroughput and goodput as the metrics for comparison.Our
  results show that a reliable link-layer protocol that isTCP-aware provides
  very good performance. Furthermore,it is possible to achieve good performance
  without splittingthe end-to-end connection at the base station. We also
  dem-onstrate that selective acknowledgments and explicit lossnotifications
  result in significant performance improve-ments.%
  }
  \verb{doi}
  \verb 10.1109/90.650137
  \endverb
  \field{issn}{1063-6692}
  \field{number}{6}
  \field{pages}{756\bibrangedash 769}
  \field{title}{A Comparison of Mechanisms for Improving {TCP} Performance over
  Wireless Links}
  \verb{url}
  \verb http://www.stanford.edu/class/cs244e/papers/balakrishnan_ton.pdf
  \endverb
  \field{volume}{5}
  \field{journaltitle}{IEEE/ACM Transactions on Networking}
  \field{month}{12}
  \field{year}{1997}
\endentry

\entry{2001xylomenos_tcp_issues_wireless}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Xylomenos}{X.}%
     {George}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Polyzo}{P.}%
     {George~C.}{G.~C.}%
     {}{}%
     {}{}}%
    {{}%
     {M\"{a}h\"{o}nen}{M.}%
     {Petri}{P.}%
     {}{}%
     {}{}}%
    {{}%
     {Saaranen}{S.}%
     {Mika}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{80211, experiment, measurement, performance, tcp, transport, wireless}
  \strng{namehash}{XGPGCMP+1}
  \strng{fullhash}{XGPGCMPSM1}
  \field{abstract}{%
  This article discusses the problems arising when the TCP/IP protocol suite is
  used to provide Internet connectivity over existing and emerging wireless
  links. Due to the strong drive toward wireless Internet access through mobile
  terminals, these problems must be carefully studied in order to build
  improved systems. We review wireless link characteristics using wireless LANs
  and cellular communications systems as examples. We then outline the
  performance problems of the TCP/IP protocol suite when employed over those
  links, such as degraded TCP performance due to mistaking wireless errors for
  congestion. We present various proposals for solving these problems and
  examine their benefits and limitations. Finally, we consider the future
  evolution of wireless systems and the challenges that emerging systems will
  impose on the Internet protocol suite.%
  }
  \verb{doi}
  \verb 10.1109/35.917504
  \endverb
  \field{issn}{0163-6804}
  \field{number}{4}
  \field{pages}{52\bibrangedash 58}
  \field{title}{{TCP} Performance Issues over Wireless Links}
  \verb{url}
  \verb http://dx.doi.org/10.1109/35.917504
  \endverb
  \field{volume}{39}
  \field{journaltitle}{IEEE Communications Magazine}
  \field{month}{04}
  \field{year}{2001}
\endentry

\entry{2003pilosof_tcp_fairness_wlan}{inproceedings}{}
  \name{author}{5}{}{%
    {{}%
     {Pilosof}{P.}%
     {Saar}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Ramjee}{R.}%
     {Ramachandran}{R.}%
     {}{}%
     {}{}}%
    {{}%
     {Raz}{R.}%
     {Danny}{D.}%
     {}{}%
     {}{}}%
    {{}%
     {Shavitt}{S.}%
     {Yuval}{Y.}%
     {}{}%
     {}{}}%
    {{}%
     {Sinha}{S.}%
     {Prasun}{P.}%
     {}{}%
     {}{}}%
  }
  \keyw{80211, analysis, bandwidth, experiment, fairness, network, simulation,
  tcp, transport, wireless}
  \strng{namehash}{PSRRRD+1}
  \strng{fullhash}{PSRRRDSYSP1}
  \field{abstract}{%
  As local area wireless networks based on the IEEE 802.11 standard see
  increasing public deployment, it is important to ensure that access to the
  network by different users remains fair. While fairness issues in 802.11
  networks have been studied before, this paper is the first to focus on TCP
  fairness in 802.11 networks in the presence of both mobile senders and
  receivers. In this paper, we evaluate extensively through analysis,
  simulation, and experimentation the interaction between the 802.11 MAC
  protocol and TCP. We identify four different regions of TCP unfairness that
  depend on the buffer availability at the base station, with some regions
  exhibiting significant unfairness of over 10 in terms of throughput ratio
  between upstream and downstream TCP flows. We also propose a simple solution
  that can be implemented at the base station above the MAC layer that ensures
  that different TCP flows share the 802.11 bandwidth equitably irrespective of
  the buffer availability at the base station.%
  }
  \field{booktitle}{INFOCOM 2003}
  \verb{doi}
  \verb 10.1109/INFCOM.2003.1208924
  \endverb
  \field{pages}{863\bibrangedash 872}
  \field{title}{Understanding {TCP} Fairness over Wireless {LAN}}
  \verb{url}
  \verb http://dx.doi.org/10.1109/INFCOM.2003.1208924
  \endverb
  \field{volume}{2}
  \field{month}{04}
  \field{year}{2003}
\endentry

\entry{2004benekos_tcp_measurements_802.11b}{inproceedings}{}
  \name{author}{5}{}{%
    {{}%
     {Benekos}{B.}%
     {Konstantinos}{K.}%
     {}{}%
     {}{}}%
    {{}%
     {Pogkas}{P.}%
     {Nikos}{N.}%
     {}{}%
     {}{}}%
    {{}%
     {Kalivas}{K.}%
     {Grigorios}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Papadopoulos}{P.}%
     {George}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Tzes}{T.}%
     {Anthony}{A.}%
     {}{}%
     {}{}}%
  }
  \keyw{80211, experiment, measurement, performance, tcp, transport, wireless}
  \strng{namehash}{BKPNKG+1}
  \strng{fullhash}{BKPNKGPGTA1}
  \field{abstract}{%
  During the last years, TCP has gained a lot of momentum in the context of
  wireless networking. However, TCP was designed for wire-line networks and for
  this reason it interprets difficulties in radio transmission differently. The
  objective of this paper is to experimentally investigate the performance of
  TCP in wireless 802.11b LANs under various propagation conditions. We
  evaluate one-hop networks where an intermediate node is used to establish
  communication between two distant nodes. To evaluate the effectiveness of the
  TCP protocol, throughput and efficiency are examined for different
  transmission rates, packet sizes and transmitted power settings. The
  measurement results demonstrate the impact of different propagation
  conditions on the performance of wireless TCP. They also show that wireless
  networking is robust and efficient in multi-path propagation environment.%
  }
  \field{booktitle}{MELECON 2004. 12th IEEE Mediterranean Electrotechnical
  Electrotechnical Conference}
  \field{isbn}{0-7803-8271-4}
  \field{pages}{575\bibrangedash 578}
  \field{title}{{TCP} Performance Measurements in {IEEE} 802.11b-based Wireless
  {LAN}s}
  \verb{url}
  \verb http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1346995
  \endverb
  \field{volume}{2}
  \field{month}{05}
  \field{year}{2004}
\endentry

\entry{2005franceschinis_tcp_wifi_measurement}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Franceschinis}{F.}%
     {Mirko}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Mellia}{M.}%
     {Marco}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Meo}{M.}%
     {Michela}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Munaf\`{o}}{M.}%
     {Maurizio}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{80211, experiment, measurement, performance, tcp, transport}
  \strng{namehash}{FMMMMM+1}
  \strng{fullhash}{FMMMMMMM1}
  \field{abstract}{%
  We present a measurement study of an operative WLAN. After briefly presenting
  the methodology used to generate traffic and measure performance indices, we
  present results focusing on the performance perceived by TCP connections,to
  understand the mechanisms which have a major effect on performance. We
  investigate the impact of TCP parameters,like the maximum congestion window,
  the effectiveness of link layer mechanisms such as RTS/CTS, and multi rate
  transmissions.Rather than only presenting aggregate measures, we show results
  relative to individual TCP connections, considering throughput as well as TCP
  round trip time, congestion window and segment retransmissions.%
  }
  \field{booktitle}{WiNMee 2005}
  \field{title}{Measuring {TCP} over {WiFi}: A Real Case}
  \verb{url}
  \verb http://www.winmee.org/2005/papers/WiNMee_Franceschinis.pdf
  \endverb
  \field{month}{04}
  \field{year}{2005}
\endentry

\entry{2006baig_freezetcp_on-board_performance}{article}{}
  \name{author}{3}{}{%
    {{}%
     {Baig}{B.}%
     {Adeel}{A.}%
     {}{}%
     {}{}}%
    {{}%
     {Libman}{L.}%
     {Lavy}{L.}%
     {}{}%
     {}{}}%
    {{}%
     {Hassan}{H.}%
     {Mabhub}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{freezetcp, handoff, mobility, ns-2, simulation, transport, wlan}
  \strng{namehash}{BALLHM1}
  \strng{fullhash}{BALLHM1}
  \field{abstract}{%
  A research area that has become increasingly important in recent years is
  that of on-board mobile communication, where users on a vehicle are connected
  to a local network that attaches to the Internet via a mobile router and a
  wireless link. In this architecture, link disruptions (e.g., due to signal
  degradation) may have an immediate impact on a potentially large number of
  connections. We argue that the advance knowledge of public transport routes,
  and their repetitive nature, allows a certain degree of prediction of
  impending link disruptions, which can be used to offset their catastrophic
  impact. Focusing on the transmission control protocol (TCP) and its extension
  known as Freeze-TCP, we present a detailed analysis of the performance
  improvement of TCP connections in the presence of disruption prediction. In
  particular, we propose a Markov model of Freeze-TCP that captures both the
  TCP behavior and the prediction+ ” freezing” feature and, using
  simulations, show that it accurately predicts the performance of the
  protocol. Our results demonstrate the significant throughput improvement that
  can be gained by disruption prediction, even with random packet losses or
  imperfect timing of the predicted disruptions.%
  }
  \field{booktitle}{Selected Areas in Communications, IEEE Journal on}
  \verb{doi}
  \verb 10.1109/JSAC.2006.875108
  \endverb
  \field{issn}{0733-8716}
  \field{number}{9}
  \field{pages}{1692\bibrangedash 1701}
  \field{title}{Performance Enhancement of On-Board Communication Networks
  Using Outage Prediction}
  \verb{url}
  \verb http://dx.doi.org/10.1109/JSAC.2006.875108
  \endverb
  \field{volume}{24}
  \field{journaltitle}{IEEE Journal on Selected Areas in Communications}
  \field{month}{09}
  \field{year}{2006}
\endentry

\entry{2009park_freezetcpv2}{incollection}{}
  \name{author}{4}{}{%
    {{}%
     {Park}{P.}%
     {Minu}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Lee}{L.}%
     {Jaehyung}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Koo}{K.}%
     {Jahwan}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Choo}{C.}%
     {Hyunseung}{H.}%
     {}{}%
     {}{}}%
  }
  \keyw{freeze, freezetcp, ns-2, simulation, tcp, transport, wireless}
  \strng{namehash}{PMLJKJ+1}
  \strng{fullhash}{PMLJKJCH1}
  \field{abstract}{%
  The advancement of mobile communications for the last few years has
  accompanied an increasingly extensive and diverse array of environments for
  TCP applications, which has led to a host of wireless TCP approaches that may
  provide more stability and ensure higher performance. In a heterogeneous
  network, as opposed to conventional wireless networks, a mobile node performs
  a handoff to another network cells with a different bandwidth and latency.
  Conventional wireless TCP schemes, however, are not capable of properly
  addressing sudden changes in round trip time (RTT) and packet loss resulting
  from handoffs within a heterogeneous network and do experience such problems
  as the waste of available bandwidth and frequent packet loss. As a solution
  to these problems, this paper proposes Freeze TCP version 2 (v2), an
  enhancement of Freeze TCP designed to dynamically obtain the available
  bandwidth in a new network cell. Comprehensive simulation study is conducted
  by using a network simulator, ns-2, to compare the proposed scheme to a few
  other schemes, such as Freeze TCP, DEMO-Vegas, and TCP Vegas, in a
  heterogeneous network environment with vertical handoffs in terms of
  throughput per speed of the mobile node and per bit error rate of the
  wireless link.%
  }
  \field{booktitle}{Human Interface and the Management of Information.
  Information and Interaction}
  \field{chapter}{49}
  \verb{doi}
  \verb 10.1007/978-3-642-02559-4_49
  \endverb
  \field{isbn}{978-3-642-02558-7}
  \field{pages}{448\bibrangedash 457}
  \field{series}{Lecture Notes in Computer Science}
  \field{title}{Freeze {TCP}v2: An Enhancement of {F}reeze {TCP} for Efficient
  Handoff in Heterogeneous Networks}
  \verb{url}
  \verb http://dx.doi.org/10.1007/978-3-642-02559-4_49
  \endverb
  \field{volume}{5618}
  \field{year}{2009}
\endentry

\entry{2008zhang_cross-layer_congestion-control_wlans}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Zhang}{Z.}%
     {Lei}{L.}%
     {}{}%
     {}{}}%
    {{}%
     {S\'{e}nac}{S.}%
     {Patrick}{P.}%
     {}{}%
     {}{}}%
    {{}%
     {Lochin}{L.}%
     {Emmanuel}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Diaz}{D.}%
     {Michel}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, cross-layer, mobility, network, optimization, tfrc,
  transport, wireless}
  \strng{namehash}{ZLSPLE+1}
  \strng{fullhash}{ZLSPLEDM1}
  \field{abstract}{%
  Congestion control is a fundamental mechanism for the stability of the
  Internet and is a central mechanism for TCP. However, this congestion control
  mechanism focuses mainly on the core network state and is blind to the
  characteristics of wireless and mobile access networks. Moreover, TCP window
  based congestion control ignores totally application layer QoS needs and
  entails throughput variations which are not compliant with application layer
  QoS constraints such as bandwidth, delay and jitter. The TCP-Friendly Rate
  Control protocol (TFRC) was originally designed in the context of wired
  networks. This protocol is one of the most convincing attempt to provide a
  congestion control mechanism adapted to multimedia flows, although limited in
  its capacity to fully address these issues. After an identification and
  evaluation of the subtle counterproductive interactions between the WLANs MAC
  layer and the transport layer, this paper shows a new approach towards
  congestion control for WLANs. This paper also introduces a specialization of
  TFRC (MTFRC: Mobile TFRC), which is adapted to wireless access networks. This
  TFRC specialization requires only slight changes to the standard TFRC
  protocol. Simulation results show substantial improvements for applications
  over TFRC in scenarios where the bottleneck situates on the MAC layer of the
  mobile nodes.%
  }
  \field{booktitle}{QShine 2008}
  \field{isbn}{978-963-9799-26-4}
  \field{pages}{1\bibrangedash 7}
  \field{title}{Cross-Layer Based Congestion Control for {WLAN}s}
  \verb{url}
  \verb http://portal.acm.org/citation.cfm?id=1535619
  \endverb
  \field{month}{06}
  \field{year}{2008}
\endentry

\entry{2008shieh_sctp_vertical_handover}{inproceedings}{}
  \name{author}{3}{}{%
    {{}%
     {Shieh}{S.}%
     {Chin~S.}{C.~S.}%
     {}{}%
     {}{}}%
    {{}%
     {Lin}{L.}%
     {I.~Cheng}{I.~C.}%
     {}{}%
     {}{}}%
    {{}%
     {Lai}{L.}%
     {Wei~K.}{W.~K.}%
     {}{}%
     {}{}}%
  }
  \keyw{3g, 80211, congestioncontrol, handover, heterogeneous, mobility, sctp,
  umts, wireless}
  \strng{namehash}{SCSLICLWK1}
  \strng{fullhash}{SCSLICLWK1}
  \field{abstract}{%
  A heterogeneous wireless network integrating IEEE 802.11 WLAN and 3G/UMTS
  mobile phone system will be a common scenario in future mobile networking.
  The multi-homing feature of SCTP and the dynamic address configuration
  extension had made seamless vertical handover possible in heterogeneous
  mobile wireless networks. However, an ongoing SCTP association will
  experience the slow-start phase on the new path after a vertical handover,
  since the congestion window and slow-start threshold on the new path are
  reset to their initial values. For smoother handover, a new approach is
  developed and presented in this article. In the proposed scheme, we send out
  probing packets on the new path to estimate available bandwidth before actual
  handover. Obtained information can then use to preset the flow control
  parameters. By doing so, the slow-start phase can be effectively skipped.
  Simulation results reveal that the proposed scheme is a feasible and
  effective solution for the improvement of SCTP performance during vertical
  handover in heterogeneous mobile wireless networks.%
  }
  \field{booktitle}{ISDA 2008}
  \verb{doi}
  \verb 10.1109/ISDA.2008.347
  \endverb
  \field{isbn}{978-0-7695-3382-7}
  \field{pages}{494\bibrangedash 498}
  \field{title}{Improvement of {SCTP} Performance in Vertical Handover}
  \verb{url}
  \verb http://dx.doi.org/10.1109/ISDA.2008.347
  \endverb
  \field{volume}{3}
  \field{year}{2008}
\endentry

\entry{2006lin_mbtfrc}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Lin}{L.}%
     {Yu}{Y.}%
     {}{}%
     {}{}}%
    {{}%
     {Cheng}{C.}%
     {Shiduan}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Wang}{W.}%
     {Wendong}{W.}%
     {}{}%
     {}{}}%
    {{}%
     {Jin}{J.}%
     {Yuehui}{Y.}%
     {}{}%
     {}{}}%
  }
  \keyw{handoff, hasref, mbtfrc, mobility, packetpair, probe, slowstart, tfrc,
  transport}
  \strng{namehash}{LYCSWW+1}
  \strng{fullhash}{LYCSWWJY1}
  \field{abstract}{%
  As a well-known multimedia stream transport protocol, TFRC provides smooth
  transfer rate under stable network conditions, and achieves good fairness to
  TCP. However, it is not flexible in heterogeneous mobile networks because the
  available bandwidth varies rapidly. This paper proposes a measurement based
  TFRC (MBTFRC) protocol, which uses passive bandwidth measurements at the
  receiver to improve the flexibility of TFRC. In addition, a window-based EWMA
  filter with two weights is used to achieve stability and fairness
  simultaneously. Simulation results verify the flexibility, stability and
  fairness of MBTFRC%
  }
  \verb{doi}
  \verb 10.1109/TWC.2006.1687706
  \endverb
  \field{issn}{1536-1276}
  \field{number}{8}
  \field{pages}{1971\bibrangedash 1975}
  \field{title}{Measurement-Based {TFRC}: Improving {TFRC} in Heterogeneous
  Mobile Networks}
  \verb{url}
  \verb http://dx.doi.org/10.1109/TWC.2006.1687706
  \endverb
  \field{volume}{5}
  \field{journaltitle}{IEEE Transactions on Wireless Communications}
  \field{month}{08}
  \field{year}{2006}
\endentry

\entry{2006chen_link_capacity_tfrc_probe}{article}{}
  \name{author}{5}{}{%
    {{}%
     {Chen}{C.}%
     {Ling-Jyh}{L.-J.}%
     {}{}%
     {}{}}%
    {{}%
     {Sun}{S.}%
     {Tony}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Yang}{Y.}%
     {Guang}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Sanadidi}{S.}%
     {M.~Yahya}{M.~Y.}%
     {}{}%
     {}{}}%
    {{}%
     {Gerla}{G.}%
     {Mario}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{capprobe, congestioncontrol, handoff, hasref, mobility, monitoring,
  network, packetpair, probe, tfrc, transport}
  \strng{namehash}{CLJSTYG+1}
  \strng{fullhash}{CLJSTYGSMYGM1}
  \field{abstract}{%
  Accurate estimation of network characteristics based on end-to-end
  measurements is an important and challenging problem. With the increasing
  variety and sophistication of Internet access methods, the mobility of the
  users and the need for seamless handoff across them, monitoring access link
  capacity becomes critical for efficient multimedia delivery. In fact, this
  allows the multimedia server to properly adjust its sending rate to the
  rapidly changing access speed of the mobile client. This problem is
  challenging because most of the existing capacity monitoring schemes are
  active, like Pathrate (and therefore, introduce extra overhead on the
  bandwidth limited access link). Moreover, the access link is often asymmetric
  (e.g. ADSL, 1×RTT, etc.) thus preventing the use of round-trip monitoring
  schemes such as Pathchar and CapProbe. In this study, we propose and evaluate
  a passive, one-way link capacity monitoring tool called TFRC Probe. With TFRC
  Probe the source can monitor the forward direction capacity of both
  asymmetric and symmetric access links, and can rapidly and accurately adapt
  its transmissions rate accordingly. We validate TFRC Probe with both
  simulation and testbed experiments, and show that TFRC Probe is a very
  flexible tool that can accurately track frequent changes in access capacity.%
  }
  \verb{doi}
  \verb 10.1016/j.comcom.2005.07.010
  \endverb
  \field{issn}{01403664}
  \field{number}{10}
  \field{pages}{1605\bibrangedash 1613}
  \field{title}{Monitoring Access Link Capacity Using {TFRC} Probe}
  \verb{url}
  \verb http://www.cs.ucla.edu/NRL/CapProbe/
  \endverb
  \field{volume}{29}
  \field{journaltitle}{Computer Communications}
  \field{month}{06}
  \field{year}{2006}
\endentry

\entry{2001dovrolis_packet-pair}{inproceedings}{}
  \name{author}{3}{}{%
    {{}%
     {Dovrolis}{D.}%
     {Constantinos}{C.}%
     {}{}%
     {}{}}%
    {{}%
     {Ramanathan}{R.}%
     {Parameswaran}{P.}%
     {}{}%
     {}{}}%
    {{}%
     {Moore}{M.}%
     {David}{D.}%
     {}{}%
     {}{}}%
  }
  \keyw{bandwidth, capacity, estimation, network, packetpair, pathrate}
  \strng{namehash}{DCRPMD1}
  \strng{fullhash}{DCRPMD1}
  \field{abstract}{%
  The packet pair technique estimates the capacity of a path (bottleneck
  bandwidth) from the dispersion (spacing) experienced by two back-to-back
  packets [1][2][3]. We demonstrate that the dispersion of packet pairs in
  loaded paths follows a multimodal distribution, and discuss the queueing
  effects that cause the multiple modes. We show that the path capacity is
  often not the global mode, and so it cannot be estimated using standard
  statistical procedures. The effect of the size of the probing packets is also
  investigated, showing that the conventional wisdom of using maximum sized
  packet pairs is not optimal. We then study the dispersion of long packet
  trains. Increasing the length of the packet train reduces the measurement
  variance, but the estimates converge to a value, referred to as Asymptotic
  Dispersion Rate (ADR), that is lower than the capacity. We derive the effect
  of the cross traffic in the dispersion of long packet trains, showing that
  the ADR is not the available bandwidth in the path, as was assumed in
  previous work. Putting all the pieces together, we present a capacity
  estimation methodology that has been implemented in a tool called pathrate.%
  }
  \field{booktitle}{INFOCOM 2001}
  \verb{doi}
  \verb 10.1109/INFCOM.2001.916282
  \endverb
  \field{pages}{905\bibrangedash 914}
  \field{title}{What Do Packet Dispersion Techniques Measure?}
  \verb{url}
  \verb http://minds.wisconsin.edu/bitstream/handle/1793/9304/file_1.pdf
  \endverb
  \field{month}{04}
  \field{year}{2001}
\endentry

\entry{2001bansal_slowly_responsive_congestion_control}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Bansal}{B.}%
     {Deepak}{D.}%
     {}{}%
     {}{}}%
    {{}%
     {Balakrishnan}{B.}%
     {Hari}{H.}%
     {}{}%
     {}{}}%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Shenker}{S.}%
     {Scott}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, conservative\_, dynamicbehavior, tcp, tfrc,
  transport}
  \strng{namehash}{BDBHFS+1}
  \strng{fullhash}{BDBHFSSS1}
  \field{abstract}{%
  The recently developed notion of TCP-compatibility has led to a number of
  proposals for alternative congestion control algorithms whose long-term
  throughput as a function of a steady-state loss rate is similar to that of
  TCP. Motivated by the needs of some streaming and multicast applications,
  these algorithms seem poised to take the current TCP-dominated Internet to an
  Internet where many congestion control algorithms co-exist. An important
  characteristic of these alternative algorithms is that they are
  slowly-responsive , refraining from reacting as drastically as TCP to a
  single packet loss.However, the TCP-compatibility criteria explored so far in
  the literature considers only the static condition of a fixed loss rate. This
  paper investigates the behavior of slowly-responsive, TCP-compatible
  congestion control algorithms under more realistic dynamic network
  conditions, addressing the fundamental question of whether these algorithms
  are safe to deploy in the public Internet. We study persistent loss rates,
  long- and short-term fairness properties, bottleneck link utilization, and
  smoothness of transmission rates.%
  }
  \field{booktitle}{SIGCOMM 2001}
  \verb{doi}
  \verb 10.1145/383059.383080
  \endverb
  \field{isbn}{1-58113-411-8}
  \field{pages}{263\bibrangedash 274}
  \field{title}{Dynamic Behavior of Slowly-Responsive Congestion Control
  Algorithms}
  \verb{url}
  \verb http://nms.lcs.mit.edu/papers/slowcc-sigcomm01.html
  \endverb
  \field{month}{08}
  \field{year}{2001}
\endentry

\entry{2008li_improving_tfrc_bandwidth_handover}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Li}{L.}%
     {Dagang}{D.}%
     {}{}%
     {}{}}%
    {{}%
     {Sleurs}{S.}%
     {Kristof}{K.}%
     {}{}%
     {}{}}%
    {{}%
     {Van~Lil}{V.~L.}%
     {Emmanuel}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Capelle}{C.}%
     {Antoine}{A.}%
     {Van~de}{V.~d.}%
     {}{}}%
  }
  \keyw{adaptation, bandwidth, congestioncontrol, handoff, hasref, mobility,
  rate, tfrc, transport}
  \strng{namehash}{LDSKVLE+1}
  \strng{fullhash}{LDSKVLECAVd1}
  \field{abstract}{%
  TCP-friendly rate control (TFRC) is a congestion control mechanism that can
  compete fairly with TCP while maintaining a much smoother transmission rate.
  The smoothness is achieved at the cost of responsiveness, which makes it slow
  to settle down when handed-over to a different network. In this paper we will
  study how to improve the TFRC performance when the available bandwidth is
  changed during a handover. An enhancement is proposed that can eliminate most
  of the heavy packet loss during a bandwidth-decreased handover. The
  definition and conditions of a smooth TFRC handover is also provided. The
  improvement over the original TFRC is proved with simulation results.%
  }
  \field{booktitle}{WiCom 2008}
  \verb{doi}
  \verb 10.1109/WiCom.2008.1072
  \endverb
  \field{isbn}{978-1-4244-2107-7}
  \field{pages}{1\bibrangedash 4}
  \field{title}{Improving {TFRC} Performance against Bandwidth Change during
  Handovers}
  \verb{url}
  \verb http://lirias.kuleuven.be/bitstream/123456789/199721/1/PID667147.pdf
  \endverb
  \field{month}{10}
  \field{year}{2008}
\endentry

\entry{draft-ietf-dccp-tfrc-faster-restart-06}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Kohler}{K.}%
     {Eddie}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Sathiaseelan}{S.}%
     {Arjuna}{A.}%
     {}{}%
     {}{}}%
  }
  \keyw{fasterrestart, ietf, internetdraft, tfrc, transport}
  \strng{namehash}{KEFSSA1}
  \strng{fullhash}{KEFSSA1}
  \field{abstract}{%
  {TCP}-Friendly Rate Control ({TFRC}) is a congestion control mechanism for
  unicast flows operating in a best-effort Internet environment. This document
  introduces Faster Restart, an optional mechanism for safely improving the
  behavior of interactive flows that use {TFRC}. Faster Restart is proposed for
  use with {TFRC} and with {TFRC}-{SP}, the Small Packet variant of {TFRC}. We
  present Faster Restart in general terms as a congestion control mechanism,
  and further discuss Faster Restart for Datagram Congestion Control Protocol
  ({DCCP}) Congestion Control {IDs} 3 and 4.%
  }
  \field{howpublished}{Working Draft}
  \field{number}{draft-ietf-dccp-tfrc-faster-restart-06.txt}
  \field{title}{Faster Restart for {TCP} Friendly Rate Control ({TFRC})}
  \verb{url}
  \verb http://www.rfc-editor.org/internet-drafts/draft-ietf-dccp-tfrc-faster-r
  \verb estart-06.txt
  \endverb
  \field{type}{Internet-Draft}
  \field{month}{07}
  \field{year}{2008}
\endentry

\entry{2007jourjon_tfrc_initialization}{article}{}
  \name{author}{3}{}{%
    {{}%
     {Jourjon}{J.}%
     {Guillaume}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Lochin}{L.}%
     {Emmanuel}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Dairaine}{D.}%
     {Laurent}{L.}%
     {}{}%
     {}{}}%
  }
  \keyw{algorithm, model, optimization, tfrc}
  \strng{namehash}{JGLEDL1}
  \strng{fullhash}{JGLEDL1}
  \field{abstract}{%
  This letter deals with the initialization of the loss history structure in
  the TFRC (TCP-friendly rate control) mechanism. This initialization occurs
  after the detection of the first loss event after every slowstart phase. The
  loss history is crucial for the algorithm since it returns the packet loss
  rate estimation. This estimation is used in the TFRC equation to compute the
  sending rate. In this letter, we propose a new method to compute the packet
  loss rate which is more computationally efficient and remains as accurate as
  the classical commonly used method. The motivation of this work is to reduce
  the computation time and formulate a unified computation scheme. This method
  is based on the Newton's algorithm issued from numerical analysis of the TCP
  throughput equation. This proposal is evaluated analytically and the results
  show a significant improvement in terms of the computation time%
  }
  \field{booktitle}{Communications Letters, IEEE}
  \verb{doi}
  \verb 10.1109/LCOMM.2007.061707
  \endverb
  \field{issn}{1089-7798}
  \field{number}{3}
  \field{pages}{276\bibrangedash 278}
  \field{title}{Optimization of {TFRC} Loss History Initialization}
  \verb{url}
  \verb http://dx.doi.org/10.1109/LCOMM.2007.061707
  \endverb
  \field{volume}{11}
  \field{journaltitle}{IEEE Communications Letters}
  \field{month}{03}
  \field{year}{2007}
\endentry

\entry{2009vint_ns_manual}{manual}{}
  \keyw{manual, network, ns-2, simulator}
  \field{abstract}{%
  ns is LBNL's Network Simulator. The simulator is written in C++; it uses OTcl
  as a command and configuration interface. ns v2 has three substantial changes
  from ns v1: (1) the more complex objects in ns v1 have been decomposed into
  simpler components for greater flexibility and composability; (2) the
  configuration interface is now OTcl, an object oriented version of Tcl; and
  (3) the interface code to the OTcl interpreter is separate from the main
  simulator.%
  }
  \field{title}{The ns Manual (formerly ns Notes and Documentation)}
  \verb{url}
  \verb http://www.isi.edu/nsnam/ns/doc/index.html
  \endverb
  \field{month}{01}
  \field{year}{2009}
\endentry

\entry{rfc3775}{report}{}
  \name{author}{3}{}{%
    {{}%
     {Johnson}{J.}%
     {David}{D.}%
     {}{}%
     {}{}}%
    {{}%
     {Perkins}{P.}%
     {Charles~E.}{C.~E.}%
     {}{}%
     {}{}}%
    {{}%
     {Arkko}{A.}%
     {Jari}{J.}%
     {}{}%
     {}{}}%
  }
  \keyw{ietf, ipv6, mipv6, mobility, rfc}
  \strng{namehash}{JDPCEAJ1}
  \strng{fullhash}{JDPCEAJ1}
  \field{abstract}{%
  This document specifies a protocol which allows nodes to remain reachable
  while moving around in the IPv6 Internet. Each mobile node is always
  identified by its home address, regardless of its current point of attachment
  to the Internet.While situated away from its home, a mobile node is also
  associated with a care-of address, which provides information about the
  mobile node's current location. IPv6 packets addressed to a mobile node's
  home address are transparently routed to its care-of address. The protocol
  enables IPv6 nodes to cache the binding of a mobile node's home address with
  its care-of address, and to then send any packets destined for the mobile
  node directly to it at this care-of address. To support this operation,
  Mobile IPv6 defines a new IPv6protocol and a new destination option. All IPv6
  nodes, whether mobile or stationary, can communicate with mobile nodes.%
  }
  \field{howpublished}{Internet Requests for Comments}
  \field{number}{3775}
  \field{title}{Mobility Support in {IPv6}}
  \verb{url}
  \verb http://www.rfc-editor.org/rfc/rfc3775.txt
  \endverb
  \field{type}{RFC}
  \field{month}{06}
  \field{year}{2004}
\endentry

\entry{2001ernst_mobiwan}{manual}{}
  \name{author}{1}{}{%
    {{}%
     {Ernst}{E.}%
     {Thierry}{T.}%
     {}{}%
     {}{}}%
  }
  \keyw{ipv6, mipv6, mobility, mobiwan, module, ns-2, simulation}
  \strng{namehash}{ET1}
  \strng{fullhash}{ET1}
  \field{title}{Mobi{W}an: A ns-2.1b6 Simulation Platform for Mobile {IP}v6 in
  Wide Area Networks}
  \verb{url}
  \verb http://www.inrialpes.fr/planete/mobiwan/
  \endverb
  \field{month}{05}
  \field{year}{2001}
\endentry

\entry{2004mattsson_dccp_ns2}{thesis}{}
  \name{author}{1}{}{%
    {{}%
     {Mattsson}{M.}%
     {Nils-Erik}{N.-E.}%
     {}{}%
     {}{}}%
  }
  \keyw{dccp, module, ns-2, simulation, transport}
  \strng{namehash}{MNE1}
  \strng{fullhash}{MNE1}
  \field{abstract}{%
  The Datagram Congestion Control Protocol (DCCP) is a proposal for a new
  transport protocol. In short, DCCP is an unreliable protocol like UDP, but
  provides congestion control like TCP. DCCP can be easily extended to support
  multiple congestion control mechanisms. Currently there are two congestion
  control mechanisms, TCP-like and TFRC, specified. The goal of this master
  thesis project was to implement a DCCP module for the Network Simulator (ns)
  that supports both TCP-like and TFRC congestion control and all features
  needed for them to function according to the specifications. The resulting
  module provides a good base for further development and evaluation of the
  DCCP protocol. Well-defined interfaces enable code reutilisations in future
  implementations, both for simulation and for real- world usage. This thesis
  includes, besides a description of the design, discussions and possible
  solutions to issues found in the specification. Also, simulation results from
  a comparison between the throughputs of SACK based TCP and TCP- like are
  presented.%
  }
  \field{issn}{1402-1617}
  \field{number}{175}
  \field{title}{A {DCCP} Module for ns-2}
  \verb{url}
  \verb http://epubl.luth.se/1402-1617/2004/175/index-en.html
  \endverb
  \field{volume}{2004}
  \field{type}{mathesis}
  \field{month}{05}
  \field{year}{2004}
\endentry

\entry{1995ypma_newton-raphson}{article}{}
  \name{author}{1}{}{%
    {{}%
     {Ypma}{Y.}%
     {Tjalling~J.}{T.~J.}%
     {}{}%
     {}{}}%
  }
  \keyw{algorithm, equation, mathe, mathematic, newton, raphson, solution}
  \strng{namehash}{YTJ1}
  \strng{fullhash}{YTJ1}
  \field{abstract}{%
  This expository paper traces the development of the Newton--Raphson method
  for solving nonlinear algebraic equations through the extant notes, letters,
  and publications of Isaac Newton, Jospeph Raphson and Thomas Simpson. It is
  shown how Newton's formulation differed from the iterative process of
  Raphson, and that Simpson was the first to give a general formulation, in
  terms of fluxional calculus, applicable to nonpolynomial equations. Simpson's
  extension of the method to systems of equations is exhibited.%
  }
  \verb{doi}
  \verb 10.1137/1037125
  \endverb
  \field{issn}{0036-1445}
  \field{number}{4}
  \field{pages}{531\bibrangedash 551}
  \field{title}{Historical Development of the {N}ewton--{R}aphson Method}
  \verb{url}
  \verb http://dx.doi.org/10.1137/1037125
  \endverb
  \field{volume}{37}
  \field{journaltitle}{SIAM Review}
  \field{month}{12}
  \field{year}{1995}
\endentry

\entry{2001koodli_fast_handover_context_transfer}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Koodli}{K.}%
     {Rajeev}{R.}%
     {}{}%
     {}{}}%
    {{}%
     {Perkins}{P.}%
     {Charles~E.}{C.~E.}%
     {}{}%
     {}{}}%
  }
  \keyw{context, fmipv6, ipv6, mipv6, mobility, qos, quality, rohc, wireless}
  \strng{namehash}{KRPCE1}
  \strng{fullhash}{KRPCE1}
  \field{abstract}{%
  We describe recent work enabling fast handovers and context transfer between
  access routers offering Internet connectivity for mobile (often wireless)
  nodes. We present our framework for engineering general context transfer
  solutions, and a protocol which uses the framework to provide a simple yet
  general mechanism for carrying out context transfers during handovers. Since
  our mechanism operates at the network level, we expect that it will be the
  most expedient way to provide for seamless handovers between heterogeneous
  networks. We report our results which show that fast handovers with context
  transfer at the network layer can support uninterrupted voice over IP (VoIP).
  Thus, our context transfer framework will catalyze the arrival of a unified
  wireless telecommunications network, with voice and data connectivity
  anytime, anywhere. Towards that end, we describe how our results and context
  transfer framework relate to other work within the IETF.%
  }
  \verb{doi}
  \verb 10.1145/1037107.1037113
  \endverb
  \field{issn}{0146-4833}
  \field{number}{5}
  \field{pages}{37\bibrangedash 47}
  \field{title}{Fast Handovers and Context Transfers in Mobile Networks}
  \verb{url}
  \verb http://www.ieee802.org/21/archived_docs/2003-09_incoming/ccr-200109-koo
  \verb dli.pdf
  \endverb
  \field{volume}{31}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{10}
  \field{year}{2001}
\endentry

\entry{2004lee_mipv6_handoff_analysis}{inproceedings}{}
  \name{author}{3}{}{%
    {{}%
     {Lee}{L.}%
     {Jun~S.}{J.~S.}%
     {}{}%
     {}{}}%
    {{}%
     {Koh}{K.}%
     {Seok~J.}{S.~J.}%
     {}{}%
     {}{}}%
    {{}%
     {Kim}{K.}%
     {Sang~H.}{S.~H.}%
     {}{}%
     {}{}}%
  }
  \keyw{analysis, delay, handoff, ipv6, mipv6, mobility}
  \strng{namehash}{LJSKSJKSH1}
  \strng{fullhash}{LJSKSJKSH1}
  \field{abstract}{%
  The handoff delay required for Mobile IPv6 is analysed by investigating the
  concerned handoff delay components. From testbed experiments, it is shown
  that the measured handover delays are almost the same as the analytical
  results.%
  }
  \field{booktitle}{VTC2004-Fall, 60th IEEE Vehicular Technology Conference}
  \verb{doi}
  \verb 10.1109/VETECF.2004.1400604
  \endverb
  \field{isbn}{0-7803-8521-7}
  \field{issn}{1090-3038}
  \field{pages}{2967\bibrangedash 2969 Vol. 4}
  \field{title}{Analysis of Handoff Delay for Mobile {IPv6}}
  \verb{url}
  \verb http://dx.doi.org/10.1109/VETECF.2004.1400604
  \endverb
  \field{volume}{4}
  \field{journaltitle}{Vehicular Technology Conference, 2004. VTC2004-Fall.
  2004 IEEE 60th}
  \field{month}{09}
  \field{year}{2004}
\endentry

\entry{1999balakrishnan_integrated_congestion_control}{article}{}
  \name{author}{3}{}{%
    {{}%
     {Balakrishnan}{B.}%
     {Hari}{H.}%
     {}{}%
     {}{}}%
    {{}%
     {Rahul}{R.}%
     {Hariharan~S.}{H.~S.}%
     {}{}%
     {}{}}%
    {{}%
     {Seshan}{S.}%
     {Srinivasan}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, congestionmanager, cross-layer, transport}
  \strng{namehash}{BHRHSSS1}
  \strng{fullhash}{BHRHSSS1}
  \field{abstract}{%
  This paper presents a novel framework for managing network congestion from an
  end-to-end perspective. Our work is motivated by trends in traffic patterns
  that threaten the long-term stability of the Internet. These trends include
  the use of multiple independent concurrent flows by Web applications and the
  increasing use of transport protocols and applications that do not adapt to
  congestion. We present an end-system architecture centered around a
  Congestion Manager (CM) that ensures proper congestion behavior and allows
  applications to easily adapt to network congestion. Our framework integrates
  congestion management across all applications and transport protocols. The CM
  maintains congestion parameters and exposes an API to enable applications to
  learn about network characteristics, pass information to the CM, and schedule
  data transmissions. Internally, it uses a window-based control algorithm, a
  scheduler to regulate transmissions, and a lightweight protocol to elicit
  feedback from receivers.We describe how TCP and an adaptive real-time
  streaming audio application can be implemented using the CM. Our simulation
  results show that an ensemble of concurrent TCP connections can effectively
  share bandwidth and obtain consistent performance, without adversely
  affecting other network flows. Our results also show that the CM enables
  audio applications to adapt to congestion conditions without having to
  perform congestion control or bandwidth probing on their own. We conclude
  that the CM provides a useful and pragmatic framework for building adaptive
  Internet applications.%
  }
  \verb{doi}
  \verb 10.1145/316194.316220
  \endverb
  \field{issn}{0146-4833}
  \field{number}{4}
  \field{pages}{175\bibrangedash 187}
  \field{title}{An Integrated Congestion Management Architecture for {I}nternet
  Hosts}
  \verb{url}
  \verb http://dx.doi.org/10.1145/316194.316220
  \endverb
  \field{volume}{29}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{10}
  \field{year}{1999}
\endentry

\entry{2011mehani_multihomed_flow_management}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Mehani}{M.}%
     {Olivier}{O.}%
     {}{}%
     {}{}}%
    {{}%
     {Boreli}{B.}%
     {Roksana}{R.}%
     {}{}%
     {}{}}%
    {{}%
     {Maher}{M.}%
     {Michael}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Ernst}{E.}%
     {Thierry}{T.}%
     {}{}%
     {}{}}%
  }
  \keyw{2011, 3g, 80211, 80216, caor, constraintprogramming, flowdistribution,
  imara, inria, minesparistech, minizinc, mobile, network, networkedsystems,
  networkselection, nicta, oliviermehani, wifi, wimax}
  \strng{namehash}{MOBRMM+1}
  \strng{fullhash}{MOBRMMET1}
  \field{abstract}{%
  We consider the problem of network selection and flow distribution for a
  multihomed mobile device. We argue the benefits of a holistic approach which
  considers user- and application-centric metrics such as quality, energy
  consumption and monetary cost, rather than the commonly used network-centric
  metrics. We thus introduce the multihomed flow management problem which
  combines network selection, flow distribution and application flow awareness.
  We formulate it as a constrained optimisation problem and compare it to
  commonly used techniques: single network selection and load balancing. For
  selected interactive applications, we use empirical network measurements to
  evaluate the optimal solutions obtained by the three approaches. We show
  that, by exploiting the flexibility of application parameters, it is possible
  to achieve the potentially conflicting goals of maintaining high application
  quality while reducing both the power consumption and cost of network use.%
  }
  \field{booktitle}{LCN 2011}
  \field{isbn}{978-1-61284-928-7}
  \field{pages}{26\bibrangedash 34}
  \field{title}{User- and Application-Centric Multihomed Flow Management}
  \verb{url}
  \verb http://www.nicta.com.au/pub?id=4578
  \endverb
  \field{month}{10}
  \field{year}{2011}
\endentry

\entry{2009piri_80221}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Piri}{P.}%
     {Esa}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Pentikousis}{P.}%
     {Kostas}{K.}%
     {}{}%
     {}{}}%
  }
  \keyw{80221, handoff, handover, mediaindependenthandover, mih, wireless}
  \strng{namehash}{PEPK1}
  \strng{fullhash}{PEPK1}
  \field{abstract}{%
  Popular mobile devices now ship with several integrated wired and wireless
  network interfaces. Personal Digital Assistants (PDAs) and smartphones, for
  example, are increasingly supporting communications through both cellular
  technologies and Wireless LANs (WLANs); laptops typically come with built-in
  Ethernet, Wi-Fi, and Bluetooth [1]. As multiaccess devices proliferate, we
  move closer to a network environment that is often referred to as "beyond 3G"
  (B3G). Key success factors for cellular third-generation (3G) communications
  include better cell capacities, increased data rates, transparent mobility
  within large geographical areas, and global reachability. For B3G, the next
  frontier lies beyond transparent mobile connections within the same access
  technology because users will expect to be globally reachable anytime,
  anywhere, and remain "always best-connected" (ABC) [2]. In order to select
  the best possible connectivity option (anytime, anywhere), mobile devices and
  access networks will have to work together in order to enable users to take
  full advantage of all available options.%
  }
  \field{number}{2}
  \field{pages}{7\bibrangedash 27}
  \field{title}{{IEEE} 802.21}
  \verb{url}
  \verb http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-2/122
  \verb _ieee.html
  \endverb
  \field{volume}{12}
  \field{journaltitle}{The Internet Protocol Journal}
  \field{month}{06}
  \field{year}{2009}
\endentry

\entry{2010lochin_chameleon}{article}{}
  \name{author}{4}{}{%
    {{}%
     {Lochin}{L.}%
     {Emmanuel}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Jourjon}{J.}%
     {Guillaume}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Ardon}{A.}%
     {S\'{e}bastien}{S.}%
     {}{}%
     {}{}}%
    {{}%
     {Senac}{S.}%
     {Patrick}{P.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, noeditor, reliable, tfrc, transport}
  \strng{namehash}{LEJGAS+1}
  \strng{fullhash}{LEJGASSP1}
  \field{abstract}{%
  Rate-based congestion control, such as TFRC, has not been designed to enable
  reliability. Indeed, the birth of TFRC protocol has resulted from the need
  for a congestion-controlled transport protocol in order to carry multimedia
  traffic. However, certain applications still prefer the use of UDP in order
  to implement their own congestion control on top of it. The present
  contribution proposes to design and validate a reliable rate-based protocol
  based on the combined use of TFRC, SACK and an adapted flow control. We argue
  that rate-based congestion control is a perfect alternative to window-based
  congestion control as most of today applications need to interact with the
  transport layer and should not be only limited to unreliable services. In
  this paper, we detail the implementation of a reliable rate-based protocol
  named Chameleon and bring out to the networking community an ns-2
  implementation for evaluation purpose.%
  }
  \verb{doi}
  \verb 10.1504/IJIPT.2010.039229
  \endverb
  \field{issn}{1743-8217}
  \field{number}{4}
  \field{pages}{175\bibrangedash 189}
  \field{title}{Promoting the Use of Reliable Rate-based Transport Protocols:
  the {C}hameleon Protocol}
  \verb{url}
  \verb http://www.nicta.com.au/pub?doc=3015
  \endverb
  \field{volume}{5}
  \field{journaltitle}{International Journal of Internet Protocol Technology}
  \field{year}{2010}
\endentry

\entry{2004gurtov_modelling_wireless}{article}{}
  \name{author}{2}{}{%
    {{}%
     {Gurtov}{G.}%
     {Andrei}{A.}%
     {}{}%
     {}{}}%
    {{}%
     {Floyd}{F.}%
     {Sally}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{congestioncontrol, mobility, simulation, transport, wireless}
  \strng{namehash}{GAFS1}
  \strng{fullhash}{GAFS1}
  \field{abstract}{%
  Wireless links have intrinsic characteristics that affect the performance of
  transport protocols; these include variable bandwidth, corruption, channel
  allocation delays, and asymmetry. In this paper we review simulation models
  for cellular, WLAN and satellite links used in the design of transport
  protocols, and consider the interplay between wireless links and transport.
  We argue that the design and evaluation of transport protocols can be
  improved by providing easily available models of wireless links that strike a
  balance between realism, generality, and detail.There is an ongoing tussle
  between wireless link design and transport protocol design, with papers about
  how wireless link designers should take into account the dynamics of TCP, and
  other papers about how TCP and other transport protocols can be designed or
  modified for better performance over current wireless link technologies. In
  this paper we consider how appropriate models for wireless links can help in
  this tussle, and in the general design and evaluation of transport protocols
  over wireless links.%
  }
  \verb{doi}
  \verb 10.1145/997150.997159
  \endverb
  \field{issn}{0146-4833}
  \field{number}{2}
  \field{pages}{85\bibrangedash 96}
  \field{title}{Modeling Wireless Links for Transport Protocols}
  \verb{url}
  \verb http://dx.doi.org/10.1145/997150.997159
  \endverb
  \field{volume}{34}
  \field{journaltitle}{SIGCOMM Computer Communication Review}
  \field{month}{04}
  \field{year}{2004}
\endentry

\entry{2005vacirca_umts_grprs_rtt_measurements}{inproceedings}{}
  \name{author}{3}{}{%
    {{}%
     {Vacirca}{V.}%
     {Francesco}{F.}%
     {}{}%
     {}{}}%
    {{}%
     {Ricciato}{R.}%
     {Fabio}{F.}%
     {}{}%
     {}{}}%
    {{}%
     {Pilz}{P.}%
     {Ren\'{e}}{R.}%
     {}{}%
     {}{}}%
  }
  \keyw{gprs, measurement, rtt, umts}
  \strng{namehash}{VFRFPR1}
  \strng{fullhash}{VFRFPR1}
  \field{abstract}{%
  In this paper we present some observations about TCP RTT as captured in the
  live traffic of an operational GPRS/UMTS network. RTT samples are extracted
  from traces collected by passive monitoring the Gn interfaces of one of the
  major providers in Austria, EU. We compare results for GPRS and UMTS, and
  expose some methodological issues involved in performing this type of
  analysis, for instance the potential bias introduced by heavy users. We also
  explore the correlation of RTT with time-of-day. The primary motivation for
  this research is to gain a better understanding of the dominant causes that
  shape the behaviour and the distribution of RTT across the TCP connections
  that populate a GPRS/UMTS network. The results presented here are useful for
  the scientific community, for instance to set more realistic simulation
  scenarios for other research activities. In addition, RTT measurements as
  obtained by large-scale passive monitoring can be used in combination with
  other indicators to build a summary indicator of the performances experienced
  by the TCP users at the scale of the whole network, i.e. a global RTT-based
  KPI (key performance indicator).%
  }
  \field{booktitle}{WICON 2005}
  \verb{doi}
  \verb 10.1109/WICON.2005.19
  \endverb
  \field{isbn}{0-7695-2382-X}
  \field{pages}{190\bibrangedash 197}
  \field{title}{Large-scale {RTT} measurements from an operational
  {UMTS}/{GPRS} network}
  \verb{url}
  \verb http://userver.ftw.at/~ricciato/darwin/wicon05-ricciato-metawin.pdf
  \endverb
  \field{journaltitle}{Wireless Internet, 2005. Proceedings. First
  International Conference on}
  \field{month}{07}
  \field{year}{2005}
\endentry

\entry{2005karapantelakis_ad-hoc_delay_experiments}{inproceedings}{}
  \name{author}{2}{}{%
    {{}%
     {Karapantelakis}{K.}%
     {Thanasis}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Iacovidis}{I.}%
     {Giorgos}{G.}%
     {}{}%
     {}{}}%
  }
  \keyw{80211, ad-hoc, delay, experiment, iperf, throughput}
  \strng{namehash}{KTIG1}
  \strng{fullhash}{KTIG1}
  \field{abstract}{%
  In this study we set up an ad-hoc testbed of heterogeneous devices and
  investigate the behavior of video and audio streaming over the TCP protocol.
  The metrics for measuring the quality of service (QoS) of the TCP flows, are
  TCP round trip time (RTT) and signal to noise ratio (SNR). Our findings
  indicate an inverse correlation between RTT and SNR, with the first value
  increasing exponentially after a lower SNR threshold. Device movement and
  large distances are two factors affecting RTT negatively. Finally we show
  that the impact of background traffic on these streaming applications is
  prominent, as it increases RTT significantly.%
  }
  \field{booktitle}{LCN 2005}
  \verb{doi}
  \verb 10.1109/LCN.2005.67
  \endverb
  \field{issn}{0742-1303}
  \field{pages}{554\bibrangedash 559}
  \field{title}{Experimenting with Real Time Applications in an {IEEE} 802.11b
  Ad Hoc Network}
  \verb{url}
  \verb http://dx.doi.org/10.1109/LCN.2005.67
  \endverb
  \field{volume}{0}
  \field{journaltitle}{Local Computer Networks, Annual IEEE Conference on}
  \field{month}{11}
  \field{year}{2005}
\endentry

\entry{2007grondalen_wimax_measures}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Gr{\o}ndalen}{G.}%
     {Ole}{O.}%
     {}{}%
     {}{}}%
    {{}%
     {Gr{\o}nsund}{G.}%
     {P\r{a}l}{P.}%
     {}{}%
     {}{}}%
    {{}%
     {Breivik}{B.}%
     {Tor}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Engelstad}{E.}%
     {Paal}{P.}%
     {}{}%
     {}{}}%
  }
  \keyw{80216, analysis, bandwidth, delay, measurement}
  \strng{namehash}{GOGPBT+1}
  \strng{fullhash}{GOGPBTEP1}
  \field{abstract}{%
  Much hype is spread about the performance of WiMAX, and many contrary
  statements are put forward. A reason for the confusion is that little or no
  published material exists about WiMAX performance based on measurements in
  real life field trials. We therefore set up a test-bed using WiMAX equipment
  now on the marked,and did extensive, real life field trial measurements. This
  paper presents measured throughput and received signal strength under
  conditions typical for fixed WiMAX systems. Based on the results, throughput
  is analyzed and analytical expressions representing the measurements are
  derived for easy use in models.%
  }
  \field{booktitle}{16th IST Mobile and Wireless Communications Summit}
  \verb{doi}
  \verb 10.1109/ISTMWC.2007.4299213
  \endverb
  \field{isbn}{1-4244-1662-0}
  \field{pages}{1\bibrangedash 5}
  \field{title}{Fixed {WiMAX} Field Trial Measurements and Analyses}
  \verb{url}
  \verb http://folk.uio.no/paalee/publications/wimax-mobilesummit-2007.pdf
  \endverb
  \field{journaltitle}{16th IST Mobile and Wireless Communications Summit}
  \field{month}{07}
  \field{year}{2007}
\endentry

\entry{2008halepovic_tcp_wimax}{inproceedings}{}
  \name{author}{4}{}{%
    {{}%
     {Halepovic}{H.}%
     {Emir}{E.}%
     {}{}%
     {}{}}%
    {{}%
     {Wu}{W.}%
     {Qian}{Q.}%
     {}{}%
     {}{}}%
    {{}%
     {Williamson}{W.}%
     {Carey}{C.}%
     {}{}%
     {}{}}%
    {{}%
     {Ghaderi}{G.}%
     {Majid}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{80216, measurement, rtt, tcp, throughput, transport}
  \strng{namehash}{HEWQWC+1}
  \strng{fullhash}{HEWQWCGM1}
  \field{abstract}{%
  We present active measurement results from a commercial IEEE
  802.16/WiMAX-based network, with primary focus on TCP performance. We compare
  four TCP variants, namely New Reno, Cubic, Vegas and Veno, using throughput,
  round-trip time (RTT), and retransmission rate metrics. While all TCP
  variants achieve similar throughput, they do so in different ways, with
  different impacts on the network performance. We identify adverse effects of
  TCP window auto-tuning in this environment and demonstrate that on the
  downlink, congestion losses dominate wireless transmission errors. We reveal
  several issues for this WiMAX-based network, including limited bandwidth for
  TCP, high RTT and jitter, and unfairness during bidirectional transfers. Such
  a network environment may be challenging for many wireless Internet
  applications, such as remote login, VoIP, and video streaming.%
  }
  \field{booktitle}{MASCOTS 2008}
  \verb{doi}
  \verb 10.1109/MASCOT.2008.4770565
  \endverb
  \field{isbn}{978-1-4244-2817-5}
  \field{issn}{1526-7539}
  \field{pages}{1\bibrangedash 10}
  \field{title}{{TCP} over {WiMAX}: A Measurement Study}
  \verb{url}
  \verb http://dx.doi.org/10.1109/MASCOT.2008.4770565
  \endverb
  \field{journaltitle}{Modeling, Analysis and Simulation of Computers and
  Telecommunication Systems, 2008. MASCOTS 2008. IEEE International Symposium
  on}
  \field{month}{09}
  \field{year}{2008}
\endentry

\entry{2004gates_iperf2}{manual}{}
  \name{author}{4}{}{%
    {{}%
     {Gates}{G.}%
     {Mark}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Tirumala}{T.}%
     {Ajay}{A.}%
     {}{}%
     {}{}}%
    {{}%
     {Dugan}{D.}%
     {Jon}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Gibbs}{G.}%
     {Kevin}{K.}%
     {}{}%
     {}{}}%
  }
  \keyw{iperf, manual}
  \strng{namehash}{GMTADJ+1}
  \strng{fullhash}{GMTADJGK1}
  \field{howpublished}{Part of Iperf's source code distribution}
  \field{title}{Iperf version 2.0.0}
  \verb{url}
  \verb http://iperf.sf.net
  \endverb
  \field{month}{05}
  \field{year}{2004}
\endentry

\entry{2005still_imagemagick}{book}{}
  \name{author}{1}{}{%
    {{}%
     {Still}{S.}%
     {Michael}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{image, imagemagick, unix}
  \strng{namehash}{SM1}
  \strng{fullhash}{SM1}
  \field{abstract}{%
  An open source project backed by years of continual development, ImageMagick
  supports over 90 image formats and can perform impressive operations such as
  creating images from scratch; changing colors; stretching, rotating, and
  overlaying images; and overlaying text on images. Whether you use ImageMagick
  to manage the family photos or to embark on a job involving millions of
  images, this book will provide you with the knowledge to manage your images
  with ease. \_The Definitive Guide to ImageMagick\_ explains all of these
  capabilities and more in a practical, learn-by-example fashion. Youll get
  comfortable using ImageMagick for any image-processing task. Through the
  books coverage of the ImageMagick interfaces for C, Perl, PHP, and Ruby,
  youll learn how to incorporate ImageMagick features into a variety of
  applications.%
  }
  \field{howpublished}{Hardcover}
  \field{isbn}{978-1590595904}
  \field{title}{The Definitive Guide to {I}mage{M}agick}
  \verb{url}
  \verb http://www.worldcat.org/isbn/1590595904
  \endverb
  \field{month}{12}
  \field{year}{2005}
\endentry

\entry{2013mehani_instrumentation_framework}{misc}{}
  \name{author}{4}{}{%
    {{}%
     {Mehani}{M.}%
     {Olivier}{O.}%
     {}{}%
     {}{}}%
    {{}%
     {Jourjon}{J.}%
     {Guillaume}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Rakotoarivelo}{R.}%
     {Thierry}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Ott}{O.}%
     {Max}{M.}%
     {}{}%
     {}{}}%
  }
  \keyw{2013, framework, measurement, nicta, oml, reporting}
  \strng{namehash}{MOJGRT+1}
  \strng{fullhash}{MOJGRTOM1}
  \field{abstract}{%
  Experimentation for research on the future Internet involves observing
  multiple metrics at various distributed points of the network under observa-
  tion. Be it in a testbed or in an uncontrolled field experiment, collecting
  these measurements is not an easy task. The relevant experimental data tends
  to be scattered across multiple hosts in different, incompatible formats, and
  sometimes buried amongst a trove of other measurements, irrelevant to the
  current question. Collecting, selecting and formatting the useful records is
  a time-consuming manual operation. In this paper, we present a conceptual
  framework to facilitate this task. It includes a common representation of any
  type of experimental data, as well as the elements to process and collect the
  measurement samples. We then introduce the OML suite, an instrumen- tation
  library following the concept of this framework. We outline its API and how
  it can be used to instrument an experiment in only a few lines of code. We
  also present an evaluation of this library, demonstrating that it can be used
  non-intrusively with respect to the processes and systems under observation,
  as well as confirming the validity of the proposed framework.%
  }
  \field{howpublished}{Under review}
  \field{title}{An Instrumentation Framework for the Critical Task of
  Measurement Collection in the Future {I}nternet}
  \field{journaltitle}{Computer Networks}
  \field{year}{2012}
\endentry

\entry{2004lartc_howto}{manual}{}
  \name{author}{8}{}{%
    {{}%
     {Hubert}{H.}%
     {Bert}{B.}%
     {}{}%
     {}{}}%
    {{}%
     {Graf}{G.}%
     {Thomas}{T.}%
     {}{}%
     {}{}}%
    {{}%
     {Maxwell}{M.}%
     {Gregory}{G.}%
     {}{}%
     {}{}}%
    {{}%
     {Van~Mook}{V.~M.}%
     {Remco}{R.}%
     {}{}%
     {}{}}%
    {{}%
     {Van~Oosterhout}{V.~O.}%
     {Martijn}{M.}%
     {}{}%
     {}{}}%
    {{}%
     {Schroeder}{S.}%
     {Paul~B.}{P.~B.}%
     {}{}%
     {}{}}%
    {{}%
     {Spaans}{S.}%
     {Jasper}{J.}%
     {}{}%
     {}{}}%
    {{}%
     {Larroy}{L.}%
     {Pedro}{P.}%
     {}{}%
     {}{}}%
  }
  \keyw{howto, iproute2, linux, netfilter, network, routing, tc}
  \strng{namehash}{HBGTMG+1}
  \strng{fullhash}{HBGTMGVMRVOMSPBSJLP1}
  \field{abstract}{%
  A very hands-on approach to iproute2, traffic shaping and a bit of
  netfilter.%
  }
  \field{howpublished}{Online publication}
  \field{title}{Linux Advanced Routing \& Traffic Control {HOWTO}}
  \verb{url}
  \verb http://lartc.org/lartc.pdf
  \endverb
  \field{month}{04}
  \field{year}{2004}
\endentry

\entry{2005hemminger_netem}{inproceedings}{}
  \name{author}{1}{}{%
    {{}%
     {Hemminger}{H.}%
     {Stephen}{S.}%
     {}{}%
     {}{}}%
  }
  \keyw{emulation, linux, netem, network}
  \strng{namehash}{HS1}
  \strng{fullhash}{HS1}
  \field{abstract}{%
  Many protocols and applications performpoorly when exposed to real life
  networks withdelay and packet loss. Often, it is costly anddifficult to
  reproduce Internet behavior in acontrolled environment. There are tools
  avail-able for testing, but they are either expen-sive hardware solutions,
  proprietary software,or limited research projects. NetEm is a recent
  enhancement of thetraffic control facilities of Linux that allowsadding
  delay, packet loss and other scenario's.Documentation and discussion of NetEm
  ismaintained at http://developer.osdl.org/shemminger/netem. NetEm is built
  using theexisting Quality Of Service (QOS) and Dif-ferentiated Services
  (diffserv) facilities in theLinux kernel.%
  }
  \field{booktitle}{LCA 2005}
  \field{title}{Network Emulation with {NetEm}}
  \verb{url}
  \verb http://www.linux.org.au/conf/2005/abstract2e37.html?id=163
  \endverb
  \field{month}{04}
  \field{year}{2005}
\endentry

\lossort
\endlossort

\endinput
