draft-ietf-rmcat-cc-requirements-01.txt   draft-ietf-rmcat-cc-requirements-02.txt 
Network Working Group R. Jesup Network Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational December 21, 2013 Intended status: Informational February 14, 2014
Expires: June 24, 2014 Expires: August 18, 2014
Congestion Control Requirements For RMCAT Congestion Control Requirements For RMCAT
draft-ietf-rmcat-cc-requirements-01 draft-ietf-rmcat-cc-requirements-02
Abstract Abstract
Congestion control is needed for all data transported across the Congestion control is needed for all data transported across the
Internet, in order to promote fair usage and prevent congestion Internet, in order to promote fair usage and prevent congestion
collapse. The requirements for interactive, point-to-point real time collapse. The requirements for interactive, point-to-point real time
multimedia, which needs low-delay, semi-reliable data delivery, are multimedia, which needs low-delay, semi-reliable data delivery, are
different from the requirements for bulk transfer like FTP or bursty different from the requirements for bulk transfer like FTP or bursty
transfers like Web pages. transfers like Web pages.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 24, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The traditional TCP congestion control requirements were developed in The traditional TCP congestion control requirements were developed in
order to promote efficient use of the Internet for reliable bulk order to promote efficient use of the Internet for reliable bulk
transfer of non-time-critical data, such as transfer of large files. transfer of non-time-critical data, such as transfer of large files.
They have also been used successfully to govern the reliable transfer They have also been used successfully to govern the reliable transfer
of smaller chunks of data in as short a time as possible, such as of smaller chunks of data in as short a time as possible, such as
when fetching Web pages. when fetching Web pages.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
recover. Note that this traffic may on an access link, or recover. Note that this traffic may on an access link, or
may cause a shift in the location of the bottleneck fir the may cause a shift in the location of the bottleneck fir the
duration of the burst. duration of the burst.
2. The algorithm must be fair to other flows, both realtime flows 2. The algorithm must be fair to other flows, both realtime flows
(such as other instances of itself), and TCP flows, both long- (such as other instances of itself), and TCP flows, both long-
lived and bursts such as the traffic generated by a typical web lived and bursts such as the traffic generated by a typical web
browsing session. Note that 'fair' is a rather hard-to-define browsing session. Note that 'fair' is a rather hard-to-define
term. term.
A. Existing flows at a bottleneck must also be fair to new
flows to that bottleneck, and must allow new flows to ramp
up to a useful share of the bottleneck bandwidth quickly.
3. The algorithm should where possible merge information across 3. The algorithm should where possible merge information across
multiple RTP streams between the same endpoints, whether or not multiple RTP streams between the same endpoints, whether or not
they're multiplexed on the same ports, in order to allow they're multiplexed on the same ports, in order to allow
congestion control of the set of streams together instead of as congestion control of the set of streams together instead of as
multiple independent streams. This allows better overall multiple independent streams. This allows better overall
bandwidth management, faster response to changing conditions, bandwidth management, faster response to changing conditions,
and fairer sharing of bandwidth with other network users. and fairer sharing of bandwidth with other network users.
Alternatively, it should work with an external bandwidth control Alternatively, it should work with an external bandwidth control
framework to coordinate bandwidth usage across a bottleneck, framework to coordinate bandwidth usage across a bottleneck,
such as draft-welzl-rmcat-coupled-cc such as draft-welzl-rmcat-coupled-cc
skipping to change at page 6, line 21 skipping to change at page 6, line 25
envisioned in order of priority: faster-than-audio, audio, envisioned in order of priority: faster-than-audio, audio,
video, best-effort, and bulk-transfer. Typically the flows video, best-effort, and bulk-transfer. Typically the flows
managed by this algorithm would be audio or video in that managed by this algorithm would be audio or video in that
heirarchy, and feedback flows would be faster-than-audio. heirarchy, and feedback flows would be faster-than-audio.
7. The algorithm should sense the unexpected lack of backchannel 7. The algorithm should sense the unexpected lack of backchannel
information as a possible indication of a channel overuse information as a possible indication of a channel overuse
problem and react accordingly to avoid burst events causing a problem and react accordingly to avoid burst events causing a
congestion collapse. congestion collapse.
8. It should attempt to avoid bandwidth 'collapse' when facing a 8. The algorithm should not starve competing TCP flows, and should
long-lived saturating TCP flow or flows. (I.e. a classic delay- as best as possible avoid starvation by TCP flows.
sensitive algorithm will reduce bandwidth to keep delay down
until the TCP flow has all the bandwidth). See the Cx-TCP A. An algorithm may be more successful at avoiding starvation
algorithm discussed in a recent Transactions On Networking from short-lived TCP long-lived/saturating TCP flows.
[cx-tcp] for an example of a delay-sensitive congestion-control
algorithm that transitions to a loss-based mode when competing B. In order to avoid starvation other goals may need to be
with TCP flows - at the cost of increased delay. compromised (such as delay).
9. The algorithm should be stable and low-delay when faced with 9. The algorithm should be stable and low-delay when faced with
active queue management (AQM) algorithms. Also note that these active queue management (AQM) algorithms. Also note that these
algorithms may apply across multiple queues in the bottleneck, algorithms may apply across multiple queues in the bottleneck,
or to a single queue or to a single queue
10. The algorithm should quickly adapt to initial network conditions 10. The algorithm should quickly adapt to initial network conditions
at the start of a flow. This should occur both if the initial at the start of a flow. This should occur both if the initial
bandwidth is above or below the bottleneck bandwidth. bandwidth is above or below the bottleneck bandwidth.
skipping to change at page 8, line 44 skipping to change at page 9, line 5
[I-D.welzl-rmcat-coupled-cc] [I-D.welzl-rmcat-coupled-cc]
Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion
control for RTP media", draft-welzl-rmcat-coupled-cc-02 control for RTP media", draft-welzl-rmcat-coupled-cc-02
(work in progress), October 2013. (work in progress), October 2013.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[cx-tcp] Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and
R. Shorten, "On the Fair Coexistence of Loss- and Delay-
Based TCP", December 2011.
Author's Address Author's Address
Randell Jesup Randell Jesup
Mozilla Mozilla
USA USA
Email: randell-ietf@jesup.org Email: randell-ietf@jesup.org
 End of changes. 10 change blocks. 
19 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/