DCCP Working Group A-L.Burness INTERNET DRAFT A. Smith draft-burness-dccp-interactive-apps-00.txt P. Eardley Expires: January 2006 BT July 8, 2005 Interactive Applications using DCCP draft-burness-dccp-interactive-apps-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 8, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Burness Expires January 8, 2006 [Page 1] Internet-Draft Interactive Apps using DCCP July 2005 Abstract This document discusses some issues that we, representing a network operator, believe should be addressed if DCCP is to become adopted as the means to congestion control interactive applications. Table of Contents 1. Introduction................................................2 1.1. The interest of DCCP to the network operator............3 2. Application Characteristics..................................5 3. Issues with TFRC............................................6 3.1. TFRC Rate Equation......................................6 3.2. Loss Rate Calculation...................................6 4. Initial Slow start..........................................7 5. Silence suppression.........................................8 6. Variable Bit Rate management.................................9 7. Interaction between various CCIDs and TCP...................10 8. User Intolerance of Changes in Quality......................11 9. Security Considerations.....................................11 10. Conclusions...............................................11 11. Informative References.....................................12 Intellectual Property Statement................................14 Disclaimer of Validity........................................14 Copyright Statement...........................................14 1. Introduction The trend of running streaming and real-time interactive services over UDP transport is perceived as potentially a serious threat to the future stability of the Internet [1]. This is because long-lived UDP traffic is not (always or correctly) congestion controlled, so if it exists in large quantities it could be unfair to other traffic or even lead to congestion collapse. Therefore a number of standards track documents have been written: o DCCP: this transport protocol [2] is designed to replace UDP for streamed UDP applications. It includes congestion control and manages this on behalf of the application. Different congestion control algorithms can be used, depending upon the nature of the traffic. Burness Expires January 8, 2006 [Page 2] Internet-Draft Interactive Apps using DCCP July 2005 o TFRC: [3] this is a congestion control mechanism that can exist fairly with current TCP congestion control, yet could be used to support applications that prefer slow, smooth changes in the sending rate, such as streaming media applications with small or moderate receiver buffering. o CCID3 in DDCP: this is an implementation of TFRC for DCCP. CCID 2 is also defined, which is TCP-like congestion response [4]. The key requirements of DCCP are to be able to provide an unreliable (fast) data transport for applications that generate large or long- lived flows (real-time and streaming), whilst protecting the networks against congestion collapse and still being fair to TCP traffic. The support of such flows comes from a combination of the base DCCP protocol and the congestion control mechanisms (CCID 2 & 3) used within the protocol. However, we believe that whilst CCID 2 and 3 give a range of suitable responses for many types of streaming applications, there is still a problem for a significant class of applications, which we call here real-time interactive applications. This document highlights the areas of concern. We describe first the applications that we feel are not adequately supported by the current congestion responses. We then discuss each of the specific problems in turn. Many of these problems are already familiar to those working in the area, and the work by Tom Phelan, Sally Floyd and Eddie Kohler amongst others has been built upon. The purpose of this document is to indicate the problems that we believe should form the basis of new study to be performed within the DCCP working group. 1.1. The interest of DCCP to the network operator We are interested because BT is moving all its networks to a single IP network. This single next generation network will carry all our current PSTN voice traffic, as well as an increasing proportion of other streamed traffic such as that caused by, for example, podcasting and video blogs. The Internet is becoming a feasible delivery medium for television and even HDTV. Whilst a vast range of applications has always co-existed within the Internet, simple file transfers (web, ftp) have remained the dominant Burness Expires January 8, 2006 [Page 3] Internet-Draft Interactive Apps using DCCP July 2005 application. It is possible that this position will change as networks are migrated to a common IP network. Even just considering voice, we estimate that the total number of voice bits transmitted over our networks is approximately equal to number of other-data bits within our networks today. We currently expect to have to use Quality of service and Admission Control to manage the congestion problem that would occur if this balance of traffic is present on our common IP network. However, a lightweight alternative, such as could be provided by the end-to-end control given by DCCP, is highly relevant to the roadmap for our future networks. It would also provide a safe option for network users who will not or cannot use a QoS-enabled network for example current wireless LAN networks. Our particular concern is with real-time interactive applications, such as peer-to-peer video telephony. These are the applications with the tightest time constraints (as opposed to other interactive applications such as the web). We believe that streaming applications with low levels of interactivity such as Internet radio can be adequately managed. Existing algorithms such as TFRC could, with suitable buffering strategies, be used without modification for this class of application [5]. Concern about the ability of TFRC to support real-time applications has already been expressed, and to date, activity has focused on solving the issues for voice traffic with a special variant of TFRC proposed for VoIP [6]. However, we have some issues with that proposal as we are not convinced that it adequately protects the network. Also, we would like to look at a general solution for all types of real-time traffic that would facilitate our ability to police our network. Ideally we should have a minimal number of congestion responses in order to simplify policing. Burness Expires January 8, 2006 [Page 4] Internet-Draft Interactive Apps using DCCP July 2005 2. Application Characteristics The applications about which we are concerned are voice, video, games and of course as yet unidentified future applications. These applications share some common characteristics that make congestion control within the current Internet difficult for them. o Voice - reacts to congestion through adjusting packet size, needs steady packet rate - typically uses small packets, TFRC unfair to these - silence suppression used to save bandwidth, it is not bandwidth greedy - minimum bandwidth is required. Codecs often only produce output at fixed bandwidth levels which are not related to the slow start and congestion avoidance mechanisms used by congestion control - users are intolerant of delay and delay variation - users are intolerant of quality fluctuations o Video - reacts to congestion control through adjusting packet size, needs steady packet rate - has mixture of small, medium and large packets - highly variable bandwidth requirements - up to factor 10 variations mean to peak bandwidth - minimum bandwidth is required. Codecs often only produce output at fixed bandwidth levels which are not related to the slow start and congestion avoidance mechanisms used by congestion control - users are intolerant of delay and delay variation Burness Expires January 8, 2006 [Page 5] Internet-Draft Interactive Apps using DCCP July 2005 - users are intolerant of quality fluctuations o Games - There are a large number of types of game. The set relevant here are those that send a continual stream of update messages. These will have characteristics similar to voice. 3. Issues with TFRC One problem is that TFRC assumes packet rate is varied and that packet size is fixed. Coupled with this is the fact that TFRC can be unfair to small packets. Fixing this problem requires changes to the TFRC rate equation and also the calculation that determines the last event rate to be used in that equation. 3.1. TFRC Rate Equation The proposed adjustment in [6] to the TFRC equation to allow applications to match their rate (including packet header overhead) with a TCP flow that would be carrying MTU sized packets simply fixes part of the packet rate problem. The addition of a minimum inter- packet spacing to prevent router processor overload is also supported. 3.2. Loss Rate Calculation It has been claimed [7] [8] that the loss event rate calculation needs to be changed if we wish to allow a congestion response to adjust packet size rather than packet rate. The rationale is that since a loss event is one or more packet losses per RTT, small-packet flows may get too much bandwidth as it becomes more likely that multiple loss events would all be considered as one loss event. Such Burness Expires January 8, 2006 [Page 6] Internet-Draft Interactive Apps using DCCP July 2005 flows over-estimate the loss interval - and hence under-estimate the loss rate. Another difficulty in calculating the loss rate is that the solution depends on whether or not the packet drop rate depends on packet size. For example, routers using RED in byte mode will have packet drop rate as a function of packet size. Although such routers are currently not common, assuming they are not can lead to schemes that are over-aggressive in the presence of such routers. Further study is recommended here. However, the virtual packets approach is commonly recommended [7] [8]. A virtual packet has arrived when MTU-worth of bytes is received; a virtual packet has been lost when MTU-worth of bytes is lost. The virtual packets are used instead of real ones to drive the TFRC calculation. 4. Initial Slow start The applications under consideration all have two characteristics that make congestion control uncomfortable for them - they operate at specific bandwidth levels, and a particular flow may vary which level it uses. The need for an initial bandwidth level before an application can start seems to be in conflict with the slow-start process that is used within congestion control to minimize the impact that a newly starting application will have on any existing flows. Slow start enables a new flow to ease itself gently onto the network. During slow start however, applications that require a minimum bandwidth cannot do any useful work. If we assume a voice (or moderate bit rate video) application with a target rate of 50 packets per second and a typical RTT of 200ms, then it would take about 1 second to reach a suitable data rate. Mobile- to-mobile call-set-up times are of the order 3-7 seconds (based on limited experiments by one of the authors). High bit rate videos often have multiple coding levels, so the lower levels can be transmitted whilst the rate is ramping up. Thus, the initial slow Burness Expires January 8, 2006 [Page 7] Internet-Draft Interactive Apps using DCCP July 2005 start may not be a significant problem from a user perspective. In order that the network is not made to transmit useless data during that time we note that that the application is typically exchanging call control data. It would clearly be beneficial if these different flows shared congestion information. RFC 3124 [9] describes a Congestion Manager for managing multiple flows, however further study is required to examine how this could be used with DCCP. One specific problem is how to handle the fact that each of these streams might have preferred to use different congestion control algorithms. 5. Silence suppression A voice application might have typical average speech bursts of 350ms, with silent spells of 500ms [13]. This is Codec dependent - figures are for G.729B, described as a modern codec. Longer times are associated with old-fashioned codecs to minimize effects of speech clipping. A key point to note is that silence suppression is not directly related to "who is talking now" Whilst you may listen silently to your mother lecturing you, if silence suppression was used the entire time you were quiet your mother would in fact assume you had left the phone. Noise may even be deliberately added to prevent this. If the voice application is using TFRC in DCCP then, when the application does not receive ACK packets for a time equal to the RTO (retransmit timeout), it assumes the network is seriously congested. Of course, if no data is sent to do silence suppression no ACKs will be returned, and the application will be forced to assume severe congestion and enter slow start. This could be very disruptive to the application. With a modern codec and a round trip time of less than 125ms, silence suppression would lead to regular time outs, putting the application back into slow start. This would be a common occurrence in sub-continental networks. However, a session with a longer round trip time - say 400ms for an international call, would not experience timeouts as a result of silence suppression. This clearly begs the question as to whether it is fair that you can reduce the problem of silence suppression timeouts by taking a longer path through the network? Burness Expires January 8, 2006 [Page 8] Internet-Draft Interactive Apps using DCCP July 2005 In [6] fast restart is allowed inside 10 minutes at the prior rate, reducing to the normal 4 packets minimum by 30 minutes. We consider this time is too long for two reasons. In a mobile environment the key assumption that path characteristics won't have changed much is untrue. And this solution is very specific to low bandwidth applications, it would not be suitable for applications like video and it could similarly be dangerous for networks with low capacity links. We propose a similar solution, but with a different timescale. As mentioned above, flows with long round trip times are unlikely to suffer because of silence suppression. Thus, we say that a maximum application idle time of (4*400ms) should be allowed, i.e. the voice of application can immediately operate at the previous rate if the silence is less than $*400ms. 400ms being the maximum RTT we would like to see for interactive traffic anyway [11], and is also approximately the biggest minimum round trip time you see round the world [12]. This time is long enough to help applications, and clearly short enough to protect current networks, ie if the application knows it has not sent data (no outstanding data to be acknowledged) then it need not activate the retransmit timer until after 1.2 seconds. There are still issues with this approach: It is less than clear how to handle this problem for longer idle times - such as those caused by a video being paused or interactive games. In order to protect the network, we think these problems should be handled by the applications for example, using application controlled predictive caching. There is also a problem for large scale multicast video-conferences, when a person with a question may need to come in quickly after listening to a presentation. 6. Variable Bit Rate management VBR is much more dramatic in video than voice, where the required sending rate may increase by a factor of 10 when there is a scene Burness Expires January 8, 2006 [Page 9] Internet-Draft Interactive Apps using DCCP July 2005 change, for example. However, scene changes are less likely for video conferencing applications. They will either be still or moving at a steady rate. Thus the variability that we need to support for real-time (as opposed to streaming) video applications may not be as great as the worst-case might suggest. Therefore, as is the case silence suppression for voice, we may be able to say that: o if the video has achieved its higher rate within a recent, limited time period o and the preceding rate reduction was due to action of the application and not as a result of a congestion response, o and the application has received no indication that congestion is increasing then it should be allowed to increase directly to that higher rate. Another approach to achieve the rate stability required to support VBR behaviors can be implemented if there are multiple streams that could share congestion state. For example, during the session there will typically be a (RTCP) control flow with every (RTP) data flow. There may be multiple data flows (voice, video, whiteboard). This would require that all the flows use the same congestion control as discussed above in section 4. on silence suppression. 7. Interaction between various CCIDs and TCP Simulations have been performed looking at how DCCP flows interact with TCP. An open question is how do the various DCCP algorithms interact with each other and TCP? Would a single CCID be better rather than different ones more suited to each application? Or would this simply increase the probability of abuse of congestion control? Burness Expires January 8, 2006 [Page 10] Internet-Draft Interactive Apps using DCCP July 2005 8. User Intolerance of Changes in Quality [10] has demonstrated that users prefer a stable level of quality for real-time applications rather than having spells where the quality improves only to degrade a short time later. This has repercussions on the ability to make maximum use of bandwidth after starting and also after a loss event has caused a flow to back-off. There seems little point in an application always probing for more bandwidth if this will always lead to a loss event and a back-off that leads to a lower quality for the user. A further aspect to this problem is that many real-time applications have set bandwidth levels in which they can operate, and it is not clear how they could probe the network for increased bandwidth anyway, without sending dummy data (or using congestion state sharing techniques). It may be that we will need a congestion response for real-time applications using DCCP and a real-time media guide to aid application developers to use the response. 9. Security Considerations TBA 10. Conclusions Further activity is required to determine how best to manage congestion for real-time interactive applications including telephony, video-phone services and games. We have described the basic characteristics of such applications. We have discussed the problems under the following topics: o Rate equation o Loss calculation o Slow start Burness Expires January 8, 2006 [Page 11] Internet-Draft Interactive Apps using DCCP July 2005 o Silence suppression o Variable Bit Rate In most cases, pointers to solutions already exist and need simply to be developed. However, a better understanding of application behavior might also be necessary, as it is likely that a number of engineering compromises will be needed. 11. Informative References [1] S. Floyd, M Handley, E. Kohler, DCCP Problem Statement, June 2005, draft-ietf-dccp-problem-01.txt [2] E. Kohler, M. Handley, S. Floyd, Datagram Congestion Control Protocol (DCCP), draft-ietf-dccp-spec-11.txt [3] S. Floyd, E. Kohler, Jitendra Padhye, Profile for DCCP Congestion Control ID 3: TFRC Congestion Control, draft-ietf- dccp-ccid3-11.txt [4] S. Floyd, E. Kohler, Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control, draft-ietf-dccp-ccid2-10.txt [5] T. Phelan, DCCP User Guide, April 2005, draft-ietf-dccp-user- guide-03.txt [6] S. Floyd, E. Kohler, TCP Friendly Rate Control (TFRC) for Voice: VoIP Variant and Faster Restart, February 2005, draft- ietf-dccp-tfrc-voip-01.txt [7] P Vasallo, Variable Packet size Equation-Based Congestion Control, International Computer Science Institute Technical Report May 2000 [8] Widmer et al, End to end congestion control for flows with variable packet sizes, ACM SIGCOMM Computer Communication Review Archive, Volume 34 , Issue 2, April 2004 [9] H. Balakrishnan, S. Seshan, The Congestion Manager, June 2001, RFC3124 [10] D. Hands, M. Wilkins, A Study of the Impact of Network Loss and Burst Size on Video Streaming Quality and Acceptability, IDMS 1999 Burness Expires January 8, 2006 [Page 12] Internet-Draft Interactive Apps using DCCP July 2005 [11] G.114 [12] Internet Traffic Report [13] Wenyu Jiang, H Schulzrinne, Analysis of on-off patterns in VoIP and their effect on voice traffic aggregation, Proceedings of ICCCN 2000 Author's Addresses Anne-Louise Burness BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: louise.burness@bt.com Alan Smith BT Research B54/74, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: alan.p.smith@bt.com Philip Eardley BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom Email: philip.eardley@bt.com Burness Expires January 8, 2006 [Page 13] Internet-Draft Interactive Apps using DCCP July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Burness Expires January 8, 2006 [Page 14]