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]