Network Working Group P. O'Hanlon
Internet-Draft University of Oxford
Intended status: Informational K. Carlberg
Expires: January 10, 2013 G11
July 9, 2012
Congestion control algorithm for lower latency and lower loss media
transport
draft-ohanlon-rmcat-dflow-00
Abstract
This memo provides an initial design for a congestion control
algorithm, for media transport, which aims to provide for lower delay
and lower loss communications.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
O'Hanlon & Carlberg Expires January 10, 2013 [Page 1]
Internet-Draft DFlow media congestion control July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TFRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Delay-Based schemes . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Design Outline . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Congestion Detection . . . . . . . . . . . . . . . . . . . 7
6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
O'Hanlon & Carlberg Expires January 10, 2013 [Page 2]
Internet-Draft DFlow media congestion control July 2012
1. Introduction
This memo outlines DFlow, a congestion control algorithm that aims to
minimise delay and loss by using delay-based techniques. The scheme
is based upon TCP Friendly Rate Control (TFRC) [RFC5348], and adds a
delay-based congestion detection scheme which feeds into a
'congestion event history' mechanism based upon TFRC's loss history.
This then provides for a 'congestion event rate' which drives the TCP
equation.
Low delay congestion control is important for real-time streams as
high delay can render the communication unacceptable [ITU.G114.2003].
Unfortunately on today's Internet many paths have an excess of
buffering which can lead to persistent high latencies, which has
become known as the Bufferbloat phenomenon. These problems are
particularly apparent with loss-based congestion control schemes such
as TCP, as they operate by filling the queues on a path till loss
occurs, thus maximising the delay. The unfortunate consequence is
that loss-based approaches not only lead to high delay for their own
packets but also introduce delays and losses for all other flows that
traverse those filled queues.
Thus when competing with TCP, without the widespread deployment of
Active Queue Management, it is not possible to maintain low delay as
TCP will do its best to keep the queues full and maximise the delay.
Furthermore when competing with TCP other flows will incur losses
which should be used to operate a loss-based algorithm whilst in the
presence of the TCP flows.
However there are a many paths where the flows are not competing
directly with TCP and where delay may be minimised.
The DFlow scheme can transport media with low delay and loss on paths
where there is no direct competion with TCP in the same queue.
Though we are currently testing some techniques to enable it compete
with loss-based schemes (at the expense of delay) but they will be
included in a later version of the draft. In simulations it has been
seen to be reasonably fair when competing with other DFlow streams.
2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
O'Hanlon & Carlberg Expires January 10, 2013 [Page 3]
Internet-Draft DFlow media congestion control July 2012
3. Background
Whilst the existing standard for media transport, Real-time Transport
Protocol (RTP) [RFC3550], suggest that congestion control should be
employed, in practice many systems tend to use fixed or variable bit
rate UDP and do very little or no adaptation to their network
environment. Most of the existing work on realtime congestion
control algorithms has been rooted in TCP-friendly approaches but
with smoother adaptation cycles. TCP congestion control is
unsuitable for interactive media for a number of reasons including
the fact that it is loss-based so it maximises the latency on a path,
it changes its transmit rate to quickly for multimedia, and favours
reliability over timeliness. Various TCP-friendly congestion control
algorithms such as TFRC [RFC5348], Sislem's LDA+, and Choi's TFWC
have been devised for unreliable media transport, that attempt to
smooth the short-term variation in sending rate. More recently there
have been development of some delay-based schemes which aim to
provide for low delay.
3.1. TFRC
TFRC is a rate based receiver driven congestion control algorithm
which utilises the Padhye TCP equation to provide a TCP-friendly
rate. The sender explicitly sets the transmission rate, using the
TCP equation driven by the loss event rate which is measured and fed
back by the receiver, where a loss event consists of one or more
packet losses within a single RTT. It utilises a weighted smoothed
loss event rate, and EWMA smoothed RTT, as input to the TCP Equation
which enables it to achieve a smoother rate adaptation that provides
for a more suitable transport for multimedia. TFRC was primarily
aimed at streaming media delivery where a smooth rate and TCP-
friendliness are more important than low latency operation.
However there are number of issues with TFRC as regards media
transport:
Loss-based operation: Firstly since it is a loss-based based scheme
the latency is maximised which is a problem for real-time
transport over heavily buffered paths. The other problem with
loss-based protocols is that they rely on a certain level of
packet loss which can be an issue for media traffic since
retransmissions are problematic. This problem is more of a
concern as rates decrease since the TCP equation requires a
corresponding increase in loss rates.
O'Hanlon & Carlberg Expires January 10, 2013 [Page 4]
Internet-Draft DFlow media congestion control July 2012
Bursty media flows: Many media flows exhibit bursty behaviour due to
a number of factors. Firstly there may be negative bursts (i.e.
gaps) due to silence or low motion which can lead oscillatory
behaviours due to the its data-limited and/or idle behaviours.
Secondly there may be postive bursts (i.e. larger than normal) can
also be due to the bursty nature of the media and codec (e.g.
I-frames) which can be lead to drops or increased latency. Whilst
the current version of TFRC [RFC5348] has attempted to address
these issues, they are still a concern.
Small RTTs environments: When operating in low RTT environments
(<5ms), such as a LAN, TFRC has can have problems with scheduling
packet transmissions as interpacket timings can be lower than
application level clock granularity. Furthermore these conditions
can Whilst the current version of TFRC [RFC5348] has attempted to
address these issues, they can still be a concern in low RTT
environments.
Variable packet sizes: As originally designed TFRC will only operate
correctly when packet sizes are close to MTU size, and when the
packet sizes are much smaller fairness issues arise. Although
there have been attempts to address this problem for small packets
[RFC4828] it is not clear how to deal with flows that do vary
their packet sizes substantially. Though this issue is only
really a marked problem with lower bit rate video flows or
variable packet rate audio.
3.2. Delay-Based schemes
In the last few years there has been a renewed interest in the use of
delay based congestion control for media, with a slightly different
emphasis to that of the history of TCP approaches such as Jain's
CARD, Crowcroft and Jon's Tri-S, Brakmo's Vegas, and more recently
Tan et al's Compound TCP. Whilst the goal with these media based
transports is to actually minimise the latency of the flow, as
opposed to just using delay as an early indication of loss. This is
of particular relevance on paths with large queues, as is the case
with a number of today's Internet paths. In 2007 Ghanbari et al did
some pioneering work on delay-based video congestion control using
fuzzy logic based systems. Recently there has been on going activity
in the IETF as part of the Low Extra Delay Background Transport
(LEDBAT) Working Group which aims to provide a less than best effort
delay-based transport with lower delay. More recently Google
published a contribution to the Real-Time Communication in WEB-
browsers (RTCWeb) Working Group, which has now been spun off to the
new BOF on RTP Media Congestion Avoidance Techniques (rmcat).
O'Hanlon & Carlberg Expires January 10, 2013 [Page 5]
Internet-Draft DFlow media congestion control July 2012
4. Objectives
The objectives of DFlow are to provide for low delay and low loss
media transport when possible. We also aim to provide (in a future
version of the draft) mechanisms to provide for better burst
management, and loss-mode operation (the key being the switch from
loss-mode back to delay-mode).
Lower Delay: The one-way delay should be kept well within the
acceptable levels of 150ms, and MUST NOT exceed 400ms
[ITU.G114.2003].
Lower Loss: For media transport is important to minimise loss as it
is usually not possible to retransmit within the delay budget for
many connections. Whilst modern codecs can tolerate some loss it
is beneficial to avoid it. The benefit of low delay congestion
control is that since it aims to operate within the queuing
boundaries it generally avoids loss.
Smoothness: The media rate should aim to be smooth within the
constraints of the media, codec, and the network path. A smooth
rate generally provides for a more palatable media consumption.
Fairness: The system should aim to be reasonably fair with TCP flows
and itself. Initially we aim for self fairness and we will aim to
tackle TCP fairness when we have sufficiently robust loss-mode
operation.
[Burst Management]: [Due in later rev] We aim to work on mechanisms
to manage the bursty nature of media allowing it maintain a
smoother quality. A smooth rate generally provides for a more
palatable media consumption.
[Loss-based mode]: [Due in later rev] We aim to wrok on mechanisms
to allow the system to compete with loss-based congestion control
and maintain throughput, though without additional network support
it is understood that the delay (and loss) would be largely beyond
control.
5. Design Outline
At this stage DFlow utilises the core aspects of TFRC, such as its
rate based operation, utilisation of the TCP equation, and its
smoother rate. It also utilises similar packet contents and
signalling mechanisms. However as the design evolves we realise that
DFlow may become quite separate from TFRC.
O'Hanlon & Carlberg Expires January 10, 2013 [Page 6]
Internet-Draft DFlow media congestion control July 2012
5.1. Congestion Detection
The delay-based detection algorithm operates by sampling the one-way
delay (OWD) of each packet arrival by comparing the send timestamp
with the receive time. The OWD is sampled over a small set time
period, sample_period, (typically 100ms) and the minima stored as the
BaseDelay over a longer period, base_period, (typically 5-10xRTT).
The current OWD is then compared to the BaseDelay and if it exceeds a
set threshold, CDthresh, (typically around 50ms) then the packet is
considered for the next stage of detection. The following test is
based upon the gradient of the delay change over two sample_periods,
indicating that delay is on the increase, if it is positive then a
'congestion event' is logged. The minima of the OWDs are used to
reduce noise of the measurements, which is beneficial in the case of
variable link types such as Wifi.
If ((BaseDelayMinNxRTT - OWD) > CDthresh AND
DelayIncreaseOver2RTTs > 0)
DelayCongestionEvent = True
Figure 1
This algorithm then provides input to the 'congestion interval
history' (or TFRC's 'loss interval history') mechanism, which is
combined with normal input from the TFRC packet loss detection
mechanisms, from which a 'congestion event rate' is derived which is
then fed into the TCP equation to determine the send rate.
Note that we disable TFRC's oscillation reduction mechanism from
Section 4.5 [RFC5348] as it adversely affects the delay-based
operation.
We have performed some simulations of the above mechanism in
operation and have found it to be reasonable fair to itself, though
it is not as smooth as TFRC.
6. Further Work
The design is still under development and there is clearly more work
to be done. But we are seeking feeback on these ideas and future
directions.
7. IANA Considerations
This document makes no requests of IANA.
O'Hanlon & Carlberg Expires January 10, 2013 [Page 7]
Internet-Draft DFlow media congestion control July 2012
8. Security Considerations
With a congestion control algorithm an attacker can attempt to
interfere with the protocol to cause rate changes. However
encryption of the protocol will protect it against such threats.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control
(TFRC): The Small-Packet (SP) Variant", RFC 4828,
April 2007.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.
9.2. Informative References
[ITU.G114.2003]
International Telecommunications Union, "One-way
transmission time", ITU-T Recommendation G.707, May 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Authors' Addresses
Piers O'Hanlon
University of Oxford
Oxford Internet Institute
1 St Giles
Oxford OX1 3JS
United Kingdom
Email: piers.ohanlon@oii.ox.ac.uk
O'Hanlon & Carlberg Expires January 10, 2013 [Page 8]
Internet-Draft DFlow media congestion control July 2012
Ken Carlberg
G11
1600 Clarendon Blvd
Arlington VA
USA
Email: carlberg@g11.org.uk
O'Hanlon & Carlberg Expires January 10, 2013 [Page 9]