33. Deployment Considerations for Congestion Control in Real-Time Interactive Media Systems
slides-ccirtcws-deployment-considerations-for-congestion-control-in-real-time-interactive-media-systems-00

Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                             July 28, 2012
Expires: January 29, 2013


     Deployment Considerations for Congestion Control in Real-Time
                       Interactive Media Systems
                     draft-arkko-wscc-deployment-00

Abstract

   This short note is a late position paper submission to the IAB
   workshop on Congestion Control for Interactive Real-Time Traffic,
   held Saturday, July 28, 2012 in Vancouver.  This note considers the
   deployment incentives for congestion control solutions and compares
   the situation to the development of congestion control for web
   traffic over the years.

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 29, 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



Arkko                   Expires January 29, 2013                [Page 1]

Internet-Draft          Deployment Considerations              July 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Thoughts  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Case for Adaptivity . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Case for Aggressive Behaviour . . . . . . . . . . . . . . . 3
     2.3.  Who Writes the Code?  . . . . . . . . . . . . . . . . . . . 4
     2.4.  What Needs to Change? . . . . . . . . . . . . . . . . . . . 5
     2.5.  What Would the Developer Do?  . . . . . . . . . . . . . . . 5
     2.6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 6
   3.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7


































Arkko                   Expires January 29, 2013                [Page 2]

Internet-Draft          Deployment Considerations              July 2012


1.  Introduction

   This note considers the deployment prospects for congestion control
   solutions.  We look at the incentives fromm the point of view of the
   developers of real-time applications such as those based on browsers
   implementing the WebRTC model with RTP underneath for actual
   transport of media streams [RFC3550].

   We also draw contrasts and similarities to the situation that has
   driven congestion control mechanisms in web traffic.


2.  Thoughts

2.1.  Case for Adaptivity

   The primary incentive for the real-time application developer lies in
   ensuring that the application works well.  It needs to survive
   varying network conditions and be able to adapt from high bandwidth
   office LANs to congestion, intermittent wireless connectivity, and
   other conditions.  The implication is that the application developer
   (and the browser developer in the case WebRTC) has incentives to
   measure network performance and optimize the application's
   performance under the observed conditions.

   There is an additional incentive for doing measurements.  It is
   important to accurately reflect the cause of network problems, as
   this can help speed up the solving those problems, such as badly
   configured router or insufficiently provisioned links.

      Note that the current public perception tends to focus on
      bandwidth rather than latency or other qualities of network
      services.  It would be important to provide tools similar to
      speedtest.net for measuring these other qualities, as they often
      have a bigger effect on real-time services than mere bandwidth.

2.2.  Case for Aggressive Behaviour

   The application needs also needs to work at least as well as other
   competing applications.  It would typically not be acceptable to
   provide lesser media quality than competing applications, as a clear
   difference would cause users to migrate to the application with
   better performance.  This implies at the very least that yielding to
   other traffic sooner than other applications is not in the
   developer's interests.

   But it may also imply that aggressive (or at least semi-aggressive)
   mechanisms get implemented among the competing applications.  As an



Arkko                   Expires January 29, 2013                [Page 3]

Internet-Draft          Deployment Considerations              July 2012


   example, speed has been a major user preference factor among web
   browsers.  While the underlying transport behaviour has been safe and
   the same (TCP) for all implementations, many browsers fetch a
   significant number of objects in parallel, many Javascript
   applications open multiple connections, and many web sites distribute
   their content across multiple servers.  These techniques essentially
   dilute a part of the fairness model that the TCP is based on.  TCP
   provides fairness between flows, and a large number of flows per user
   implies that the user gets a higher share of the network capacity
   than a user with small number of flows.  This can be considered one
   example of the two-party overconsumption attack in [Rescorla].

   That being said, the Internet works remarkably well today, despite
   the contention for resources and the ever increasing amount of
   traffic.  The world has not ended.

2.3.  Who Writes the Code?

   It is also interesting to note the universal use of the underlying
   TCP model.  There has been multiple reasons for this, one being it
   being the standard way to communicate between web clients and
   servers, its placement in the kernel in typical operating system
   architecture, the relative complexity of writing a new
   implementation, and the easy availability of code bases that support
   TCP.  While replacing or tweaking TCP might have offered benefits for
   some applications to be even more aggressive than they are today,
   this was largely not done for the above reasons.  It was too hard,
   and to some extent, unnecessary, as there were tools above TCP that
   would provide the same benefits as tweaking TCP.

   The situation with real-time traffic is obviously different, but
   similar principles may still apply.  A non-congestion controlled
   application can be easily developed, as UDP-based traffic is far
   simpler to generate and process than TCP.  However, an application
   that wishes to benefit from adaptivity may be significantly more
   complex to develop.  The WebRTC model where a relatively small number
   of browser implementations could provide congestion control and
   adaptive media behavior in a way that applications can build on.  As
   long as this support is safe in the similar way that TCP is, we can
   expect that similar development will occur as has occurred in the
   web.  In other words, contention and aggressiveness migrates to
   applications, while lower layers of the protocol stack and the
   implementation employ mechanisms that have been designed to optimize
   the entire network's performance, and not just this single
   application.  Interestingly, Ted Hardie [Hardie] argues for the same
   for slightly different reasons, namely that Javascript developers are
   unlikely to be experts enough in RTP feedback mechanisms to be able
   to provide this support.



