Internet DRAFT - draft-ohanlon-rmcat-dflow

draft-ohanlon-rmcat-dflow







Network Working Group                                        P. O'Hanlon
Internet-Draft                                      University of Oxford
Intended status: Standards Track                             K. Carlberg
Expires: October 26, 2013                                            G11
                                                          April 24, 2013


  Congestion control algorithm for lower latency and lower loss media
                               transport
                      draft-ohanlon-rmcat-dflow-02

Abstract

   This memo provides a 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 October 26, 2013.

Copyright Notice

   Copyright (c) 2013 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 October 26, 2013                [Page 1]

Internet-Draft       DFlow media congestion control           April 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions, Definitions and Acronyms . . . . . . . . . . . .   3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  TFRC  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Delay-Based schemes . . . . . . . . . . . . . . . . . . .   4
   4.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Design Outline  . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Delay Composition . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Delay Measurement . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Congestion Detection  . . . . . . . . . . . . . . . . . .   7
     5.4.  Slow Start  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.5.  Loss-mode . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Further Work  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9


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.

   Congestion control that aims to minimise the delay is important for
   real-time streams as high delay can render the communication
   unacceptable [ITU.G114.2003].  On today's Internet a number of 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 same filled queues.

   Thus when competing with TCP, without the widespread deployment of
   Active Queue Management that aims to minimise delay, (e.g.  Codel
   [I-D.nichols-tsvwg-codel]), it is not possible to maintain low delay



O'Hanlon & Carlberg     Expires October 26, 2013                [Page 2]

Internet-Draft       DFlow media congestion control           April 2013


   as TCP will do its best to keep the queues full and maximise the
   delay.

   However there are 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 competition 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].

3.  Background

   Whilst the existing standard for media transport, Real-time Transport
   Protocol (RTP) [RFC3550], suggests 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 real-time 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], Sisalem's LDA+ [SisalemLDA.2000],
   and Choi's TCP Friendly Window Control (TFWC) [ChoiTFWC.2007] have
   been devised for 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 smoothed 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



O'Hanlon & Carlberg     Expires October 26, 2013                [Page 3]

Internet-Draft       DFlow media congestion control           April 2013


   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 real-time
   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 lost
      media packet cannot usually be retransmitted in time.  This
      problem becomes more of a concern at lower transmission rates
      since the TCP equation requires a corresponding increase in loss
      rates.

   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 data-limited and/or idle behaviours.
      Secondly there may be positive 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
      some of these issues, they are still a concern.

   Small RTT environments:  When operating in low RTT environments
      (<5ms), such as a LAN, systems implementing TFRC can have problems
      with scheduling packet transmissions as inter-packet timings can
      be lower than application level clock granularity.  Whilst the
      current version of TFRC [RFC5348] has attempted to address these
      issues, they can still be a concern in some 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.  However this issue is only
      really a marked problem with lower bit rate video flows or
      variable packet rate audio.

3.2.  Delay-Based schemes




O'Hanlon & Carlberg     Expires October 26, 2013                [Page 4]

Internet-Draft       DFlow media congestion control           April 2013


   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 based approaches such as
   Jain's CARD, Wang and Crowcroft's Tri-S, Brakmo's Vegas, Tan et al's
   Compound TCP, and more recently Budzisz's CxTCP [BudziszCxTCP.2011].
   Where the primary goal with 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 [GhanbariFuzzy.2007] 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.  However [RFC6817] specifies a one-
   way queuing delay target of 100ms which is quite a high baseline for
   interactive media, considering the recommended total one-way delay
   limit for a VoIP call should be less than 150ms [ITU.G114.2003].

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.

   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 it 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 advantage 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 more palatable media consumption.

   Fairness:  The system should aim to be reasonably fair with itself
      and TCP flows.  Initially we aim for self fairness, and we will
      aim to tackle TCP fairness when we have sufficiently robust loss-
      mode operation.






O'Hanlon & Carlberg     Expires October 26, 2013                [Page 5]

Internet-Draft       DFlow media congestion control           April 2013


   [Burst Management]:  [Due in later rev] We are working on mechanisms
      to manage the bursty nature of media allowing it maintain a
      smoother quality.

   [Loss-based mode]:  [Due in later rev] We are working 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

   The DFlow scheme aims to primarily utilise delay measurements to
   drive the congestion control.  It currently utilises some of the core
   aspects of TFRC, such as its rate based operation, utilisation of the
   TCP equation, and its rate smoothing.  It also employs similar
   signalling mechanisms.  However as the design evolves we expect that
   DFlow may diverge further from TFRC.

