draft-ietf-avtcore-feedback-supression-rtp-06.txt   draft-ietf-avtcore-feedback-supression-rtp-07.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: March 3, 2012 Huawei Expires: March 29, 2012 Huawei
August 31, 2011 September 26, 2011
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-06 draft-ietf-avtcore-feedback-supression-rtp-07
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 cases where it is not duplicate feedback reports. However, there are cases where it is not
recommended to forward feedback reports, and this may allow feedback recommended to forward feedback reports, and this may allow feedback
implosion. This memo discusses these cases and defines a new RTCP implosion. This memo discusses these cases and defines a new RTCP
third-party loss report that can be used to inform receivers that a third-party loss report that can be used to inform receivers that the
feedback target is aware of some loss event, allowing them to network is aware of some loss event, allowing them to suppress
suppress feedback. Associated SDP signalling is also defined. 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 March 3, 2012. This Internet-Draft will expire on March 29, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 6 4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 5
4.1. Transport Layer Feedback: Third-party Loss Report . . . . 6 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 5
4.2. Payload Specific Feedback: Third-party Loss Report . . . . 7 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 6
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 8
6.2. Unicast based Rapid Acquisition of Multicast Stream 6.2. Unicast based Rapid Acquisition of Multicast Stream
(RAMS) use case . . . . . . . . . . . . . . . . . . . . . 10 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 9
6.3. RTP transport translator use case . . . . . . . . . . . . 11 6.3. RTP transport translator use case . . . . . . . . . . . . 9
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 11 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.5. Mixer use Case . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 15 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 15 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 13
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 16 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 14
A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 16 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 14
A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 16 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 14
A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 17 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 15
A.7. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 when using unicast RTCP feedback with SSM a delegated feedback target when using unicast RTCP feedback with SSM
[RFC5760]). There are cases where multiple receivers may initiate [RFC5760]). There are cases where multiple receivers may initiate
the same, or an equivalent message towards the same media source. the same, or an equivalent message towards the same media source.
When the receiver count is large, this behavior may cause transient When the receiver count is large, this behavior may cause transient
overload of the media source, the network or both. This is known as overload of the media source, the network or both. This is known as
a "feedback storm" or a "NACK storm". One common cause of such a a "feedback storm" or a "NACK storm". One common cause of such a
feedback storm is receivers utilizing RTP retransmission [RFC4588] as feedback storm is receivers utilizing RTP retransmission [RFC4588] as
a packet loss recovery technique based, sending feedback using RTCP a packet loss recovery technique based, sending feedback using RTCP
NACK messages [RFC4585] without proper dithering of the NACK messages [RFC4585] without proper dithering of the
retransmission requests. retransmission requests (e.g., implementing the RFC 4585 dithering
rules or sending NACKs to a middlebox that doesn't redistribute them
to other receivers).
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 multipoint video switching conference [RFC4587]. In
packet loss may happen on an upstream link of an intermediate network this scenario, the receiver may lose synchronization with the video
element such as a Multipoint Control Unit(MCU). Poorly designed stream when speaker is changed in the middle of session. Poorly
receivers that blindly issue fast update requests (i.e., Full Intra designed receivers that blindly issue fast update requests (i.e.,
Request (FIR) described in [RFC5104]), can cause an implosion of FIR Full Intra Request (FIR) described in [RFC5104]), can cause an
requests from receivers to the same media source. implosion of FIR 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 NACK is defined as a receiver report the sender of NACK. However NACK is defined as a receiver report
sent from a receiver observing a packet loss, therefore it only sent from a receiver observing a packet loss, therefore it only
inform others that sender of NACK detected loss while the case the inform others that sender of NACK detected loss while the case the
sender of the feedback has received reports that the indicated 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
third-party loss report for this function. It further is more third-party loss report for this function. It supplements the
precise in the intended uses and less likely to be confusing to existing the use of RTCP NACK packet and further is more precise in
receivers. It tells receivers explicitly that feedback for a the uses where the network is active to suppress feedback. It tells
particular packet or frame loss is not needed for a period of time receivers explicitly that feedback for a particular packet or frame
and can provide an early indication before the receiver reacts to the loss is not needed for a period of time and can provide an early
loss and invokes its packet loss repair machinery. Section 6 indication before the receiver reacts to the loss and invokes its
provides some examples of when to send the Third Party Loss Report packet loss repair machinery. Section 6 provides some examples of
message. when to send the Third Party Loss Report message. 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 (RTP/AVPF) [RFC4585] defining a Audio-Visual Profile with feedback (RTP/AVPF) [RFC4585] defining a
Third Party Loss Report message. The Third Party Loss Report message Third Party Loss Report message. The Third Party Loss Report message
can be used by the media source or intermediaries to inform the can be used by the intermediaries to inform the receiver that the
receiver that the sender of the Third Party Loss Report has received sender of the Third Party Loss Report has received reports that the
reports that the indicated packets were lost, and asks the receiver indicated packets were lost, and asks the receiver not to send
not to send feedback to it regarding these packets. feedback to it regarding these packets.
RTCP Third Party Loss Report follows the similar format of message
type as RTCP NACK or Full Intra Request Command. However, the Third
Party Loss Report is defined as an indication that the sender of the
feedback has received reports that the indicated packets were lost,
while NACK [RFC4585] just indicates that the sender of the NACK
observed that these packets were lost. The Third Party Loss Report
message is generated by a RTP system that has not seen the actual
packet loss and sent following the same timing rule as sending NACK
defined in [RFC4585], e.g., The TPLR message may be sent in a regular
full compound RTCP packet or in an early RTCP packet, as per AVPF.
RTP Systems in the network that receive a Third Party Loss Report
SHOULD NOT initiate their own additional Third Party Loss Report
messages for the same packet sequence numbers. They should simply
forward the Third Party Loss Report message received from upstream
direction, additionally, they may generate their own Third Party Loss
Report that reports a set of the losses they see, which are different
from ones reported in the Third Party Loss report they received. The
Third Party Loss Report does not have the retransmission request
[RFC4588] semantics.
When a receiver gets a Third Party Loss Report message, it should When a receiver gets a Third Party Loss Report message, it should
refrain from sending a feedback request (e.g., NACK or FIR) for the start a timer for this message and refrain from sending a feedback
missing packets reported in the message for a certain period of time. request (e.g., NACK or FIR) for the missing packets reported in the
message during the lifetime of the timer. The timer value shall be
based on the observed round-trip time. A receiver should compute an
estimate of the round-trip time (RTT) to the sender of TPLR from RTCP
report round-trip time if available, or its reception time of the
reflected RTCP FB message (e.g.,NACK), or any other means.
To increase the robustness to the loss of a TPLR or of a transmission
packet, a receiver is allowed to receive additional TPLR for the same
packet. In the case the first TPLR is lost and the additional TPLR
arrives at the receiver, the receiver should immediately refresh the
timer. When the timer for this message expires and there is no
retransmitted packet or a new Third Party Loss Report message, the
receiver should take its normal behavior as if there is no current
retransmission suppression.
A receiver may still have sent a Feedback message according to the A receiver may still have sent a Feedback message according to the
RTP/AVPF scheduling algorithm of [RFC4585]before receiving a Third RTP/AVPF scheduling algorithm of [RFC4585] before receiving a Third
Party Loss Report message, but further feedback messages for those Party Loss Report message, but further feedback messages for those
sequence numbers will be suppressed by this technique for a certain sequence numbers will be suppressed by this technique for a certain
period of time. Nodes that do not understand the Third Party Loss period of time. Nodes that do not understand the Third Party Loss
Report message will ignore it, and might therefore still send Report message will ignore it, and might therefore still send
feedback according to the AVPF scheduling algorithm of [RFC4585]. feedback according to the AVPF scheduling algorithm of [RFC4585].
The media source or intermediate nodes cannot assume that the use of The media source or intermediate nodes cannot assume that the use of
a Third Party Loss Report message actually reduces the amount of a Third Party Loss Report message actually reduces the amount of
feedback it receives. feedback it receives.
RTCP Third Party Loss Report follows the similar format of message
type as RTCP NACK. However, the Third Party Loss Report is defined
as an indication that the sender of the feedback has received reports
that the indicated packets were lost, while NACK [RFC4585] just
indicates that the sender of the NACK observed that these packets
were lost. The Third Party Loss Report message is generated by a
system that has not seen the actual packet loss. Systems that
receive a Third Party Loss Report SHOULD NOT initiate their own
additional Third Party Loss Report messages for the same packet
sequence numbers. They may either simply forward the Third Party
Loss Report message, or they may generate their own Third Party Loss
Report that reports a set of the losses they see, which are different
from ones reported in the Third Party Loss report they received. 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. In order not to incur a lot of NACK
the retransmitted packet by sending a NACK upstream and sent it requests due to additional TPLR described above, it is recommended
downstream. This retransmitted packet was lost on the downstream that the RTP system sending TPLR should be implemented more closer to
link. In order to deal with this, the downstream receiver can start the source. Also when the loss was detected and repair initiated
a timeout in which it expected to get a retransmission packet. When much closer to the source, the delay for the receiver to recover from
this timeout expires and there is no retransmitted packet or a new packet loss can be reduced through the combination of intermediary
Third Party Loss Report message, it can take its normal behavior as feedback to the source and Third Party Loss Report downstream.
if there is no current retransmission suppression. In the case when
the loss was detected and repair initiated much closer to the source,
the delay for the receiver to recover from packet loss can be reduced
through the combination of intermediary feedback to the source and
Third Party Loss Report downstream.
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 the Third Party Loss Report together with repair methods MAY use the Third Party Loss Report together with
their existing loss-repair methods either for every packet they their existing loss-repair methods either for every packet they
expect to receive, or for an application-specific subset of the RTP expect to receive, or for an application-specific subset of the RTP
packets in a session. In other words, receivers MAY ignore Third packets in a session. In other words, receivers MAY ignore Third
Party Loss Report messages, but SHOULD react to them unless they have Party Loss Report messages, but SHOULD react to them unless they have
good reason to still send feedback messages despite having been good reason to still send feedback messages despite having been
requested to suppress them. requested to suppress them.
4.1. Transport Layer Feedback: Third-party Loss Report 4.1. Transport Layer Feedback: Third-party Loss Report
This Third Party Loss Report message is an extension to the RTCP This Third Party Loss Report message is an extension to the RTCP
Transport Layer Feedback Report and identified by RTCP packet type Transport Layer Feedback Report and identified by RTCP packet type
value PT=RTPFB and FMT=TBD. value PT=RTPFB and FMT=TBD.
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source"
denotes the media sender.
The FCI field MUST contain one or more entries of transport layer The FCI field MUST contain one or more entries of transport layer
third party loss Early Indication (TLLEI). Each entry applies to a third party loss Early Indication (TLLEI). Each entry applies to the
different media source, identified by its SSRC. same media source identified by the SSRC contained in the SSRC of
media source field of Feedback header.
The Feedback Control Information (FCI) for TLLEI uses the similar The Feedback Control Information (FCI) for TLLEI uses the similar
format of message Types defined in the section 6.2.1 of [RFC4585]. format of message Types defined in the section 6.2.1 of [RFC4585].
The format is shown in Figure 1. The format is shown in Figure 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP | | PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 19 skipping to change at page 6, line 39
bitmask of proceeding lost packets (BLP): 16 bits bitmask of proceeding lost packets (BLP): 16 bits
The BLP allows for reporting losses of any of the 16 RTP packets The BLP allows for reporting losses of any of the 16 RTP packets
immediately following the RTP packet indicated by the PID. The immediately following the RTP packet indicated by the PID. The
BLP's definition is identical to that given in [RFC4585]. BLP's definition is identical to that given in [RFC4585].
4.2. Payload Specific Feedback: Third-party Loss Report 4.2. Payload Specific Feedback: Third-party Loss Report
This message is an extension to the RTCP Payload Specific Feedback This message is an extension to the RTCP Payload Specific Feedback
report and identified by RTCP packet type value PT=PSFB and FMT=TBD. report and identified by RTCP packet type value PT=PSFB and FMT=TBD,
which is used to suppress FIR [RFC5104]or PLI [RFC4585].
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source"
is not used and SHALL be set to 0. The SSRCs of the media senders to
which this message applies are in the corresponding FCI entries.
The FCI field MUST contain a Payload Specific Third Party Loss Early The FCI field MUST contain a Payload Specific Third Party Loss Early
Indication (PSLEI) entry. Each entry applies to a different media Indication (PSLEI) entry. Each entry applies to a different media
source, identified by its SSRC. Source that is requested to send a decoder refresh point or that is
indicated that it lost synchronization with the video stream,
identified by its SSRC.
The Feedback Control Information (FCI) for PSLEI uses the similar The Feedback Control Information (FCI) for PSLEI uses the similar
format of message Types defined in the section 4.3.1.1 of [RFC5104]. format of message Types defined in the section 4.3.1.1 of [RFC5104].
The format is shown in Figure 2. The format is shown in Figure 2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved | | Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Message Format for the Third Party Loss Report Figure 2: Message Format for the Third Party Loss Report
SSRC (32 bits): SSRC (32 bits):
The SSRC value of the media source that is requested to send a The SSRC value of the media source that is requested to send a
decoder refresh point. decoder refresh point or that is indicated that it lost
synchronization with the video stream.
Seq nr:8bits Command sequence number. The sequence number space is Seq nr:8bits Command sequence number. It is used by the Command
unique for each pairing of the SSRC of command source and the SSRC receiver to check if the Command is repeated. The sequence number
of the command target. The sequence number SHALL be increased by space is unique for each pairing of the SSRC of command sender and
1 modulo 256 for each new request. the SSRC of the command receiver. The sequence number SHALL
increase by 1 modulo 256 for each new Command. A repetition SHALL
NOT increase the sequence number. The initial value is arbitrary.
Reserved: 24 bits Reserved: 24 bits
All bits SHALL be set to 0 by the media source and SHALL be All bits SHALL be set to 0 by the media source and SHALL be
ignored on reception. ignored on reception.
5. SDP Signaling 5. SDP Signaling
A new feedback value "tplr" needs to be defined for the Third Party A new feedback value "tplr" needs to be defined for the Third Party
Loss Report message to be used with Session Description Protocol Loss Report message to be used with Session Description Protocol
skipping to change at page 9, line 11 skipping to change at page 8, line 41
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 some of the intended use use cases. The following sections outline some of the intended use
cases for using the Third Party Loss Report for feedback suppression cases for using the Third Party Loss Report for feedback suppression
and give an overview of the particular mechanisms. and 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. Note that each receiver sending multicast specific multicast group.
NACK to its group may still need to send unicast NACK addressed to
the media source or distribution source for lost packets, 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, there's no need for distribution source to create the Third
receivers, and there's no need for distribution source to create the Party Loss Report, instead, NACKs are reflected by the distribution
Third Party Loss Report. The Third Party Loss Report may be source to the other Receivers. However in the Distribution Source
generated at the distribution source when downstream loss report is Feedback Summary model, the distribution source will not redistribute
received in the Distribution Source Feedback Summary model, since the NACK for some reason(e.g., to prevent revealing the identity or
this summary feedback does not mandate the forwarding of NACK existence of a system sending NACK)and may send a Third Party Loss
downstream. Report to the systems that were unable to receive the NACK, and won't
receive the NACK via other means. since the summary feedback does not
In order to observe packet loss before the receivers perceive it, one mandate the forwarding of NACK downstream. The Third Party Loss
or more intermediate nodes may be placed between the media source and Report can be generated at the distribution source when downstream
the receivers. These intermediaries monitor for upstream packet loss loss is told (e.g., downstream loss report is received), which
. These intermediates may be Distribution source, MCUs, RTP indicates to the receivers that they should not transmit feedback
translator, or RTP mixers, depending on the precise implementation. messages for the same loss event for a certain time. Therefore the
If an intermediary notices the loss itself, then it may send a NACK distribution source in the feedback summary model can be reasonably
both downstream towards the receivers and upstream towards the media certain that it will help the situation by sending this Third Party
source, to indicate that it has noticed the loss, and to suppress Loss Report message to all the relevant receivers impacted by the
feedback from other downstream receivers. In the SSM case, If the packet loss.
distribution source ,using the simple feedback model, receives a NACK
from another system (e.g.,an intermediary), it should redistribute
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 certain 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
notices the loss itself, then it may send a NACK downstream towards
the receivers to suppress feedback. 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. 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 [RFC6285] may have several Burst/ The typical RAMS architecture [RFC6285] may have several Burst/
Retransmission Sources(BRS) behind the multicast source (MS) placed Retransmission Sources(BRS) behind the multicast source (MS) placed
at the same level. These BRSes will receive the multicast SSM stream at the same level. These BRSes will receive the primary multicast
from the media source. If one of the BRSes receives downstream loss RTP stream from the media source and cache most recent packets after
report (i.e., First loss in Figure 3) on its downstream link, but the joining multicast session. If packet loss happens at the upstream of
others BRSes have not, as the packet loss took place on the SSM tree all the BRSs or the downstream of one or more BRSes. one of the BRSes
branch that does not impact the other BRSes. In such case, the BRSes or all the BRSes may send a NACK or TPLR message to the DS, where the
not being impacted are not aware of downstream loss at their SSRC in this NACK or TPLR message is the one of the BRS. The DS
downstream link, therefore these BRSes will not create a new Third forwards/reflects this message down on the primary SSM. The details
Party Loss Report message and send it to receivers in their on how DS deal with this message is specified in
downstream path. If the BRS impacted by packet loss has been told [RETRANSMISSION-FOR-SSM].
the actual packet loss, the BRS MAY choose to create new Third Party
Loss Report message and send it to the receivers in the downstream
link. Note that BRS must use its own SSRC as packet sender SSRC for
transmitting the feedback suppress message.
The BRS may also send a NACK upstream to request the retransmitted
packet. Upon receiving the retransmitted packet, the BRS sent it
downstream. Note that this retransmitted packet may get lost (i.e.,
second loss in the Figure 3) on the downstream link. In order to
deal with this issue, the downstream receiver can start a timeout
clock in which it expected to get a retransmission packet. When this
timeout expires and there is no retransmitted packet or a new Third
Party Loss Report message, it can take its normal behavior as if
there is no current retransmission suppression in place.
+------------+ First Loss +----------+
|Burst and |Second Loss | |
+-----------| Retrans. |----X--X--->| |
| Upstream |Source1(BRS)| Downstream | |
Link close | link 1 +------------+ link 1 | |
to multicast | | |
source | | |
| | | |
| | +------------+ | RTP |
+---------+ | +-----++ |Burst and | | Receiver |
|Multicast| V| | +----------| Retrans. |----------->| |
| Source +-----|Router|Upstream |Source2(BRS)| Downstream | RTP_Rx |
+---------+ | |link 2 +------------+ link 2 | |
+-----++ | |
| | |
| | |
| | |
| +------------+ | |
| |Burst and | | |
+-----------+ Retrans. |----------->| |
Upstream |Source k(BRS| Downstream | |
link k +------------+ link k +----------+
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 acting as quality
using co-located monitor [I-D.ietf-avtcore-monarch] by receiving a monitoring [Monarch] may suffer a loss of important video packets.
NACK from another system and then the monitor can use it's own SSRC In this case, the translator may trigger repair by the media sender
as packet sender SSRC for transmitting the Third Party Loss Report and at the same time,use it's own SSRC as packet sender SSRC to
message and send this message to the unicast receivers that is not create a new Third Party Loss Report message and send it to the
aware of packet loss. 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- When the speaker is changed in a voice-activated multipoint video
Video-switch-MCU) [RFC5117], the MCU typically forwards a single switching conference [RFC4587], an RTP mixer can be used to select
media stream to each participant, selected from the available input the available input streams and forward them to each participants.
streams. The selection of the input stream is often based on voice If the MCU is doing a blind switch without waiting for a
activity in the audio-visual conference, but other conference synchronization point on the new stream it can send a FIR to the new
management mechanisms (like presentation mode or explicit floor video source. In this case the MCU should send a FIR suppression
control) exist as well. message to the new receivers. e.g.,when the RTP Mixer starts to
receive FIR from some participants it can suppress the remaining
session participants from sending FIR by sending out a Third party
Loss report message.
In this case the MCU may identify packet loss by receiving a NACK 6.5. Mixer use Case
from another system or may decide to switch to a new source. In both
cases the receiver may lose synchronization with the video stream and A Mixer, in accordance with [RFC5117], aggregates multiple RTP
may send a FIR request. If the MCU itself can detect the mis- streams from other session participants and generates a new RTP
synchronization of the video, the MCU can send the FIR suppression stream sent to the session participants. In some cases, the video
message to the receivers and send a FIR request to the video source. frames may get badly screwed up between media source and the mixer.
As suggested in RFC 5117, this topology is better implemented as an In such case, the mixer need to check if the packet loss will result
Topo-Mixer, in which case the mixer's SSRC is used as packet sender in PLI or FIR transmissions from most of the group by analyzing the
SSRC for transmitting the Third Party Loss Report message. received video. If so the mixer initiates FIR or PLI towards the
media source on behalf of all the session participants and send out a
Third party Loss report message to these session participants that
may or are expected to send a PLI or FIR Another possible way for
mixer to deal with, is when the mixer starts to receive FIR or PLI
from some participants and like to suppress the remaining session
participants from sending FIR or PLI by sending out a 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:
Sending the Third Party Loss Report with wrong sequence number of Sending the spurious Third Party Loss Report (e.g., the Third Party
lost packet that makes missing RTP packets can not be compensated. Loss Report with the wrong sequence number of lost packet) that makes
missing RTP packets can not be compensated.
To prevent these attacks, there is a need to apply authentication and To prevent these attacks, there is a need to apply authentication and
integrity protection of the feedback messages. This can be integrity protection of the feedback messages. This can be
accomplished against threats external to the current RTP session accomplished against threats external to the current RTP session
using the RTP profile that combines Secure RTP [RFC3711] and AVPF using the RTP profile that combines Secure RTP [RFC3711] and AVPF
into SAVPF [RFC5124]. into SAVPF [RFC5124].
Note that middleboxes that are not visible at the RTP layer that wish Note that middleboxes that are not visible at the RTP layer that wish
to send the Third Party Loss Reports on behalf of the media source to send the Third Party Loss Reports on behalf of the media source
can only do so if they spoof the SSRC of the media source. This is can only do so if they spoof the SSRC of the media source. This is
difficult in case SRTP is in use. If the middlebox is visible at the difficult in case SRTP is in use. If the middlebox is visible at the
RTP layer, this is not an issue, provided the middlebox is part of RTP layer, this is not an issue, provided the middlebox is part of
the security context for the session. the security context for the session.
Also note that endpoints that receive a Third Party Loss Report would Also note that endpoints that receive a Third Party Loss Report would
be well-advised to ignore it, unless it is authenticated via SRTCP or be well-advised to ignore it, unless the security is in place to
similar. Accepting un-authenticated Third Party Loss Report can lead authenticate the sender of the Third Party Loss Report. Accepting
to a denial of service attack, where the endpoint accepts poor Third Party Loss Report from un-authenticated sender can lead to a
quality media that could be repaired. denial of service attack, where the endpoint accepts poor quality
media that could be repaired.
8. IANA Consideration 8. IANA Consideration
New feedback type and New parameters for RTCP Third Party Loss Report The new value "TPLR" has been registered with IANA in the "rtcp-fb"
are subject to IANA registration. For general guidelines on IANA Attribute Values registry located at the time of publication at:
considerations for RTCP feedback, refer to [RFC4585]. http://www.iana.org/assignments/sdp-parameters
This document assigns one new feedback type value in the RTCP
feedback report registry to "Third Party Loss Report" with the
following registrations format:
Name: TPLR Value name: tplr
Long Name: Third Party Loss Report Long Name: Third Party Loss Reports
Value: TBD Reference: This document
Reference: This document.
This document also assigns the parameter value in the RTCP TPLR A new registry " Third Party Loss Report Messages" has been created
feedback report Registry to " Transport Layer Third Party Loss Early to hold "tplr" parameters located at time of publication at:
Indication ", with the following registrations format: http://www.iana.org/assignments/sdp-parameters
Name: TLLEI New registration in this registry follows the "Specification
Long name: Transport Layer Third Party Loss Early Indication required" policy as defined by [RFC2434]. In addition, they are
Value: TBD required to indicate any additional RTCP feedback types, such as
Reference: this document. "nack" and "ack".
This document also assigns the parameter value in the RTCP TPLR The following values have been registered as FMT values in the "FMT
feedback report Registry to "Payload Specific Third Party Loss Early Values for RTPFB Payload Types" registry located at the time of
Indication ", with the following registrations format: publication at: http://www.iana.org/assignments/rtp-parameters
Name: PSLEI RTPFB range
Long name: Payload Specific Third Party Loss Early Indication Name Long Name Value Reference
Value: TBD -------------- --------------------------------- ----- ---------
Reference: this document. TLLEI Transport Layer Third Party X [RFCXXXX]
Loss Early Indication
The contact information for the registrations is: The following values have been registered as FMT values in the "FMT
Values for PSFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters
Qin Wu PSFB range
sunseawq@huawei.com Name Long Name Value Reference
101 Software Avenue, Yuhua District -------------- --------------------------------- ----- ---------
Nanjing, Jiangsu 210012, China PSLEI Payload Specific Third Party X [RFCXXXX]
Loss Early Indication
9. Acknowledgement 9. Acknowledgement
The authors would like to thank David R Oran, Ali C. Begen, Colin The authors would like to thank David R Oran, Magnus Westerlund,
Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, Colin Perkins, Ali C. Begen, Tom VAN CAENEGEM, Ingemar Johansson S,
Jonathan Lennox, WeeSan Lee for their valuable comments and Bill Ver Steeg, Jonathan Lennox, WeeSan Lee for their valuable
suggestions on this document. comments and suggestions on this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
skipping to change at page 14, line 22 skipping to change at page 12, line 32
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 15, line 14 skipping to change at page 13, line 21
[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.
[RFC6285] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- [RFC6285] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
June 2011. June 2011.
[I-D.ietf-avtcore-monarch] [Monarch] Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures
Wu, Q., Hunt, G., and P. Arden, "Monitoring Architectures
for RTP", June 2011. for RTP", June 2011.
[I-D.ietf-pmol-metrics-framework] [RETRANSMISSION-FOR-SSM]
Clark, A. and B. Claise, "Framework for Performance Metric Caenegem, T., Steeg, B., and A. Begen, "Retransmission for
Development", January 2011. Source-Specific Multicast (SSM) Sessions", May 2011.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams",
RFC 4587, August 2006.
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 17, line 23 skipping to change at page 15, line 39
o References Update. o References Update.
o Move one rationale on preventing sending unicast NACK in o Move one rationale on preventing sending unicast NACK in
introduction section to SSM case section. introduction section to SSM case section.
o Other Editorial changes to section 6.1, 6.1.1, 6.2. o Other Editorial changes to section 6.1, 6.1.1, 6.2.
A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 A.6. draft-ietf-avtcore-feedback-suppression-rtp-06
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o A few Editorial changes to the whole document. o A few Editorial changes to the whole document.
A.7. draft-ietf-avtcore-feedback-suppression-rtp-07
The following are the major changes compared to previous version:
o Restructuring the protocol overview section to clarify the round
trip time calculation and receiver behavior to the additional
TPLR.
o Restructuring the SSM use case section to focus on the use of
TPLR.
o Editorial changes to the abstract, introduction, message format,
use cases and IANA sections.
o References update
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. 46 change blocks. 
274 lines changed or deleted 257 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/