Arkko                   Expires January 29, 2013                [Page 4]

Internet-Draft          Deployment Considerations              July 2012


2.4.  What Needs to Change?

   John Leslie has made the right observation, I think, that there is a
   need for action on several layers: application, transport, and
   network [Leslie].  The case for application and transport layers is
   perhaps obvious, but as John Leslie, Jim Gettys [Gettys], and Keith
   Winstein et al [Winstein] argue, unnecessary buffering (the
   "bufferbloat" problem) is making it difficult for TCP and interactive
   real-time traffic to co-exist in the network.

2.5.  What Would the Developer Do?

   And that is the main question.  We can theorize what would be best
   for the Internet, but ultimately what happens in this space is
   decided by application developers, browser framework developers,
   server developers, and those who deploy these components.

   If I was a developer, given the reasons in Section 2.1 and
   Section 2.2, I would want to ensure that my application behaves as
   well as possible.  If I were developing a server or browser
   framework, I'd probably have the ability add support for multiple
   mechanisms and not be too limited about complexity or the effort to
   develop them.  So, ideally, I'd be able to consider inputs such as

   o  ECN notifications

   o  packet drop

   o  delay variations

   o  application hints on what is important and what is not

   o  application signaling with the peer(s) about the performance

   In general, there are a few different classes of mechanisms
   available:

   o  Application and browser behaviour, essentially everything in the
      above list, as far as the application code, server, or the browser
      framework is concerned.

   o  Unilateral router behaviour, such as ECN or buffering improvements
      suggested in [Gettys].

   o  Coordinated router behaviour in the network, such as deployment of
      new DiffServ and other quality-of-service mechanisms.

   Simple analysis indicates that the first class of mechanisms is the



Arkko                   Expires January 29, 2013                [Page 5]

Internet-Draft          Deployment Considerations              July 2012


   only one which the developer has control over.  As long as the
   implementation complexity is not an issue, adding the functionality
   is likely a positive action.  When the application sees an input such
   as delay variation or ECN marking, it can take action that benefits
   it.

   The other two classes are not under the control of the developer.
   However, the two classes differ in a significant way: adding ECN
   capabilities to one router [Sarker] potentially helps some
   applications some part of the time, without having to assume anything
   from other parts of the network.  At least some of the quality-of-
   service mechanisms require coordination between multiple routers,
   code point agreements, or even signaling between network parts,
   however.  These are more difficult to deploy, and evidence from past
   20 years suggests that such deployment is not very likely in the
   global Internet.

2.6.  Conclusions

   While the details of the first class of mechanisms are outside the
   scope of this memo (and outside my field of expertise), I am
   optimistic about their deployment.  Delay-based mechanisms, for
   instance, seem like the right fit for the problem.  We should expect
   to see these deployed as soon as browser frameworks have been updated
   to support what is needed.  But the worrisome aspect is what Jim
   Gettys and others have raised about the need to do something about
   buffering in the current Internet routers.  I agree with them that
   with overly aggressive buffering, there is little that other
   applications can do to save the real-time aspect of their
   communications.  So it seems that we have an Internet wide upgrade
   ahead of us.  But even so, we should focus on doing that in the
   simplest possible way.  My personal belief is that upgrades should
   fix the buffering problem, and that this is not a situation where we
   need to add complex quality-of-service functionality or other things.
   I am also cautiously optimistic about fixing the buffering problem,
   as it has been widely publicized, and occurs perhaps most widely in
   small home routers which are replaced quite frequently and are
   typically based on a handful of open source IP stacks.  Fix those,
   and we will have a better Internet in a couple of years.


3.  Informative References

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [Hardie]   Hardie, T., "RTP Congestion Control and RTCWEB Application



Arkko                   Expires January 29, 2013                [Page 6]

Internet-Draft          Deployment Considerations              July 2012


              Feedback", Position Paper in the IAB Workshop on
              Congestion Control for Interactive Real-Time Traffic ,
              July 2012.

   [Sarker]   Sarker, Z. and I. Johansson, "Improving the interactive
              real-time video communication with network provided
              congestion notification", Position Paper in the IAB
              Workshop on Congestion Control for Interactive Real-Time
              Traffic , July 2012.

   [Gettys]   Gettys, J., "The Internet is Broken, and How to Fix It",
              Position Paper in the IAB Workshop on Congestion Control
              for Interactive Real-Time Traffic , July 2012.

   [Leslie]   Leslie, J., "There is No Magic Transport Wand", Position
              Paper in the IAB Workshop on Congestion Control for
              Interactive Real-Time Traffic , July 2012.

   [Winstein]
              Winstein, K., Sivaraman, A., and H. Balakrishnan,
              "Congestion Control for Interactive Real-Time Flows on
              Today's Internet", Position Paper in the IAB Workshop on
              Congestion Control for Interactive Real-Time Traffic ,
              July 2012.

   [Rescorla]
              Rescorla, E., "Some Notes on Threat Modelling Congestion
              Management", Position Paper in the IAB Workshop on
              Congestion Control for Interactive Real-Time Traffic ,
              July 2012.


Appendix A.  Acknowledgments

   The author would like to thank the participants of the IAB CC
   Workshop and the IAB for interesting discussions in this problem
   space.


Author's Address

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@piuha.net




Arkko                   Expires January 29, 2013                [Page 7]