Internet DRAFT - draft-burness-dccp-interactive-apps
draft-burness-dccp-interactive-apps
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]
