draft-ietf-rmcat-scream-cc-00.txt   draft-ietf-rmcat-scream-cc-01.txt 
RMCAT WG I. Johansson RMCAT WG I. Johansson
Internet-Draft Z. Sarker Internet-Draft Z. Sarker
Intended status: Informational Ericsson AB Intended status: Experimental Ericsson AB
Expires: November 3, 2015 May 2, 2015 Expires: January 7, 2016 July 6, 2015
Self-Clocked Rate Adaptation for Multimedia Self-Clocked Rate Adaptation for Multimedia
draft-ietf-rmcat-scream-cc-00 draft-ietf-rmcat-scream-cc-01
Abstract Abstract
This memo describes a rate adaptation algorithm for conversational This memo describes a rate adaptation algorithm for conversational
video services. The solution conforms to the packet conservation video services. The solution conforms to the packet conservation
principle and uses a hybrid loss and delay based congestion control principle and uses a hybrid loss and delay based congestion control
algorithm. The algorithm is evaluated over both simulated Internet algorithm. The algorithm is evaluated over both simulated Internet
bottleneck scenarios as well as in a LTE (Long Term Evolution) system bottleneck scenarios as well as in a LTE (Long Term Evolution) system
simulator and is shown to achieve both low latency and high video simulator and is shown to achieve both low latency and high video
throughput in these scenarios. throughput in these scenarios.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 3, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 3 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4
3.1. Congestion Control . . . . . . . . . . . . . . . . . . . 4 3.1. Congestion Control . . . . . . . . . . . . . . . . . . . 4
3.2. Transmission Scheduling . . . . . . . . . . . . . . . . . 5 3.2. Transmission Scheduling . . . . . . . . . . . . . . . . . 5
3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 5 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 5
4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 5 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 5
4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 5 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Constants and Parameter values . . . . . . . . . . . 7 4.1.1. Constants and Parameter values . . . . . . . . . . . 7
4.1.2. Network congestion control . . . . . . . . . . . . . 11 4.1.2. Network congestion control . . . . . . . . . . . . . 11
4.1.2.1. Congestion window update . . . . . . . . . . . . 12 4.1.2.1. Congestion window update . . . . . . . . . . . . 12
4.1.2.2. Transmission scheduling . . . . . . . . . . . . . 16 4.1.2.2. Transmission scheduling . . . . . . . . . . . . . 16
4.1.3. Video rate control . . . . . . . . . . . . . . . . . 17 4.1.3. Video rate control . . . . . . . . . . . . . . . . . 17
4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 19 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 19
5. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 20 5. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 20
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. Source code . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Implementation status . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. Change history . . . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 13. Change history . . . . . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Additional features . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . 25
A.1. Packet pacing . . . . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 26
A.2. Stream prioritization . . . . . . . . . . . . . . . . . . 26 Appendix A. Additional features . . . . . . . . . . . . . . . . 27
A.3. Q-bit semantics (source quench) . . . . . . . . . . . . . 28 A.1. Packet pacing . . . . . . . . . . . . . . . . . . . . . . 27
A.4. Frame skipping . . . . . . . . . . . . . . . . . . . . . 29 A.2. Stream prioritization . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 A.3. Q-bit semantics (source quench) . . . . . . . . . . . . . 30
A.4. Frame skipping . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Congestion in the internet is a reality and applications that are Congestion in the internet is a reality and applications that are
deployed in the internet must have congestion control schemes in deployed in the internet must have congestion control schemes in
place not only for the robustness of the service that it provides but place not only for the robustness of the service that it provides but
also to ensure the function of the currently deployed internet. As also to ensure the function of the currently deployed internet. As
the interactive realtime communication imposes a great deal of the interactive realtime communication imposes a great deal of
requirements on the transport, a robust, efficient rate adaptation requirements on the transport, a robust, efficient rate adaptation
for all access types is considered as an important part of for all access types is considered as an important part of
skipping to change at page 3, line 21 skipping to change at page 3, line 23
in available channel bandwidth. This memo describes a solution,named in available channel bandwidth. This memo describes a solution,named
SCReAM, that is based on the self-clocking principle of TCP and uses SCReAM, that is based on the self-clocking principle of TCP and uses
techniques similar to what is used in a new delay based rate techniques similar to what is used in a new delay based rate
adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor
LEDBAT was designed for interactive realtime media, a few extra LEDBAT was designed for interactive realtime media, a few extra
features are needed to make the concept work well within this features are needed to make the concept work well within this
context. This memo describes these extra features. context. This memo describes these extra features.
1.1. Wireless (LTE) access properties 1.1. Wireless (LTE) access properties
[I-D.draft-sarker-rmcat-cellular-eval-test-cases] introduces the [I-D.ietf-rmcat-wireless-tests] introduces the complications that can
complications that can be observed in wireless environments. be observed in wireless environments. Wireless access such as LTE
Wireless access such as LTE can typically not guarantee a given can typically not guarantee a given bandwidth, this is true
bandwidth, this is true especially for default bearers. The network especially for default bearers. The network throughput may vary
throughput may vary considerably for instance in cases where the considerably for instance in cases where the wireless terminal is
wireless terminal is moving around. moving around.
Unlike wireline bottlenecks with large statistical multiplexing it is Unlike wireline bottlenecks with large statistical multiplexing it is
not possible to try to maintain a given bitrate when congestion is not possible to try to maintain a given bitrate when congestion is
detected with the hope that other flows will yield, this because detected with the hope that other flows will yield, this because
there are generally few other flows competing for the same there are generally few other flows competing for the same
bottleneck. Each user gets its own variable throughput bottleneck, bottleneck. Each user gets its own variable throughput bottleneck,
where the throughput depends on factors like channel quality, network where the throughput depends on factors like channel quality, network
load and historical throughput. The bottom line is, if the load and historical throughput. The bottom line is, if the
throughput drops, the sender has no other option than to reduce the throughput drops, the sender has no other option than to reduce the
bitrate. In addition, the grace time, i.e. allowed reaction time bitrate. In addition, the grace time, i.e. allowed reaction time
skipping to change at page 23, line 12 skipping to change at page 23, line 12
o Describe how clock drift compensation is done o Describe how clock drift compensation is done
o Describe how FEC overhead is accounted for in target_bitrate o Describe how FEC overhead is accounted for in target_bitrate
computation computation
o Investigate the impact of more sparse RTCP feedback, for instance o Investigate the impact of more sparse RTCP feedback, for instance
once per RTT once per RTT
o Describe ECN behavior o Describe ECN behavior
9. Source code 9. Implementation status
Source code for SCReAM is available in two formats : [Editor's note: Please remove the whole section before publication,
as well reference to RFC 6982]
o C++ code, that is apt for experimentation. The code maitained as This section records the status of known implementations of the
Visual Studio project. This code can possibly be included in protocol defined by this specification at the time of posting of this
simulators such as NS3. Avaliable at Internet-Draft, and is based on a proposal described in [RFC6982].
https://github.com/EricssonResearch/scream The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
o OpenWebRTC implementation : Work in progress, see According to [RFC6982], "this will allow reviewers and working groups
http://www.openwebrtc.io/ for information about the OpenWebRTC to assign due consideration to documents that have the benefit of
project running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see it".
9.1. OpenWebRTC
The SCReAM algorithm has been implemented in the OpenWebRTC project
[OpenWebRTC], an open source WebRTC implementation from Ericsson
Research. This SCReAM implementation is usable with any WebRTC
endpoint using OpenWebRTC.
o Organization : Ericsson Research, Ericsson.
o Name : OpenWebRTC gst plug-in.
o Implementation link : The GStreamer plug-in code for SCReAM can be
found at github repository [SCReAM-Implementation] and is waiting
to be merged with the master branch of OpebWebRTC repository
(https://github.com/EricssonResearch/openwebrtc/pull/413).
However, people are encouraged to have look at it and send
feedback. This wiki
(https://github.com/EricssonResearch/openwebrtc/wiki) contains
required information for building and using OpenWebRTC. Note that
to get all the SCReAM related code and build them, one has to use
the cerbero fork from DanielLindstrm' s repository
(https://github.com/DanielLindstrm/cerbero/tree/scream) instead of
EricssonResearch fork of cerbero.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]. The
current implementation has been tuned and tested to adapt video
stream and does not adapt the audio streams.
o Implementation experience : The implementation of the algorithm in
the OpenWebRTC has given great insight into the algorithm itself
and its interaction with other involved modules such as encoder,
RTP queue etc. In fact it proves the usability of a self-clocked
rate adaptation algorithm in the real WebRTC system. The
implementation experience has led to various algorithm
improvements both in terms of stability and design. For example,
improved rate increase behavior and removal of the ACK vector from
the feedback message.
o Contact : irc://chat.freenode.net/openwebrtc
9.2. A C++ Implementation of SCReAM
o Organization : Ericsson Research, Ericsson.
o Name : SCReAM.
o Implementation link : A C++ implementation of SCreAM is also
available which is aimed for doing quick
experiments[SCReAM-Cplusplus_Implementation]. This repository
also includes a rudimentary implementation of a simulator. This
code can be included in other simulators like NS-3.
o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]
o Contact : ingemar.s.johansson@ericsson.com,
zaheduzzaman.sarker@ericsson.com
10. Acknowledgements 10. Acknowledgements
We would like to thank the following persons for their comments, We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm,
Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson,
Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard
Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund.
skipping to change at page 23, line 49 skipping to change at page 25, line 22
12. Security Considerations 12. Security Considerations
The feedback can be vulnerable to attacks similar to those that can The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at affect TCP. It is therefore recommended that the RTCP feedback is at
least integrity protected. least integrity protected.
13. Change history 13. Change history
A list of changes: A list of changes:
o WG-00 to WG-01 : Changed the Source code section to Implementation
status section.
o -05 to WG-00 : First version of WG doc, moved additional features o -05 to WG-00 : First version of WG doc, moved additional features
section to Appendix. Added description of prioritization in section to Appendix. Added description of prioritization in
SCReAM. Added description of additional cap on target bitrate SCReAM. Added description of additional cap on target bitrate
o -04 to -05 : ACK vector is replaced by a loss counter, PT is o -04 to -05 : ACK vector is replaced by a loss counter, PT is
removed from feedback, references to source code added removed from feedback, references to source code added
o -03 to -04 : Extensive changes due to review comments, code o -03 to -04 : Extensive changes due to review comments, code
somewhat modified, frame skipping made optional somewhat modified, frame skipping made optional
skipping to change at page 25, line 5 skipping to change at page 26, line 27
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
December 2012. December 2012.
14.2. Informative References 14.2. Informative References
[FACK] "Forward Acknowledgement: Refining TCP Congestion [FACK] "Forward Acknowledgement: Refining TCP Congestion
Control", 2006. Control", 2006.
[I-D.draft-sarker-rmcat-cellular-eval-test-cases]
Sarker, Z., "Evaluation Test Cases for Interactive Real-
Time Media over Cellular Networks",
<http://www.ietf.org/id/
draft-sarker-rmcat-cellular-eval-test-cases-00.txt>.
[I-D.ietf-rmcat-app-interaction] [I-D.ietf-rmcat-app-interaction]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP
Application Interaction with Congestion Control", draft- Application Interaction with Congestion Control", draft-
ietf-rmcat-app-interaction-01 (work in progress), October ietf-rmcat-app-interaction-01 (work in progress), October
2014. 2014.
[I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-00 (work in
progress), May 2015.
[I-D.ietf-rmcat-wireless-tests]
Sarker, Z. and I. Johansson, "Evaluation Test Cases for
Interactive Real-Time Media over Wireless Networks",
draft-ietf-rmcat-wireless-tests-00 (work in progress),
June 2015.
[I-D.ietf-tcpm-newcwv] [I-D.ietf-tcpm-newcwv]
Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to support Rate-Limited Traffic", draft-ietf-tcpm- TCP to support Rate-Limited Traffic", draft-ietf-tcpm-
newcwv-10 (work in progress), April 2015. newcwv-13 (work in progress), June 2015.
[OpenWebRTC]
"Open WebRTC project.", <http://www.openwebrtc.io/>.
[QoS-3GPP] [QoS-3GPP]
TS 23.203, 3GPP., "Policy and charging control TS 23.203, 3GPP., "Policy and charging control
architecture", June 2011, <http://www.3gpp.org/ftp/specs/ architecture", June 2011, <http://www.3gpp.org/ftp/specs/
archive/23_series/23.203/23203-990.zip>. archive/23_series/23.203/23203-990.zip>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July
2013.
[SCReAM-Cplusplus_Implementation]
"C++ Implementation of SCReAM",
<https://github.com/EricssonResearch/scream>.
[SCReAM-Implementation]
"SCReAM Implementation",
<https://github.com/DanielLindstrm/openwebrtc-gst-
plugins/tree/scream>.
[TFWC] University College London, "Fairer TCP-Friendly Congestion [TFWC] University College London, "Fairer TCP-Friendly Congestion
Control Protocol for Multimedia Streaming", December 2007, Control Protocol for Multimedia Streaming", December 2007,
<http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/ <http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/
tfwc-conext.pdf>. tfwc-conext.pdf>.
Appendix A. Additional features Appendix A. Additional features
This section describes additional features. They are not required This section describes additional features. They are not required
for the basic functionality of SCReAM but can improve performance in for the basic functionality of SCReAM but can improve performance in
certain scenarios and topologies. certain scenarios and topologies.
 End of changes. 15 change blocks. 
41 lines changed or deleted 137 lines changed or added

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