RMCAT WG X. Zhu
Internet-Draft Cisco Systems
Intended status: Informational Z. Sarker
Expires: January 8, 2017 Ericsson AB
July 7, 2016

Framework for Real-time Media Congestion Avoidance Techniques
draft-zhu-rmcat-framework-00

Abstract

Congestion control is an essential element in ensuring fair bandwidth usage and preventing congestion collapse for traffic sharing the Internet. For interactive real-time media traffic such as video conferencing, design of congestion control solution also needs to account for many other factors such as the requirement for low latency packet delivery and interactions with live video encoder. This document describes a common framework with the core functional building blocks for a real-time media congestion solutions.

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 8, 2017.

Copyright Notice

Copyright (c) 2016 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Given increasing amount of interactive real-time media traffic over the Internet, such as video conferencing, it is important that these applications employ proper congestion control mechanisms to avoid congestion collapse. [I-D.ietf-rmcat-cc-requirements] specifies the list of requirements of a viable solution.

This document outlines a common framework for designing a congestion control mechanism for real-time interactive communication, so that individual drafts on specific solutions follow a consistent set of terminologies in describing their respective components. The next section [sec-functional-modules] describes common functional modules in this framework, whereas Section 4 provides examples on how these modules build together to support single and multiple media streams.

[ Editor's note : This document does not describe the interaction between application, codec and congestion control system. The interaction among application, codec and congestion control system are defined in other documents. There is a possibility to merge all the documents into one single document. ]

2. Key Words for Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Functional Modules

A viable solution for real-time media congestion control needs to comprise of several common modules. This section provides a brief description of them and their respective functionalities. A congestion control solution for real-time media should comprise of the described functional modules. This should help understanding different congestion control solutions.

4. Example Configurations

4.1. Example Configurations for a Single Stream


                                                   RTCP Feedback
+---------+                       +-------------+   Reports
|  Live   |                       |   Network   |<---------------- 
|  Video  |<----------------+     |  Congestion |
| Encoder |                 |     |  Controller |
+---------+                 |     +-------------+        
    ||                      |            |(1)             
    ||                      |            |                
    ||                      |           \|/               
    ||    +--------------+  |  (4) +-------------+        
    ||    |   Network    |  +------|    Rate     | 
    ||    |    Probe     |<--------| Controller  | 
    ||    |  Generator   |    (5)  +-------------+
    ||    +--------------+          (3)|   /|\ 
    ||           ||                    |    |
    ||           || Probing           \|/   |(2)         
    ||           || Packets       +---------------+   
    ||           \\=============> |  Transmission | 
    \\==========================> |      Queue    |==============>
        Encoded Video Packets     +---------------+   Outgoing  
                                                       Packets     
                

Figure 1: RMCAT Solution Framework at the Sender: Single Stream

Figure 1 shows an example configuration at the sender for supporting a single media stream. The Network Congestion Controller estimates available bandwidth based on periodic RTCP feedback reports. The Rate Controller takes as input the estimated available bandwidth (1) and the current occupancy level of the Transmission Queue (2). It calculates as output sending rate (3) for the Transmission Queue, video target rate (4) for the Live Video Encoder, and probing rate (5) -- if they are needed -- for the Network Probe Generator. The Transmission Queue holds packets generated by both the Live Video Encoder and the Network Probe Generator; it paces transmission of its outgoing packets according to the sending rate (3) specified by Rate Controller.

Obviously, it is possible for a congestion control solution to contain alternative configurations between these functional modules. [TODO: add one quick example on alternative wiring.] It is required that the candidate solution draft specify how their internal functional modules align to this framework.

4.2. Example Configurations for Multiple Streams

  

                                                   RTCP Feedback
+---------+                       +-------------+   Reports
|  Live   |                       |   Network   |<---------------- 
|  Video  |<----------------+     |  Congestion |
| Encoder |                 |     |  Controller |
+---------+                 |     +-------------+      
    ||                      |            |(1)           
    ||                      |            |              
    ||                      |           \|/             
    ||                      |  (4) +-------------+      +--------+
    ||      +---------+     +------|    Rate     |<-----| Shared |  
    ||      |  Live   |     |      | Controller  |      | States |
    ||      |  Video  |<----+      +-------------+      +--------+
    ||      | Encoder |             (3)|   /|\ 
    ||      +---------+                |    |
    ||          ||                    \|/   |(2)         
    ||          ||                +---------------+   
    ||          ||                |  Transmission | 
    \\==========================> |      Queue    |==============>
        Encoded Video Packets     +---------------+   Outgoing  
                                                       Packets     
          

Figure 2: RMCAT Solution Framework at the Sender: Multiple Streams

Figure 2 shows an example configuration for multiple video streams sharing a common Network Congestion Controller. The Network Congestion Controller calculates an aggregated estimated available bandwidth (1) based on periodic RTCP feedback reports. The Rate Controller divides up the aggregate estimated bandwidth (1) from the Network Congestion Controller amongst sub-streams based on their relative priority levels, Shared States, as well as current occupancy level of the Transmission Queue. It subsequently determines the per-flow sending rate (3) as regulated by the Transmission Queue and target video rate (4) for each flow.

In this specific example, the transmission queue is envisioned as a logical entity. For instance, this transmission queue can be implemented priority-based scheduling and one physical queue per stream. For sake of simplicity the role of Network Probe Generator is omitted in the above figure.

5. Acknowledgements

The RMCAT design team discussions contributed to this memo.

6. IANA Considerations

This memo includes no request to IANA.

7. Security Considerations

TBD

8. References

8.1. Normative References

[I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", Internet-Draft draft-ietf-rmcat-cc-requirements-09, December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M. and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008.

8.2. Informative References

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980.

Authors' Addresses

Xianqing Zhu Cisco Systems 12515 Research Blvd., Building 4 Austin, TX 78759 USA EMail: xiaoqzhu@cisco.com
Zaheduzzaman Sarker Ericsson AB Luleae, Sweden Phone: 00 46 10 717 37 43 EMail: zaheduzzaman.sarker@ericsson.com