draft-ietf-avtcore-feedback-supression-rtp-03.txt   draft-ietf-avtcore-feedback-supression-rtp-04.txt 
Network Working Group Q. Wu Network Working Group Q. Wu
Internet-Draft F. Xia Internet-Draft F. Xia
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: November 13, 2011 Huawei Expires: November 28, 2011 Huawei
May 12, 2011 May 27, 2011
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-03 draft-ietf-avtcore-feedback-supression-rtp-04
Abstract Abstract
In a large RTP session using the RTCP feedback mechanism defined in In a large RTP session using the RTCP feedback mechanism defined in
RFC 4585, a feedback target may experience transient overload if some RFC 4585, a feedback target may experience transient overload if some
event causes a large number of receivers to send feedback at once. event causes a large number of receivers to send feedback at once.
This overload is usually avoided by ensuring that feedback reports This overload is usually avoided by ensuring that feedback reports
are forwarded to all receivers, allowing them to avoid sending are forwarded to all receivers, allowing them to avoid sending
duplicate feedback reports. However, there are certain cases where duplicate feedback reports. However, there are certain cases where
it is not possible to forward feedback reports, and this may allow it is not possible to forward feedback reports, and this may allow
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 13, 2011. This Internet-Draft will expire on November 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 7 4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 7
4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7
4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 10
6.1.1. Distribution Source Feedback Summary Model . . . . . . 11 6.1.1. Distribution Source Feedback Summary Model . . . . . . 11
6.2. Unicast based Rapid Acquisition of Multicast Stream 6.2. Unicast based Rapid Acquisition of Multicast Stream
(RAMS) use case . . . . . . . . . . . . . . . . . . . . . 11 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 11
6.3. RTP transport translator use case . . . . . . . . . . . . 12 6.3. RTP transport translator use case . . . . . . . . . . . . 13
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 17
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 17 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 17
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 17 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
RTCP feedback messages [RFC4585] allow the receivers in an RTP RTCP feedback messages [RFC4585] allow the receivers in an RTP
session to report events and ask for action from the media source (or session to report events and ask for action from the media source (or
a delegated feedback target defined in SSM [RFC5760]). There are a delegated feedback target defined in SSM [RFC5760]). There are
cases where multiple receivers may initiate the same, or an cases where multiple receivers may initiate the same, or an
equivalent message towards the same media source. When the receiver equivalent message towards the same media source. When the receiver
count is large, this behavior may cause transient overload of the count is large, this behavior may cause transient overload of the
media source, the network or both. This is known as a "feedback media source, the network or both. This is known as a "feedback
skipping to change at page 5, line 29 skipping to change at page 5, line 29
for particular packets (indicated by their RTP sequence numbers) for particular packets (indicated by their RTP sequence numbers)
independent of whether the receiver detected the packet loss or independent of whether the receiver detected the packet loss or
detected a need for a decoder refresh point. detected a need for a decoder refresh point.
In order to observe packet loss before the receivers perceive it, one In order to observe packet loss before the receivers perceive it, one
or more intermediate nodes may be placed between the media source and or more intermediate nodes may be placed between the media source and
the receivers. These intermediates are variously referred to as the receivers. These intermediates are variously referred to as
Distribution servers, MCUs, RTP translator, or RTP mixers, depending Distribution servers, MCUs, RTP translator, or RTP mixers, depending
on the precise use case. These intermediaries monitor for packet on the precise use case. These intermediaries monitor for packet
loss upstream of themselves by checking RTP sequence numbers, just as loss upstream of themselves by checking RTP sequence numbers, just as
receivers do. Upon observing (or suspecting) an upstream loss, the receivers do. If an intermediary notices the loss itself, then it
intermediary Should send NACK both downstream towards the receivers may send a NACK both downstream towards the receivers and upstream
and upstream towards the media source, to indicate that it has towards the media source, to indicate that it has noticed the loss,
noticed the loss, and to suppress feedback from other downstream and to suppress feedback from other downstream receivers. If an
receivers. However, in some cases where packet loss occurs in the intermediary receives a NACK from another system, it should
downstream of these intermediates, it is not possible for them to redistribute that NACK to all other systems that would not otherwise
distribute the NACKs to all receivers since they are unable to receive it. An example of this is RTCP-SSM in simple feedback model
observe downstream loss. In such cases, downstream loss needs to be [RFC5760], where the distribution source reflects NACKs to other
firstly reported to the intermediary. When downstream loss is systems. If an intermediary receives a NACK from another system,
reported to the intermediary, the intermediary SHOULD create and send but, for some reason, cannot redistribute that NACK, then it may send
the Third Party Loss report to the other downstream receivers which a third-party loss report to the systems that were unable to receive
are not aware of the loss reports, to inform those receivers of the the NACK, and won't receive the NACK via other means. An example
loss and suppress their feedback. Therefore the intermediate node would be a distribution source using RTCP-SSM in Distribution Source
Feedback Summary model [RFC5760]. Therefore the intermediate node
can be reasonably certain that it will help the situation by sending can be reasonably certain that it will help the situation by sending
a Third Party Loss Report message to all the relevant receivers, a Third Party Loss Report message to all the relevant receivers,
thereby indicating to the receivers that they should not transmit thereby indicating to the receivers that they should not transmit
feedback messages for a period of time. The intermediate node needs feedback messages for a period of time. The intermediate node needs
to take into account such factors as the tolerable application delay, to take into account such factors as the tolerable application delay,
packet loss recovery techniques, the network dynamics, and the media packet loss recovery techniques, the network dynamics, and the media
type. Loss-repair methods such as retransmission and Forward Error type. Loss-repair methods such as retransmission and Forward Error
Correction may be used to recover the missing packet. Correction may be used to recover the missing packet.
Alternatively, the media source may directly monitor the amount of Alternatively, the media source may directly monitor the amount of
feedback reports it receives from downstream. Upon receiving feedback reports it receives from downstream. If the media source
downstream loss report in the form of such feedback report which is receives a NACK from another system, it should redistribute that NACK
only destined for media source, the media source SHOULD create and to all other systems that would not otherwise receive it. An example
send the Third Party Loss Report messages to the other downstream of this is RTCP-SSM in simple feedback model [RFC5760], where the
receivers which are not aware of the loss reports, to inform those distribution source reflects NACKs to other systems. If an
receivers of the loss and suppress their feedback. intermediary receives a NACK from another system, but, for some
reason, cannot redistribute that NACK, then it may send a third-party
loss report to the systems that were unable to receive the NACK, and
won't receive the NACK via other means. An example would be a
distribution source using RTCP-SSM in Distribution Source Feedback
Summary model [RFC5760].
When a receiver gets such a Third Party Loss Report message, it When a receiver gets such a Third Party Loss Report message, it
should refrain from sending a feedback request (e.g., NACK or FIR) should refrain from sending a feedback request (e.g., NACK or FIR)
for the missing packets reported in the message for a period of time. for the missing packets reported in the message for a period of time.
A receiver may still have sent a Feedback message according to the A receiver may still have sent a Feedback message according to the
AVPF scheduling algorithm of [RFC4585]before receiving a Third Party AVPF scheduling algorithm of [RFC4585]before receiving a Third Party
Loss Report message, but further feedback messages for those sequence Loss Report message, but further feedback messages for those sequence
numbers will be suppressed by this technique for a period of time. numbers will be suppressed by this technique for a period of time.
Nodes that do not understand the Third Party Loss Report message will Nodes that do not understand the Third Party Loss Report message will
ignore it, and might therefore still send feedback according to the ignore it, and might therefore still send feedback according to the
skipping to change at page 11, line 18 skipping to change at page 11, line 25
In the distribution source feedback summary model, we assume there In the distribution source feedback summary model, we assume there
are two distribution sources between media source and receivers: are two distribution sources between media source and receivers:
distribution source A and distribution source B. The distribution distribution source A and distribution source B. The distribution
source A is at the upstream of distribution source B. source A is at the upstream of distribution source B.
The distribution source A must listen on the RTP channel for data. The distribution source A must listen on the RTP channel for data.
When the distribution source A observes RTP packets from a media When the distribution source A observes RTP packets from a media
source are not consecutive by checking the sequence number of source are not consecutive by checking the sequence number of
packets, the distribution source A generates the NACK message, and packets, the distribution source A generates the NACK message, and
then send it to receivers in the downstream path via the multicast then send it to receivers in the downstream path via the multicast
channel. channel. Also the distribution source A may create a Third Party
Loss Report and send it to all the other RTP receivers which are not
aware of feedback report, over the multicast channel when downstream
loss is reported to distribution source A.
The Distribution Source B must also listen for RTCP data sent to the The Distribution Source B must also listen for RTCP data sent to the
RTCP port. Upon receiving the RTCP Third Party Loss Report from the RTCP port. Upon receiving the RTCP Third Party Loss Report or NACK
Distribution Source A, the Distribution Source B needs to check message from the Distribution Source A, the Distribution Source B
whether it sees the same event reported both from upstream needs to check whether it sees the same event reported both from
distribution source A and downstream receiver. If the upstream Third upstream distribution source A and downstream receiver. If the
Party Loss Report reports the different event, the distribution upstream Third Party Loss Report reports the different event, the
source B passes through any Third Party Loss Report message it distribution source B passes through any Third Party Loss Report
receives from the upstream direction. If the same event is reported message it receives from the upstream direction. If the same event
from both distribution source A and downstream receiver of is reported from both distribution source A and downstream receiver
distribution source B, the distribution source B may suppress of distribution source B, the distribution source B may suppress
creating and sending its own report with the same event to the creating and sending its own report with the same event to the
downstream RTP receiver. downstream RTP receiver.
Also the Distribution Source B may create and send its own Third Also the Distribution Source B may create and send its own Third
Party Loss Report described in the Section 4 to the group over the Party Loss Report described in the Section 4 to the group over the
multicast RTCP channel in response to NACKs received from downstream. multicast RTCP channel in response to NACKs received from downstream.
if downstream loss is reported using NACK to the distribution source if downstream loss is reported using NACK to the distribution source
B. B.
6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use
skipping to change at page 16, line 29 skipping to change at page 17, line 11
[DVB-IPTV] [DVB-IPTV]
ETSI Standard, "Digital Video Broadcasting(DVB); Transport ETSI Standard, "Digital Video Broadcasting(DVB); Transport
of MPEG-2 TS Based DVB Services over IP Based Networks", of MPEG-2 TS Based DVB Services over IP Based Networks",
ETSI TS 102 034, V1.4.1 , August 2009. ETSI TS 102 034, V1.4.1 , August 2009.
[I-D.ietf-avt-rapid-acquisition-for-rtp] [I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
November 2010. November 2010.
[I-D.hunt-avt-monarch-01] [I-D.ietf-avtcore-monarch-01]
Hunt, G. and P. Arden, "Monitoring Architectures for RTP", Wu, Q., "Monitoring Architectures for RTP", May 2011.
August 2008.
[I-D.ietf-pmol-metrics-framework-02] [I-D.ietf-pmol-metrics-framework-08]
Clark, A., "Framework for Performance Metric Development". Clark, A. and B. Claise, "Framework for Performance Metric
Development", January 2011.
Appendix A. Change Log Appendix A. Change Log
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
skipping to change at page 18, line 5 skipping to change at page 18, line 32
o Update section 3 Paragraph 2 to differentiate when a third-party o Update section 3 Paragraph 2 to differentiate when a third-party
loss report should be used compared to a NACK. loss report should be used compared to a NACK.
o Update section 3 Paragraph 3 to explain when media source to send o Update section 3 Paragraph 3 to explain when media source to send
a third-party loss. a third-party loss.
o Move specific rules for section 6.1.1 and section 6.1.2 to section o Move specific rules for section 6.1.1 and section 6.1.2 to section
6.1 as generic rules and delete section 6.1.1. 6.1 as generic rules and delete section 6.1.1.
A.4. draft-ietf-avtcore-feedback-suppression-rtp-04
The following are the major changes compared to previous version:
o Reference Update.
o Clarify the use of the third party loss report in section 3 and
section 6.1.1.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
Frank Xia Frank Xia
Huawei Huawei
1700 Alma Dr. Suite 500 1700 Alma Dr. Suite 500
Plano, TX 75075 Plano, TX 75075
USA USA
Phone: +1 972-509-5599 Phone: +1 972-509-5599
Email: xiayangsong@huawei.com Email: xiayangsong@huawei.com
Roni Even Roni Even
 End of changes. 16 change blocks. 
46 lines changed or deleted 62 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/