draft-ietf-avtcore-rtp-multi-stream-optimisation-08.txt   draft-ietf-avtcore-rtp-multi-stream-optimisation-09.txt 
AVTCORE WG J. Lennox AVTCORE WG J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: April 4, 2016 Ericsson Expires: May 27, 2016 Ericsson
Q. Wu Q. Wu
Huawei Huawei
C. Perkins C. Perkins
University of Glasgow University of Glasgow
October 2, 2015 November 24, 2015
Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP
Reception Statistics and Other Feedback Reception Statistics and Other Feedback
draft-ietf-avtcore-rtp-multi-stream-optimisation-08 draft-ietf-avtcore-rtp-multi-stream-optimisation-09
Abstract Abstract
RTP allows multiple media streams to be sent in a single session, but RTP allows multiple media streams to be sent in a single session, but
requires each Synchronisation Source (SSRC) to send RTCP reception requires each Synchronisation Source (SSRC) to send RTCP reception
quality reports for every other SSRC visible in the session. This quality reports for every other SSRC visible in the session. This
causes the number of RTCP reception reports to grow with the number causes the number of RTCP reception reports to grow with the number
of SSRCs, rather than the number of endpoints. In many cases most of of SSRCs, rather than the number of endpoints. In many cases most of
these RTCP reception reports are unnecessary, since all SSRCs of an these RTCP reception reports are unnecessary, since all SSRCs of an
endpoint are co-located and see the same reception quality. This endpoint are co-located and see the same reception quality. This
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 April 4, 2016. This Internet-Draft will expire on May 27, 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 40 skipping to change at page 2, line 40
3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9 3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9
3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9
3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10
4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 11 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 11
4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 11
4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 12 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for
group communication, supporting multiparty multimedia sessions. A group communication, supporting multiparty multimedia sessions. A
single RTP session can support multiple participants sending at once, single RTP session can support multiple participants sending at once,
and can also support participants sending multiple simultaneous media and can also support participants sending multiple simultaneous media
streams. Examples of the latter might include a participant with streams. Examples of the latter might include a participant with
multiple cameras who chooses to send multiple views of a scene, or a multiple cameras who chooses to send multiple views of a scene, or a
skipping to change at page 4, line 40 skipping to change at page 4, line 40
the reception quality reports generated by the reporting source might the reception quality reports generated by the reporting source might
grow too large to fit into a single compound RTCP packet, forcing the grow too large to fit into a single compound RTCP packet, forcing the
reporting source to use a round-robin policy to determine what remote reporting source to use a round-robin policy to determine what remote
SSRCs it includes in each compound RTCP packet, and so reducing the SSRCs it includes in each compound RTCP packet, and so reducing the
frequency of reports on each SSRC. To avoid this, in sessions with frequency of reports on each SSRC. To avoid this, in sessions with
large numbers of remote SSRCs, an RTCP reporting group MAY use more large numbers of remote SSRCs, an RTCP reporting group MAY use more
than one reporting source. If several SSRCs are acting as reporting than one reporting source. If several SSRCs are acting as reporting
sources for an RTCP reporting group, then each reporting source MUST sources for an RTCP reporting group, then each reporting source MUST
have non-overlapping sets of remote SSRCs it reports on. have non-overlapping sets of remote SSRCs it reports on.
An endpoint SHOULD NOT create an RTCP reporting group that comprises An endpoint MUST NOT create an RTCP reporting group that comprises
only a single local SSRC (i.e., an RTCP reporting group where the only a single local SSRC (i.e., an RTCP reporting group where the
reporting source is the only member of the group), unless it is reporting source is the only member of the group), unless it is
anticipated that the group might have additional SSRCs added to it in anticipated that the group might have additional SSRCs added to it in
the future. the future.
If a reporting source leaves the RTP session (i.e., if it sends a If a reporting source leaves the RTP session (i.e., if it sends a
RTCP BYE packet, or leaves the session without sending BYE under the RTCP BYE packet, or leaves the session without sending BYE under the
rules of [RFC3550] section 6.3.7), the remaining members of the RTCP rules of [RFC3550] section 6.3.7), the remaining members of the RTCP
reporting group MUST either (a) have another reporting source, if reporting group MUST either (a) have another reporting source, if one
existing, report on the remote SSRCs the leaving SSRC reported on, exists, report on the remote SSRCs the leaving SSRC reported on, (b)
(b) choose a new reporting source, or (c) disband the RTCP reporting choose a new reporting source, or (c) disband the RTCP reporting
group and begin sending reception quality reports following [RFC3550] group and begin sending reception quality reports following [RFC3550]
and [I-D.ietf-avtcore-rtp-multi-stream]. and [I-D.ietf-avtcore-rtp-multi-stream].
The RTCP timing rules assign different bandwidth fractions to senders The RTCP timing rules assign different bandwidth fractions to senders
and receivers. This lets senders transmit RTCP reception quality and receivers. This lets senders transmit RTCP reception quality
reports more often than receivers. If a reporting source in an RTCP reports more often than receivers. If a reporting source in an RTCP
reporting group is a receiver, but one or more non-reporting SSRCs in reporting group is a receiver, but one or more non-reporting SSRCs in
the RTCP reporting group are senders, then the endpoint MAY treat the the RTCP reporting group are senders, then the endpoint MAY treat the
reporting source as a sender for the purpose of RTCP bandwidth reporting source as a sender for the purpose of RTCP bandwidth
allocation, increasing its RTCP bandwidth allocation, provided it allocation, increasing its RTCP bandwidth allocation, provided it
skipping to change at page 5, line 32 skipping to change at page 5, line 32
When RTCP Reporting Groups are in use, the other SSRCs in the RTP When RTCP Reporting Groups are in use, the other SSRCs in the RTP
session need to be able to identify which SSRCs are members of an session need to be able to identify which SSRCs are members of an
RTCP reporting group. Two RTCP extensions are defined to support RTCP reporting group. Two RTCP extensions are defined to support
this: the RTCP RGRP SDES item is used by the reporting source(s) to this: the RTCP RGRP SDES item is used by the reporting source(s) to
identify an RTCP reporting group, and the RTCP RGRS packet is used by identify an RTCP reporting group, and the RTCP RGRS packet is used by
other members of an RTCP reporting group to identify the reporting other members of an RTCP reporting group to identify the reporting
source(s). source(s).
3.2.1. Definition and Use of the RTCP RGRP SDES Item 3.2.1. Definition and Use of the RTCP RGRP SDES Item
A new RTCP SDES item is defined to identify an RTCP reporting group. This document defines a new RTCP SDES item to identify an RTCP
The motivation for giving a reporting group an identify is to ensure reporting group. The motivation for giving a reporting group an
that the RTCP reporting group and its member SSRCs can be correctly identify is to ensure that the RTCP reporting group and its member
associated when there are multiple reporting sources, and to ensure SSRCs can be correctly associated when there are multiple reporting
that a reporting SSRC can be associated with the correct reporting sources, and to ensure that a reporting SSRC can be associated with
group if an SSRC collision occurs. the correct reporting group if an SSRC collision occurs.
The RTCP Source Description (SDES) RGRP item is defined. The RTCP This document defines the RTCP Source Description (SDES) RGRP item.
SDES RGRP item MUST be sent by the reporting sources in a reporting The RTCP SDES RGRP item MUST be sent by the reporting sources in a
group, and MUST NOT be sent by other members of the reporting group reporting group, and MUST NOT be sent by other members of the
or by SSRCs that are not members of any RTCP reporting group. reporting group or by SSRCs that are not members of any RTCP
Specifically, every reporting source in an RTCP reporting group MUST reporting group. Specifically, every reporting source in an RTCP
include an RTCP SDES packet containing an RGRP item in every compound reporting group MUST include an RTCP SDES packet containing an RGRP
RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP item in every compound RTCP packet in which it sends an RR or SR
packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). packet (i.e., in every RTCP packet it sends, unless Reduced-Size RTCP
[RFC5506] is in use).
Syntactically, the format of the RTCP SDES RGRP item is identical to Syntactically, the format of the RTCP SDES RGRP item is identical to
that of the RTCP SDES CNAME item [RFC7022], except that the SDES item that of the RTCP SDES CNAME item [RFC7022], except that the SDES item
type field MUST have value RGRP=(TBA) instead of CNAME=1. The value type field MUST have value RGRP=(TBA) instead of CNAME=1. The value
of the RTCP SDES RGRP item MUST be chosen with the same concerns of the RTCP SDES RGRP item MUST be chosen with the same concerns
about global uniqueness and the same privacy considerations as the about global uniqueness and the same privacy considerations as the
RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable
throughout the lifetime of the reporting group, even if some or all throughout the lifetime of the reporting group, even if some or all
of the reporting sources change their SSRC due to collisions, or if of the reporting sources change their SSRC due to collisions, or if
the set of reporting sources changes. the set of reporting sources changes.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Value: Value:
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Example: Example:
a=rtcp-rgrp a=rtcp-rgrp
When doing SDP Offer/Answer [RFC3264] an offering client that wishes When doing SDP Offer/Answer [RFC3264] an offering client that wishes
to use RTCP Reporting Groups MUST include the attribute "a=rtcp-rgrp" to use RTCP Reporting Groups MUST include the attribute "a=rtcp-rgrp"
in the SDP offer. If "a=rtcp-rgrp" is present in the offer SDP, the in the SDP offer. If "a=rtcp-rgrp" is present in the offer SDP, the
answerer that supports RTCP Reporting Groups and wishes to use it answerer that supports RTCP Reporting Groups and wishes to use it
SHALL include the "a=rtcp-rgrp" attribute in the answer. In cases SHALL include the "a=rtcp-rgrp" attribute in the answer. If the
the answer has been excluded, neither agents SHALL use the RTCP answerer does not wish to use RTCP Reporting Groups, it MUST NOT
Reporting Groups. include the "a=rtcp-rgrp" attribute in the answer.
In declarative usage of SDP, such as the Real Time Streaming Protocol In declarative usage of SDP, such as the Real Time Streaming Protocol
(RTSP) [RFC2326] and the Session Announcement Protocol (SAP) (RTSP) [RFC2326] and the Session Announcement Protocol (SAP)
[RFC2974], the presence of the attribute indicates that the session [RFC2974], the presence of the attribute indicates that the session
participant MAY use RTCP Reporting Groups in its RTCP transmissions. participant MAY use RTCP Reporting Groups in its RTCP transmissions.
An implementation that doesn't explicitly support RTCP Reporting An implementation that doesn't explicitly support RTCP Reporting
Groups MAY join a RTP session as long as it has been verified that Groups MAY join a RTP session as long as it has been verified that
the implementation doesn't suffer from the problems discussed in the implementation doesn't suffer from the problems discussed in
Section 4.2. Section 4.2.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
feedback rules, each of the 184 receivers will send 16 report blocks, feedback rules, each of the 184 receivers will send 16 report blocks,
and each of the 16 senders will send 15. This amounts to and each of the 16 senders will send 15. This amounts to
approximately 76 kB of report block traffic per interval; 92% of RTCP approximately 76 kB of report block traffic per interval; 92% of RTCP
traffic consists of report blocks. traffic consists of report blocks.
If reporting groups are used, however, there is only 0.4 kB of If reporting groups are used, however, there is only 0.4 kB of
reports per interval, with no loss of useful information. reports per interval, with no loss of useful information.
Additionally, there will be (assuming 16-byte RGRPs, and a single Additionally, there will be (assuming 16-byte RGRPs, and a single
reporting source per reporting group) an additional 2.4 kB per cycle reporting source per reporting group) an additional 2.4 kB per cycle
of RGRP SDES items and RGRS packets. Put another way, the unmodified of RGRP SDES items and RGRS packets. Put another way, the unmodified
[RFC3550] reporting interval is approximately 8.9 times longer than [RFC3550] reporting interval is approximately 9 times longer than if
if reporting groups are in use. reporting groups are in use.
4.2. Compatibility of RTCP Reporting Groups 4.2. Compatibility of RTCP Reporting Groups
The RTCP traffic generated by receivers using RTCP Reporting Groups The RTCP traffic generated by receivers using RTCP Reporting Groups
might appear, to observers unaware of these semantics, to be might appear, to observers unaware of these semantics, to be
generated by receivers who are experiencing a network disconnection, generated by receivers who are experiencing a network disconnection,
as the non-reporting sources appear not to be receiving a given as the non-reporting sources appear not to be receiving a given
sender at all. sender at all.
This could be a potentially critical problem for such a sender using This could be a potentially critical problem for such a sender using
skipping to change at page 15, line 34 skipping to change at page 15, line 34
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-09 (work in progress), draft-ietf-avtcore-rtp-multi-stream-09 (work in progress),
September 2015. September 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
skipping to change at page 16, line 14 skipping to change at page 16, line 16
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, Streaming Protocol (RTSP)", RFC 2326,
DOI 10.17487/RFC2326, April 1998, DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>. <http://www.rfc-editor.org/info/rfc2326>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>. October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <http://www.rfc-editor.org/info/rfc3711>.
 End of changes. 13 change blocks. 
33 lines changed or deleted 34 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/