draft-ietf-avtcore-feedback-supression-rtp-02.txt   draft-ietf-avtcore-feedback-supression-rtp-03.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 7, 2011 Huawei Expires: November 13, 2011 Huawei
May 6, 2011 May 12, 2011
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-02 draft-ietf-avtcore-feedback-supression-rtp-03
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 media source or middlebox may experience transient RFC 4585, a feedback target may experience transient overload if some
overload if some event causes a large number of receivers to send event causes a large number of receivers to send feedback at once.
feedback at once. This feedback implosion can be mitigated if the This overload is usually avoided by ensuring that feedback reports
device suffering from overload can send a third party loss report are forwarded to all receivers, allowing them to avoid sending
message to the receivers to inhibit further feedback. This memo duplicate feedback reports. However, there are certain cases where
defines RTCP Extension for third party loss report, to suppress NACK it is not possible to forward feedback reports, and this may allow
and FIR feedback requests. It also defines associated SDP signaling. feedback implosion. This memo defines a new RTCP third-party loss
report that can be used to inform receivers that a feedback target is
aware of some loss event, allowing them to suppress feedback.
Associated SDP signalling is also defined.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 7, 2011. This Internet-Draft will expire on November 13, 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 13 skipping to change at page 3, line 13
than English. than English.
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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 9
6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 10 6.1.1. Distribution Source Feedback Summary Model . . . . . . 11
6.1.2. 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 . . . . . . . . . . . . 13 6.3. RTP transport translator use case . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 13
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. Appendix A. Change Log . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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
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. These intermediate nodes need to take into account receivers do. Upon observing (or suspecting) an upstream loss, the
such factors as the tolerable application delay, packet loss recovery intermediary Should send NACK both downstream towards the receivers
techniques, the network dynamics, and the media type. Loss-repair and upstream towards the media source, to indicate that it has
methods such as retransmission and Forward Error Correction may be noticed the loss, and to suppress feedback from other downstream
used to recover the missing packet. Upon observing (or suspecting) receivers. However, in some cases where packet loss occurs in the
an upstream loss, the intermediary Should send NACK both downstream downstream of these intermediates, it is not possible for them to
towards the receivers and upstream towards the media source, to distribute the NACKs to all receivers since they are unable to
indicate that it has noticed the loss, and to suppress feedback from observe downstream loss. In such cases, downstream loss needs to be
other downstream receivers. Upon downstream loss is reported to the firstly reported to the intermediary. When downstream loss is
intermediary, the intermediary SHOULD send the Third Party Loss reported to the intermediary, the intermediary SHOULD create and send
report to the other downstream receivers which are not aware of the the Third Party Loss report to the other downstream receivers which
loss reports, to inform those receivers of the loss and suppress are not aware of the loss reports, to inform those receivers of the
their feedback. Therefore the intermediate node can be reasonably loss and suppress their feedback. Therefore the intermediate node
certain that it will help the situation by sending a Third Party Loss can be reasonably certain that it will help the situation by sending
Report message and NACK 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. feedback messages for a period of time. The intermediate node needs
to take into account such factors as the tolerable application delay,
packet loss recovery techniques, the network dynamics, and the media
type. Loss-repair methods such as retransmission and Forward Error
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 requests it receives from downstream, and send the Third feedback reports it receives from downstream. Upon receiving
Party Loss Report messages to the downstream receivers. downstream loss report in the form of such feedback report which is
only destined for media source, the media source SHOULD create and
send the Third Party Loss Report messages to the other downstream
receivers which are not aware of the loss reports, to inform those
receivers of the loss and suppress their feedback.
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 9, line 45 skipping to change at page 10, line 6
using Third Party Loss Report for feedback suppression and give an using Third Party Loss Report for feedback suppression and give an
overview of the particular mechanisms. overview of the particular mechanisms.
6.1. Source Specific Multicast (SSM) use case 6.1. Source Specific Multicast (SSM) use case
In SSM RTP sessions as described in [RFC5760], one or more Media In SSM RTP sessions as described in [RFC5760], one or more Media
Sources send RTP packets to a Distribution Source. The Distribution Sources send RTP packets to a Distribution Source. The Distribution
Source relays the RTP packets to the receivers using a source- Source relays the RTP packets to the receivers using a source-
specific multicast group. specific multicast group.
As outlined in the [RFC5760], there are two Unicast Feedback models
that may be used for reporting, - the Simple Feedback model and the
Distribution Source Feedback Summary Model. In the simple Feedback
Model, NACKs are reflected by the distribution source to the other
receivers, and there's no need for distribution source to create the
third-party loss report. The third-party loss report is only
generated at the distribution source when downstream loss report is
received in Distribution Source Feedback Summary model. Therefore
the RTCP extension for Third Party Loss Report specified in the
Section 4 of this document only works in Distribution Source Feedback
models. Details of operation are specified in Section 6.1.1.
In order to avoid the forms of Feedback implosion described in In order to avoid the forms of Feedback implosion described in
section 1,the distribution source should be told that the indicated section 1,the distribution source should be told that the indicated
packets were lost. How the distribution source know the indicated packets were lost. When one downstream receiver reports loss, the
packets were lost is beyond of scope of this document. When one distribution source creates a Third Party Loss Report and sent it to
downstream receiver reports loss, the distribution source creates a all the other RTP receivers which are not aware of feedback report,
Third Party Loss Report and sent it to all the RTP receivers, over over the multicast channel. Another possibility is when there may be
the multicast channel. Another possibility is when there may be
multiple distribution sources placed between the media source and the multiple distribution sources placed between the media source and the
receivers, each distribution source may send its own Third Party Loss receivers, each distribution source may send its own Third Party Loss
report to downstream receivers respectively when downstream loss is report to downstream receivers respectively when downstream loss is
reported to each distribution source. And also the upstream reported to each distribution source. And also the upstream
distribution source may inform downstream distribution sources in the distribution source may inform downstream distribution sources in the
path of the detected packet loss using the Third Party Loss Report path of the detected packet loss using the Third Party Loss Report
messages. In response, if the upstream Third Party Loss Report messages. In response, if the upstream Third Party Loss Report
reports the different event, the downstream distribution sources reports the different event, the downstream distribution sources
forward Third Party Loss Report received from upstream to all the RTP forward Third Party Loss Report received from upstream to all the RTP
receivers, over the multicast channel. If the same event is reported receivers, over the multicast channel. If the same event is reported
both from upstream distribution source and from downstream receiver, both from upstream distribution source and from the downstream
the downstream distribution source may suppress creating and sending receiver, the downstream distribution source may suppress creating
its own report to the relevant RTP receivers. This Third Party Loss and sending its own report to the relevant RTP receivers. This Third
Report message tells the receivers that the sender of the third party Party Loss Report message tells the receivers that the sender of the
loss report has received reports that the indicated packets were third party loss report has received reports that the indicated
lost. The distribution source then can (optionally) ask for the lost packets were lost. The distribution source then can (optionally) ask
packets from the media source or itself on behalf of all the RTP for the lost packets from the media source or itself on behalf of all
receivers. The lost packets will either be forthcoming from the RTP receivers. The lost packets will either be forthcoming from
distribution source, or it irretrievably lost such that there is distribution source, or it irretrievably lost such that there is
nothing to be gained by the receiver sending a NACK to the media nothing to be gained by the receiver sending a NACK to the media
source. source.
The distribution source must be able to communicate with all group The distribution source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing members in order for either mechanism to be effective at suppressing
feedback. feedback. If the media source(s) are part of the SSM group for RTCP
packet, the Distribution Source must filter this packet out. If the
As outlined in the [RFC5760], there are two Unicast Feedback models media source(s) are not part of the SSM group for RTCP packets, the
that may be used for reporting, - the Simple Feedback model and the Distribution Source must not forward this RTCP Third Party Loss
Distribution Source Feedback Summary Model. The RTCP Feedback
extension for Third Party Loss Report specified in the Section 4 of
this document will work in both Feedback models. Details of
operation in each are specified below.
6.1.1. Simple Feedback Model
In the simple Feedback Model, NACKs from the receiver observing the
loss will be reflected to the other receivers, and there's no need
for distribution source to create the third-party loss report. The
distribution source that has not seen the actual packet loss should
pass through any Third Party Loss Report message it receives from the
upstream direction.
This RTCP Third Party Loss Report message lets the receivers know
that the sender of the Third party Loss Report has received reports
that the indicated packets were lost and feedback for this packet
loss is not needed and should not be sent to the media source(s). If
the media source(s) are part of the SSM group for RTCP packet
reflection, the Distribution Source must filter this packet out. If
the media source(s) are not part of the SSM group for RTCP packets,
the Distribution Source must not forward this RTCP Third Party Loss
Report message to the media source(s). Report message to the media source(s).
6.1.2. Distribution Source Feedback Summary Model 6.1.1. Distribution Source Feedback Summary Model
In the distribution source feedback summary model, there may be In the distribution source feedback summary model, we assume there
multiple distribution sources who see the actual packet loss In this are two distribution sources between media source and receivers:
section, we focus on this generic case to discuss the distribution distribution source A and distribution source B. The distribution
Source Feedback Summary Model. 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.
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 from the
skipping to change at page 16, line 40 skipping to change at page 16, line 36
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.hunt-avt-monarch-01]
Hunt, G. and P. Arden, "Monitoring Architectures for RTP", Hunt, G. and P. Arden, "Monitoring Architectures for RTP",
August 2008. August 2008.
[I-D.ietf-pmol-metrics-framework-02] [I-D.ietf-pmol-metrics-framework-02]
Clark, A., "Framework for Performance Metric Development". Clark, A., "Framework for Performance Metric Development".
Appendix A. 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:
o Remove the merge report from SSM use case and addional text to o Remove the merge report from SSM use case and addional text to
address report merging issue. address report merging issue.
o Revise section 3 and section 6 to address FEC packet dealing issue o Revise section 3 and section 6 to address FEC packet dealing issue
and Leave how to repair packet loss beyond the scope. and Leave how to repair packet loss beyond the scope.
o Modify the SSM use case and RAMS use case to focus on uses. o Modify the SSM use case and RAMS use case to focus on uses.
o Other Editorial changes. o Other Editorial changes.
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o In Appendix A, fix typo: Appendix A. Appendix A. -> Appdendix A.
o In Section 4.1, fix typo: Section 4.3.1.1 of section [RFC5104]-> o In Section 4.1, fix typo: Section 4.3.1.1 of section [RFC5104]->
section 6.2.1 of [RFC4585]. section 6.2.1 of [RFC4585].
o In Section 3: Clarify how to deal with downstream loss using Third o In Section 3: Clarify how to deal with downstream loss using Third
party loss report and upstream loss using NACK. party loss report and upstream loss using NACK.
o Update title and abstract to focus on third party loss report. o Update title and abstract to focus on third party loss report.
o In Section 6.1: Update this section to explain how third party o In Section 6.1: Update this section to explain how third party
loss report is used to deal with downstream loss. loss report is used to deal with downstream loss.
o In section 6.1.2: Update this section to explain how third party o In section 6.1.2: Update this section to explain how third party
loss report is used to deal with downstream loss. loss report is used to deal with downstream loss.
o In section 6.2: Rephrase the text to discuss how BRS deal with the o In section 6.2: Rephrase the text to discuss how BRS deal with the
third party loss report. third party loss report.
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03
The following are the major changes compared to previous version:
o In Appendix A, fix typo: Appendix A. Appendix A. -> Appdendix A.
o Update abstract to clarify when third-party loss reports should be
sent instead of NACKs.
o Update section 3 Paragraph 2 to differentiate when a third-party
loss report should be used compared to a NACK.
o Update section 3 Paragraph 3 to explain when media source to send
a third-party loss.
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.
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
 End of changes. 29 change blocks. 
80 lines changed or deleted 106 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/