5.1.  Delay Composition

   The total end-to-end one-way delay (OWD) a packet incurs may be
   considered to consist of four elements; transmission (or
   serialisation), propagation, processing, and queuing delays.  For our
   purposes the first three elements may be considered together as a
   largely static component, termed the base delay.  The base delay
   generally does not change significantly unless the node is mobile or
   the underlying link alters due to something like a route change.  The
   main dynamic element of the delay, which DFlow aims to utilise, is
   the queuing delay.  Taken together with the base delay, the queuing
   delay provides an indication of the actual path latency and also
   provides an insight as to the level of congestion on the path.

5.2.  Delay Measurement

   The notional one-way delay is measured for each packet by comparing
   the sender and receiver timestamps.  Whilst the clocks on the sender
   and receiver are unlikely to be synchronised, it is assumed that
   their offset is relatively constant as the clock skew is generally
   quite small.  Thus the notional OWD may only be used in a relative
   context.  The notional OWD is measured for each packet over two
   sampling periods; Firstly over the longer base_period (typically
   10*RTT) from which the minima are stored as the base_delay.  And
   secondly it is sampled over a shorter period current_period
   (typically 50ms), which is also filtered, usually also using a minima
   filter, and stored as current_delay.  The minima of the OWDs are used
   to reduce noise of the measurements, which can be beneficial in the
   case of variable link types such as wireless.



O'Hanlon & Carlberg     Expires October 26, 2013                [Page 6]

Internet-Draft       DFlow media congestion control           April 2013


5.3.  Congestion Detection

   The delay-based detection algorithm, outlined in Figure 1, operates
   by comparing the current_delay to the base_delay, which gives an
   indication of the queuing delay.  If it exceeds a set congestion
   detection threshold, cd_thresh, then the packet is considered for the
   next stage of detection.  The cd_thresh sets the limit for the
   queuing delay incurred by the flow, and is typically set at 50ms (we
   are also investigating automated thresholds).  Once a flow has
   exceeded its cd_thresh then it undergoes a second test which is based
   upon the gradient of the delay change over two current_period's,
   indicating that delay is on the increase, if it is positive then a
   'congestion event' is flagged.

        If ((base_delay - current_delay) > cd_thresh AND
                  (current_delay - prev_current_delay) > 0)
                DelayCongestionEvent = True

                Figure 1: Congestion Detection pseudo-code

   This algorithm then provides input to the 'congestion interval
   history' mechanism (based on TFRC's 'loss interval history'), 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 currently disable TFRC's oscillation reduction mechanism
   from [RFC5348] (Section 4.5) as it adversely affects the delay-based
   operation.

   We have performed a number of simulations of the above mechanism in
   operation and have found it to be reasonably fair to itself,
   providing for smooth rates at suitable RTTs.

5.4.  Slow Start

   The delay based congestion detection is not only used during normal
   the congestion avoidance phase of the protocol but it also employed
   during slow start allowing for rapid, lower loss, attainment of the
   operating rate.

5.5.  Loss-mode

   We are actively investigating techniques to enable competitive
   behaviours with loss-based protocol such as TCP.  We aim to develop a
   solution that provides for automatic fallback between loss and delay
   modes.




O'Hanlon & Carlberg     Expires October 26, 2013                [Page 7]

Internet-Draft       DFlow media congestion control           April 2013


6.  Further Work

   The design is still under active development and there is more work
   to be done.  We are seeking feedback on these ideas and future
   directions.

7.  IANA Considerations

   This document makes no requests of IANA.

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 largely 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

   [BudziszCxTCP.2011]
              Budzisz, L., Stanojevic, R., Schlote, A., Shorten, R., and
              F. Baker, "On the Fair Coexistence of Loss- and Delay-
              Based TCP", July 2011.

   [ChoiTFWC.2007]
              Choi, S. and M. Handley, "Fairer TCP-friendly congestion
              control protocol for multimedia streaming applications",
              Dec 2007.

   [GhanbariFuzzy.2007]
              Jammeh, E., Fleury, M., and M. Ghanbari, "Delay-based
              congestion avoidance for video communication with fuzzy
              logic control", Nov 2007.



O'Hanlon & Carlberg     Expires October 26, 2013                [Page 8]

Internet-Draft       DFlow media congestion control           April 2013


   [I-D.nichols-tsvwg-codel]
              Nichols, K. and V. Jacobson, "Controlled Delay Active
              Queue Management", draft-nichols-tsvwg-codel-01 (work in
              progress), February 2013.

   [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.

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              December 2012.

   [SisalemLDA.2000]
              Sisalem, D. and A. Wolisz, "LDA+: A TCP-Friendly
              Adaptation Scheme for Multimedia Communication", May 2000.

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


   Ken Carlberg
   G11
   1600 Clarendon Blvd
   Arlington  VA
   USA

   Email: carlberg@g11.org.uk










O'Hanlon & Carlberg     Expires October 26, 2013                [Page 9]