draft-ietf-avtcore-feedback-supression-rtp-04.txt   draft-ietf-avtcore-feedback-supression-rtp-05.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 28, 2011 Huawei Expires: January 12, 2012 Huawei
May 27, 2011 July 11, 2011
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-04 draft-ietf-avtcore-feedback-supression-rtp-05
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 cases where it is not
it is not possible to forward feedback reports, and this may allow recommended to forward feedback reports, and this may allow feedback
feedback implosion. This memo defines a new RTCP third-party loss implosion. This memo discusses these cases and defines a new RTCP
report that can be used to inform receivers that a feedback target is third-party loss report that can be used to inform receivers that a
aware of some loss event, allowing them to suppress feedback. feedback target is aware of some loss event, allowing them to
Associated SDP signalling is also defined. 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 28, 2011. This Internet-Draft will expire on January 12, 2012.
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 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
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 . . . . . . . . . . . . . . . 6
4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 6
4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 7
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 10 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . 10
6.3. RTP transport translator use case . . . . . . . . . . . . 13 6.3. RTP transport translator use case . . . . . . . . . . . . 11
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 17 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 15
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 17 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 15
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 18 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 16
A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 18 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 16
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 when using unicast RTCP feedback with SSM
cases where multiple receivers may initiate the same, or an [RFC5760]). There are cases where multiple receivers may initiate
equivalent message towards the same media source. When the receiver the same, or an equivalent message towards the same media source.
count is large, this behavior may cause transient overload of the When the receiver count is large, this behavior may cause transient
media source, the network or both. This is known as a "feedback overload of the media source, the network or both. This is known as
storm" or a "NACK storm". One common cause of such a feedback storm a "feedback storm" or a "NACK storm". One common cause of such a
is receivers utilizing RTP retransmission [RFC4588] as a packet loss feedback storm is receivers utilizing RTP retransmission [RFC4588] as
recovery technique based, sending feedback using RTCP NACK messages a packet loss recovery technique based, sending feedback using RTCP
[RFC4585] without proper dithering of the retransmission requests. NACK messages [RFC4585] without proper dithering of the
retransmission requests.
Another use case involves video Fast Update requests. A storm of Another use case involves video Fast Update requests. A storm of
these feedback messages can occur in conversational multimedia these feedback messages can occur in conversational multimedia
scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario,
packet loss may happen on an upstream link of an intermediate network packet loss may happen on an upstream link of an intermediate network
element such as a Multipoint Control Unit(MCU). Poorly designed element such as a Multipoint Control Unit(MCU). Poorly designed
receivers that blindly issue fast update requests (i.e., Full Intra receivers that blindly issue fast update requests (i.e., Full Intra
Request (FIR) described in [RFC5104]), can cause an implosion of FIR Request (FIR) described in [RFC5104]), can cause an implosion of FIR
requests from receivers to the same media source. requests from receivers to the same media source.
RTCP feedback storms may cause short term overload, and in extreme RTCP feedback storms may cause short term overload, and in extreme
cases to pose a possible risk of increasing network congestion on the cases to pose a possible risk of increasing network congestion on the
control channel (e.g. RTCP feedback), the data channel, or both. It control channel (e.g. RTCP feedback), the data channel, or both. It
is therefore desirable to provide a way of suppressing unneeded is therefore desirable to provide a way of suppressing unneeded
feedback. feedback.
One approach to this, suggested in [DVB-IPTV], involves sending a One approach to this, suggested in [DVB-IPTV], involves sending a
NACK message to the other clients (or receiver) in the same group as NACK message to the other clients (or receiver) in the same group as
the sender of NACK. However sending multicast NACK to the group can the sender of NACK. However NACK is defined as a receiver report
not prevent large amount of unicast NACK addressed to the same media sent from a receiver observing a packet loss, therefore it only
source or middlebox, for example when the NACK is used as a inform others that sender of NACK detected loss while the case the
retransmission request [RFC4588]. Also NACK is defined as a receiver sender of the feedback has received reports that the indicated
report sent from a receiver observing a packet loss, therefore it
only inform others that sender of NACK detected loss while the case
the sender of the feedback has received reports that the indicated
packets were lost is not covered. This document specifies a new packets were lost is not covered. This document specifies a new
message for this function. It further is more precise in the third-party loss report for this function. It further is more
intended uses and less likely to be confusing to receivers. It tells precise in the intended uses and less likely to be confusing to
receivers explicitly that feedback for a particular packet or frame receivers. It tells receivers explicitly that feedback for a
loss is not needed for a period of time and can provide an early particular packet or frame loss is not needed for a period of time
indication before the receiver reacts to the loss and invokes its and can provide an early indication before the receiver reacts to the
packet loss repair machinery. loss and invokes its packet loss repair machinery. Section 6
provides some examples of when to send the third party loss report
message.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Protocol Overview 3. Protocol Overview
This document extends the RTCP feedback messages defined in the This document extends the RTCP feedback messages defined in the
Audio-Visual Profile with Feedback (AVPF) and define the Third Party Audio-Visual Profile with feedback (RTP/AVPF) [RFC4585] defining a
Loss Report message. The Third Party Loss Report message informs the Third Party Loss Report message. The Third Party Loss Report message
receiver in the downstream path of the middlebox that the sender of can be used by the media source or intermediaries to inform the
the Third Party Loss Report has received reports that the indicated receiver that the sender of the Third Party Loss Report has received
packets were lost and asks a receiver to not send feedback messages reports that the indicated packets were lost, and asks the receiver
for particular packets (indicated by their RTP sequence numbers) not to send feedback to it regarding these packets.
independent of whether the receiver detected the packet loss or
detected a need for a decoder refresh point.
In order to observe packet loss before the receivers perceive it, one
or more intermediate nodes may be placed between the media source and
the receivers. These intermediates are variously referred to as
Distribution servers, MCUs, RTP translator, or RTP mixers, depending
on the precise use case. These intermediaries monitor for packet
loss upstream of themselves by checking RTP sequence numbers, just as
receivers do. If an intermediary notices the loss itself, then it
may send a NACK both downstream towards the receivers and upstream
towards the media source, to indicate that it has noticed the loss,
and to suppress feedback from other downstream receivers. If an
intermediary receives a NACK from another system, it should
redistribute that NACK to all other systems that would not otherwise
receive it. An example of this is RTCP-SSM in simple feedback model
[RFC5760], where the distribution source reflects NACKs to other
systems. If an 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]. Therefore the intermediate node
can be reasonably certain that it will help the situation by sending
a Third Party Loss Report message to all the relevant receivers,
thereby indicating to the receivers that they should not transmit
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
feedback reports it receives from downstream. If the media source
receives a NACK from another system, it should redistribute that NACK
to all other systems that would not otherwise receive it. An example
of this is RTCP-SSM in simple feedback model [RFC5760], where the
distribution source reflects NACKs to other systems. If an
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 a Third Party Loss Report message, it should
should refrain from sending a feedback request (e.g., NACK or FIR) refrain from sending a feedback request (e.g., NACK or FIR) for the
for the missing packets reported in the message for a period of time. missing packets reported in the message for a period of time. A
A receiver may still have sent a Feedback message according to the receiver may still have sent a Feedback message according to the RTP/
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
AVPF scheduling algorithm of [RFC4585]. The media source or AVPF scheduling algorithm of [RFC4585]. The media source or
intermediate nodes cannot assume that the use of a Third Party Loss intermediate nodes cannot assume that the use of a Third Party Loss
Report message actually reduces the amount of feedback it receives. Report message actually reduces the amount of feedback it receives.
RTCP Third Party Loss Report follows the similar format of message RTCP Third Party Loss Report follows the similar format of message
type as RTCP NACK. But unlike RTCP NACK, the third party loss report type as RTCP NACK. However, the third party loss report is defined
is defined as an indication that the sender of the feedback has as an indication that the sender of the feedback has received reports
received reports that the indicated packets were lost and conveys the that the indicated packets were lost, while NACK [RFC4585] just
packet receipt/loss events at the sequence number level from the indicates that the sender of the NACK observed that these packets
middlebox to the receivers in the downstream path of middlebox while were lost. The Third Party Loss Report message is generated by a
NACK [RFC4585] just indicates that the sender of the NACK observed system that has not seen the actual packet loss. Systems that
that these packets were lost. The Third Party Loss Report message is receive a third party loss report SHOULD NOT initiate their own
generated by RTP middlebox that has not seen the actual packet loss additional Third Party Loss Report messages for the same packet
and sent to the corresponding receivers. Intermediaries downstream sequence numbers. They may either simply forward the Third Party
of an intermediary receiving the upstream report obviously SHOULD NOT Loss Report message, or they may generate their own Third Party Loss
initiate their own additional Third Party Loss Report messages for Report that reports a superset of the loss reported in the Third
the same packet sequence numbers. They may either simply forward the Party Loss report they received. The Third Party Loss Report does
Third Party Loss Report message received from upstream, or send its not have the retransmission request [RFC4588] semantics.
own Third Party Loss Report message that reflects the loss they have
been told. The Third Party Loss Report does not have the
retransmission request [RFC4588] semantics.
Since Third Party Loss Report interacts strongly with repair timing, Since Third Party Loss Report interacts strongly with repair timing,
it has to work together with feedback to not adversely impact the it has to work together with feedback to not adversely impact the
repair of lost source packets. One example is the middle box gets repair of lost source packets. One example is the middle box gets
the retransmitted packet by sending a NACK upstream and sent it the retransmitted packet by sending a NACK upstream and sent it
downstream. This retransmitted packet was lost on the downstream downstream. This retransmitted packet was lost on the downstream
link. In order to deal with this, the downstream receiver can start link. In order to deal with this, the downstream receiver can start
a timeout in which it expected to get a retransmission packet. When a timeout in which it expected to get a retransmission packet. When
this timeout expires and there is no retransmitted packet or a new this timeout expires and there is no retransmitted packet or a new
third party loss report message, it can take its normal behavior as third party loss report message, it can take its normal behavior as
if there is no current retransmission suppression. In some cases if there is no current retransmission suppression. In this case when
where the loss was detected and repair initiated much closer to the the loss was detected and repair initiated much closer to the source,
source, the delay for the receiver to recover from packet loss can be the delay for the receiver to recover from packet loss can be reduced
reduced through the combination of intermediary feedback to the through the combination of intermediary feedback to the source and
source and Third Party Loss Report downstream. In all (properly Third Party Loss Report downstream.
operating) cases, the risk of increasing network congestion is
decreased.
4. Format of RTCP Feedback Messages 4. Format of RTCP Feedback Messages
This document registers two new RTCP Feedback messages for Third This document registers two new RTCP Feedback messages for Third
Party Loss Report. Applications that are employing one or more loss- Party Loss Report. Applications that are employing one or more loss-
repair methods MAY use Third Party Loss Report together with their repair methods MAY use Third Party Loss Report together with their
existing loss-repair methods either for every packet they expect to existing loss-repair methods either for every packet they expect to
receive, or for an application-specific subset of the RTP packets in receive, or for an application-specific subset of the RTP packets in
a session. In other words, receivers MAY ignore Third Party Loss a session. In other words, receivers MAY ignore Third Party Loss
Report messages, but SHOULD react to them unless they have good Report messages, but SHOULD react to them unless they have good
skipping to change at page 9, line 48 skipping to change at page 8, line 48
byte-string = <as defined in section 4.2 of [RFC4585] > byte-string = <as defined in section 4.2 of [RFC4585] >
Refer to Section 4.2 of [RFC4585] for a detailed description and the Refer to Section 4.2 of [RFC4585] for a detailed description and the
full syntax of the "rtcp-fb" attribute. full syntax of the "rtcp-fb" attribute.
6. Example Use Cases 6. Example Use Cases
The operation of feedback suppression is similar for all types of RTP The operation of feedback suppression is similar for all types of RTP
sessions and topologies [RFC5117], however the exact messages used sessions and topologies [RFC5117], however the exact messages used
and the scenarios in which suppression is employed differ for various and the scenarios in which suppression is employed differ for various
use cases. The following sections outline the intended use cases of use cases. The following sections outline some of the intended use
using Third Party Loss Report for feedback suppression and give an cases for using Third Party Loss Report for feedback suppression and
overview of the particular mechanisms. give an 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. Note that each receiver sending multicast
NACK to its group may still need to send unicast NACK addressed to
the media source or distribution source , this may lead to a NACK
storm if feedback suppression is not performed and if the RTCP
bandwidth limit is misconfigured.
As outlined in the [RFC5760], there are two Unicast Feedback models As outlined in the [RFC5760], there are two Unicast Feedback models
that may be used for reporting, - the Simple Feedback model and the that may be used for reporting, - the Simple Feedback model and the
Distribution Source Feedback Summary Model. In the simple Feedback Distribution Source Feedback Summary Model. In the simple Feedback
Model, NACKs are reflected by the distribution source to the other Model, NACKs are reflected by the distribution source to the other
receivers, and there's no need for distribution source to create the receivers, and there's no need for distribution source to create the
third-party loss report. The third-party loss report is only third-party loss report. The third-party loss report may be
generated at the distribution source when downstream loss report is generated at the distribution source when downstream loss report is
received in Distribution Source Feedback Summary model. Therefore received in the Distribution Source Feedback Summary model, since
the RTCP extension for Third Party Loss Report specified in the this summary feedback does not mandate the forwarding of NACK
Section 4 of this document only works in Distribution Source Feedback downstream.
models. Details of operation are specified in Section 6.1.1.
In order to avoid the forms of Feedback implosion described in
section 1,the distribution source should be told that the indicated
packets were lost. When one downstream receiver reports loss, the
distribution source creates a Third Party Loss Report and sent it to
all the other RTP receivers which are not aware of feedback report,
over the multicast channel. Another possibility is when there may be
multiple distribution sources placed between the media source and the
receivers, each distribution source may send its own Third Party Loss
report to downstream receivers respectively when downstream loss is
reported to each distribution source. And also the upstream
distribution source may inform downstream distribution sources in the
path of the detected packet loss using the Third Party Loss Report
messages. In response, if the upstream Third Party Loss Report
reports the different event, the downstream distribution sources
forward Third Party Loss Report received from upstream to all the RTP
receivers, over the multicast channel. If the same event is reported
both from upstream distribution source and from the downstream
receiver, the downstream distribution source may suppress creating
and sending its own report to the relevant RTP receivers. This Third
Party Loss Report message tells the receivers that the sender of the
third party loss report has received reports that the indicated
packets were lost. The distribution source then can (optionally) ask
for the lost packets from the media source or itself on behalf of all
the RTP receivers. The lost packets will either be forthcoming from
distribution source, or it irretrievably lost such that there is
nothing to be gained by the receiver sending a NACK to the media
source.
The distribution source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing
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
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).
6.1.1. Distribution Source Feedback Summary Model
In the distribution source feedback summary model, we assume there
are two distribution sources between media source and receivers:
distribution source A and distribution source B. The distribution
source A is at the upstream of distribution source B.
The distribution source A must listen on the RTP channel for data.
When the distribution source A observes RTP packets from a media
source are not consecutive by checking the sequence number of
packets, the distribution source A generates the NACK message, and
then send it to receivers in the downstream path via the multicast
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 In order to observe packet loss before the receivers perceive it, one
RTCP port. Upon receiving the RTCP Third Party Loss Report or NACK or more intermediate nodes may be placed between the media source and
message from the Distribution Source A, the Distribution Source B the receivers. These intermediaries monitor for upstream packet loss
needs to check whether it sees the same event reported both from . These intermediates may be Distribution source, MCUs, RTP
upstream distribution source A and downstream receiver. If the translator, or RTP mixers, depending on the precise implementation.
upstream Third Party Loss Report reports the different event, the If an intermediary notices the loss itself, then it may send a NACK
distribution source B passes through any Third Party Loss Report both downstream towards the receivers and upstream towards the media
message it receives from the upstream direction. If the same event source, to indicate that it has noticed the loss, and to suppress
is reported from both distribution source A and downstream receiver feedback from other downstream receivers. In the SSM case, If the
of distribution source B, the distribution source B may suppress distribution source ,using the simple feedback model, receives a NACK
creating and sending its own report with the same event to the from another system (e.g.,an intermediary), it should redistribute
downstream RTP receiver. that NACK to all other systems that would not otherwise receive it.
If the distribution source, using the summary feedback model,
receives a NACK from another system, but, for some reason(e.g., to
prevent revealing the identity or existence of a system sending
NACK), 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. . Therefore the intermediate
node can be reasonably certain that it will help the situation by
sending a Third Party Loss Report message to all the relevant
receivers, thereby indicating to the receivers that they should not
transmit 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.
Also the Distribution Source B may create and send its own Third Alternatively, the media source may directly monitor the amount of
Party Loss Report described in the Section 4 to the group over the feedback reports it receives from downstream. If the media source
multicast RTCP channel in response to NACKs received from downstream. notices the loss itself, then it may send a NACK downstream towards
if downstream loss is reported using NACK to the distribution source the receivers to suppress feedback. If the media source receives a
B. NACK from another system, it should redistribute that NACK to all
other systems that would not otherwise receive it. If the media
source receives a NACK from another system, but, for some reason
(e.g., hiding identity or existing a system sending NACK, 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.
6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use 6.2. Unicast based Rapid Acquisition of Multicast Stream (RAMS) use
case case
The typical RAMS architecture The typical RAMS architecture [RFC6285] may have several Burst/
Retransmission Sources(BRS) behind the multicast source (MS) placed
[I-D.ietf-avt-rapid-acquisition-for-rtp] may have several Burst/ at the same level. These BRSes will receive the multicast SSM stream
Retransmission Sources(BRS) behind the multicast source (MS) These from the media source. If one of the BRSes receives downstream loss
BRSes will receive the multicast SSM stream from the media source. report (i.e., First loss in Figure 3) on its downstream link, but the
If one of the BRSes receives downstream loss report (i.e., First loss others BRSes have not, as the packet loss took place on the SSM tree
in Figure 3) on its downstream link, but the others BRSes have not, branch that does not impact the other BRSes. In such case, the BRSes
as the packet loss took place on the SSM tree branch that does not not being impacted are not aware of downstream loss at their
impact the other BRSes. In such case, the BRSes not being impacted downstream link, therefore these BRSes will not create new Third
are not aware of downstream loss at their downstream link, therefore Party Loss Report message and send it to receivers in their
these BRSes will not create new Third Party Loss Report message and downstream path. If the BRS impacted by packet loss has been told
send it to receivers in their downstream path. If the BRS impacted the actual packet loss, the BRS MAY choose to create new Third Party
by packet loss has been told the actual packet loss, the BRS MAY Loss Report message and send it to the receivers in the downstream
choose to create new Third Party Loss Report message and send it to link. Note that BRS must use its own SSRC as packet sender SSRC for
the receivers in the downstream link. Note that BRS must use its own transmitting the feedback suppress message.
SSRC as packet sender SSRC for transmitting the feedback suppress
message.
The BRS may also send a NACK upstream to request the retransmitted The BRS may also send a NACK upstream to request the retransmitted
packet. Upon receiving the retransmitted packet, the BRS sent it packet. Upon receiving the retransmitted packet, the BRS sent it
downstream. Note that this retransmitted packet may get lost (i.e., downstream. Note that this retransmitted packet may get lost (i.e.,
second loss in the Figure 3) on the downstream link. In order to second loss in the Figure 3) on the downstream link. In order to
deal with this issue, the downstream receiver can start a timeout deal with this issue, the downstream receiver can start a timeout
clock in which it expected to get a retransmission packet. When this clock in which it expected to get a retransmission packet. When this
timeout expires and there is no retransmitted packet or a new Third timeout expires and there is no retransmitted packet or a new Third
Party Loss Report message, it can take its normal behavior as if Party Loss Report message, it can take its normal behavior as if
there is no current retransmission suppression in place. there is no current retransmission suppression in place.
skipping to change at page 13, line 36 skipping to change at page 11, line 36
link k +------------+ link k +----------+ link k +------------+ link k +----------+
Figure 3: RAMS Use Case Figure 3: RAMS Use Case
6.3. RTP transport translator use case 6.3. RTP transport translator use case
A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117] A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117]
is typically forwarding the RTP and RTCP traffic between RTP clients, is typically forwarding the RTP and RTCP traffic between RTP clients,
for example converting between multicast and unicast for domains that for example converting between multicast and unicast for domains that
do not support multicast. The translator can identify packet loss do not support multicast. The translator can identify packet loss
from the upstream and send the Third Party Loss Report message to the using co-located monitor [I-D.ietf-avtcore-monarch] by receiving a
unicast receivers. Note that the translator must be a participant in NACK from another system and then the monitor can use it's own SSRC
the session and can then use it's own SSRC as packet sender SSRC for as packet sender SSRC for transmitting the Third Party Loss Report
transmitting the Third Party Loss Report message message and send this message to the unicast receivers that is not
aware of packet loss.
6.4. Multipoint Control Unit (MCU) use case 6.4. Multipoint Control Unit (MCU) use case
In point to multipoint topologies using video switching MCU (Topo- In point to multipoint topologies using video switching MCU (Topo-
Video-switch-MCU) [RFC5117], the MCU typically forwards a single Video-switch-MCU) [RFC5117], the MCU typically forwards a single
media stream to each participant, selected from the available input media stream to each participant, selected from the available input
streams. The selection of the input stream is often based on voice streams. The selection of the input stream is often based on voice
activity in the audio-visual conference, but other conference activity in the audio-visual conference, but other conference
management mechanisms (like presentation mode or explicit floor management mechanisms (like presentation mode or explicit floor
control) exist as well. control) exist as well.
In this case the MCU may detect packet loss from the sender or may In this case the MCU may identify packet loss by receiving a NACK
decide to switch to a new source. In both cases the receiver may from another system or may decide to switch to a new source. In both
lose synchronization with the video stream and may send a FIR cases the receiver may lose synchronization with the video stream and
request. If the MCU itself can detect the mis-synchronization of the may send a FIR request. If the MCU itself can detect the mis-
video, the MCU can send the FIR suppression message to the receivers synchronization of the video, the MCU can send the FIR suppression
and send a FIR request to the video source. As suggested in RFC message to the receivers and send a FIR request to the video source.
5117, this topology is better implemented as an Topo-mixer, in which As suggested in RFC 5117, this topology is better implemented as an
case the mixer's SSRC is used as packet sender SSRC for transmitting Topo-mixer, in which case the mixer's SSRC is used as packet sender
Third Party Loss Report message. SSRC for transmitting Third Party Loss Report message.
7. Security Considerations 7. Security Considerations
The defined messages have certain properties that have security The defined messages have certain properties that have security
implications. These must be addressed and taken into account by implications. These must be addressed and taken into account by
users of this protocol. users of this protocol.
Spoofed or maliciously created feedback messages of the type defined Spoofed or maliciously created feedback messages of the type defined
in this specification can have the following implications: in this specification can have the following implications:
skipping to change at page 17, line 6 skipping to change at page 15, line 10
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport "NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", November 2009. Protocol", November 2009.
[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] [RFC6285] 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. June 2011.
[I-D.ietf-avtcore-monarch-01] [I-D.ietf-avtcore-monarch]
Wu, Q., "Monitoring Architectures for RTP", May 2011. Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures
for RTP", June 2011.
[I-D.ietf-pmol-metrics-framework-08] [I-D.ietf-pmol-metrics-framework]
Clark, A. and B. Claise, "Framework for Performance Metric Clark, A. and B. Claise, "Framework for Performance Metric
Development", January 2011. 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:
o Remove the merge report from SSM use case and addional text to o Remove the merge report from SSM use case and additional 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
skipping to change at page 18, line 18 skipping to change at page 16, line 20
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 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03
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 Appendix A, fix typo: Appendix A. Appendix A. -> Appendix A.
o Update abstract to clarify when third-party loss reports should be o Update abstract to clarify when third-party loss reports should be
sent instead of NACKs. sent instead of NACKs.
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.
skipping to change at page 18, line 36 skipping to change at page 16, line 38
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 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Reference Update. o Reference Update.
o Clarify the use of the third party loss report in section 3 and o Clarify the use of the third party loss report in section 3 and
section 6.1.1. section 6.1.1.
A.5. draft-ietf-avtcore-feedback-suppression-rtp-05
The following are the major changes compared to previous version:
o Remove 3rd and 4th paragraphs of section 6.1 and replaced them
with 2nd and 3rd paragraphs of section 3.
o Remove section 6.1.1.1.
o Revise the last paragraph of section 1 to clarify the rationale of
using new message.
o Update RTP transport translator case in section 6.3 to correct the
use of the third party loss report.
o Update MCU case in section 6.4 to correct the use of the third
party loss report.
o Revise SSM use case to address multiple DS issue.
o References Update.
o Move one rationale on preventing sending unicast NACK in
introduction section to SSM case section.
o Other Editorial changes to section 6.1, 6.1.1, 6.2.
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. 31 change blocks. 
248 lines changed or deleted 197 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/