draft-ietf-avtcore-feedback-supression-rtp-05.txt   draft-ietf-avtcore-feedback-supression-rtp-06.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: January 12, 2012 Huawei Expires: March 3, 2012 Huawei
July 11, 2011 August 31, 2011
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-05 draft-ietf-avtcore-feedback-supression-rtp-06
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on March 3, 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 32 skipping to change at page 3, line 32
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 15 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 15
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 15 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 15
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 16 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 16
A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 16 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 16
A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 16 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 16
A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
RTCP feedback messages [RFC4585] allow the receivers in an RTP RTCP feedback messages [RFC4585] allow the receivers in an RTP
session to report events and ask for action from the media source (or session to report events and ask for action from the media source (or
a delegated feedback target 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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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 further is more
precise in the intended uses and less likely to be confusing to precise in the intended uses and less likely to be confusing to
receivers. It tells receivers explicitly that feedback for a receivers. It tells receivers explicitly that feedback for a
particular packet or frame loss is not needed for a period of time particular packet or frame loss is not needed for a period of time
and can provide an early indication before the receiver reacts to the and can provide an early indication before the receiver reacts to the
loss and invokes its packet loss repair machinery. Section 6 loss and invokes its packet loss repair machinery. Section 6
provides some examples of when to send the third party loss report provides some examples of when to send the Third Party Loss Report
message. 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 media source or intermediaries to inform the
receiver that the sender of the Third Party Loss Report has received receiver that the sender of the Third Party Loss Report has received
reports that the indicated packets were lost, and asks the receiver reports that the indicated packets were lost, and asks the receiver
not to send feedback to it regarding these packets. not to send feedback to it regarding these packets.
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 refrain from sending a feedback request (e.g., NACK or FIR) for the
missing packets reported in the message for a period of time. A missing packets reported in the message for a certain period of time.
receiver may still have sent a Feedback message according to the RTP/ A receiver may still have sent a Feedback message according to the
AVPF scheduling algorithm of [RFC4585]before receiving a Third Party RTP/AVPF scheduling algorithm of [RFC4585]before receiving a Third
Loss Report message, but further feedback messages for those sequence Party Loss Report message, but further feedback messages for those
numbers will be suppressed by this technique for a period of time. sequence numbers will be suppressed by this technique for a certain
Nodes that do not understand the Third Party Loss Report message will period of time. Nodes that do not understand the Third Party Loss
ignore it, and might therefore still send feedback according to the Report message will ignore it, and might therefore still send
AVPF scheduling algorithm of [RFC4585]. The media source or feedback according to the AVPF scheduling algorithm of [RFC4585].
intermediate nodes cannot assume that the use of a Third Party Loss The media source or intermediate nodes cannot assume that the use of
Report message actually reduces the amount of feedback it receives. a Third Party Loss 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. However, the third party loss report is defined type as RTCP NACK. However, the Third Party Loss Report is defined
as an indication that the sender of the feedback has received reports as an indication that the sender of the feedback has received reports
that the indicated packets were lost, while NACK [RFC4585] just that the indicated packets were lost, while NACK [RFC4585] just
indicates that the sender of the NACK observed that these packets indicates that the sender of the NACK observed that these packets
were lost. The Third Party Loss Report message is generated by a were lost. The Third Party Loss Report message is generated by a
system that has not seen the actual packet loss. Systems that system that has not seen the actual packet loss. Systems that
receive a third party loss report SHOULD NOT initiate their own receive a Third Party Loss Report SHOULD NOT initiate their own
additional Third Party Loss Report messages for the same packet additional Third Party Loss Report messages for the same packet
sequence numbers. They may either simply forward the Third Party sequence numbers. They may either simply forward the Third Party
Loss Report message, or they may generate their own Third Party Loss Loss Report message, or they may generate their own Third Party Loss
Report that reports a superset of the loss reported in the Third Report that reports a set of the losses they see, which are different
Party Loss report they received. The Third Party Loss Report does from ones reported in the Third Party Loss report they received. The
not have the retransmission request [RFC4588] semantics. 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 this case when if there is no current retransmission suppression. In the case when
the loss was detected and repair initiated much closer to the source, 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 the delay for the receiver to recover from packet loss can be reduced
through the combination of intermediary feedback to the source and through the combination of intermediary feedback to the source and
Third Party Loss Report downstream. 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 Third Party Loss Report together with their repair methods MAY use the Third Party Loss Report together with
existing loss-repair methods either for every packet they expect to their existing loss-repair methods either for every packet they
receive, or for an application-specific subset of the RTP packets in expect to receive, or for an application-specific subset of the RTP
a session. In other words, receivers MAY ignore Third Party Loss packets in a session. In other words, receivers MAY ignore Third
Report messages, but SHOULD react to them unless they have good Party Loss Report messages, but SHOULD react to them unless they have
reason to still send feedback messages despite having been requested good reason to still send feedback messages despite having been
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.
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 a
different media source, identified by its SSRC. different media source, identified by its SSRC.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
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
(SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF)
[RFC4585]. [RFC4585].
The "tplr" feedback value SHOULD be used with parameters that The "tplr" feedback value SHOULD be used with parameters that
indicate the third party loss supported. In this document, we define indicate the third party loss supported. In this document, we define
two such parameter, namely: two such parameter, namely:
o "tllei" denotes support of transport layer third party loss early o "tllei" denotes support of transport layer third party loss early
indication (fsei). indication.
o "pslei" denotes support of payload specific third party loss early o "pslei" denotes support of payload specific third party loss early
indication. indication.
In the ABNF for rtcp-fb-val defined in [RFC4585], there is a In the ABNF for rtcp-fb-val defined in [RFC4585], there is a
placeholder called rtcp-fb-id to define new feedback types. "tplr" is placeholder called rtcp-fb-id to define new feedback types. "tplr" is
defined as a new feedback type in this document, and the ABNF for the defined as a new feedback type in this document, and the ABNF for the
parameters for tplr is defined here (please refer to section 4.2 of parameters for tplr is defined here (please refer to section 4.2 of
[RFC4585] for complete ABNF syntax). [RFC4585] for complete ABNF syntax).
skipping to change at page 8, line 49 skipping to change at page 8, line 49
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 some of the intended use use cases. The following sections outline some of the intended use
cases for using Third Party Loss Report for feedback suppression and cases for using the Third Party Loss Report for feedback suppression
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. Note that each receiver sending multicast
NACK to its group may still need to send unicast NACK addressed to 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 the media source or distribution source for lost packets, this may
storm if feedback suppression is not performed and if the RTCP lead to a NACK storm if feedback suppression is not performed and if
bandwidth limit is misconfigured. 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 may be 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 the Distribution Source Feedback Summary model, since received in the Distribution Source Feedback Summary model, since
this summary feedback does not mandate the forwarding of NACK this summary feedback does not mandate the forwarding of NACK
downstream. downstream.
In order to observe packet loss before the receivers perceive it, one In order to observe packet loss before the receivers perceive it, one
or more intermediate nodes may be placed between the media source and or more intermediate nodes may be placed between the media source and
the receivers. These intermediaries monitor for upstream packet loss the receivers. These intermediaries monitor for upstream packet loss
. These intermediates may be Distribution source, MCUs, RTP . These intermediates may be Distribution source, MCUs, RTP
translator, or RTP mixers, depending on the precise implementation. translator, or RTP mixers, depending on the precise implementation.
If an intermediary notices the loss itself, then it may send a NACK If an intermediary notices the loss itself, then it may send a NACK
both downstream towards the receivers and upstream towards the media both downstream towards the receivers and upstream towards the media
source, to indicate that it has noticed the loss, and to suppress source, to indicate that it has noticed the loss, and to suppress
feedback from other downstream receivers. In the SSM case, If the feedback from other downstream receivers. In the SSM case, If the
distribution source ,using the simple feedback model, receives a NACK distribution source ,using the simple feedback model, receives a NACK
from another system (e.g.,an intermediary), it should redistribute from another system (e.g.,an intermediary), it should redistribute
that NACK to all other systems that would not otherwise receive it. that NACK to all other systems that would not otherwise receive it.
If the distribution source, using the summary feedback model, If the distribution source, using the summary feedback model,
receives a NACK from another system, but, for some reason(e.g., to receives a NACK from another system, but, for some reason(e.g., to
prevent revealing the identity or existence of a system sending prevent revealing the identity or existence of a system sending
NACK), cannot redistribute that NACK, then it may send a third-party 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 Loss Report to the systems that were unable to receive the NACK, and
won't receive the NACK via other means. . Therefore the intermediate won't receive the NACK via other means. Therefore the intermediate
node can be reasonably certain that it will help the situation by node can be reasonably certain that it will help the situation by
sending a Third Party Loss Report message to all the relevant sending a Third Party Loss Report message to all the relevant
receivers, thereby indicating to the receivers that they should not receivers, thereby indicating to the receivers that they should not
transmit feedback messages for a period of time. The intermediate transmit feedback messages for a certain period of time. The
node needs to take into account such factors as the tolerable intermediate node needs to take into account such factors as the
application delay, packet loss recovery techniques, the network tolerable application delay, packet loss recovery techniques, the
dynamics, and the media type. Loss-repair methods such as network dynamics, and the media type. Loss-repair methods such as
retransmission and Forward Error Correction may be used to recover retransmission and Forward Error Correction may be used to recover
the missing packet. the missing packet.
Alternatively, the media source may directly monitor the amount of Alternatively, the media source may directly monitor the amount of
feedback reports it receives from downstream. If the media source feedback reports it receives from downstream. If the media source
notices the loss itself, then it may send a NACK downstream towards notices the loss itself, then it may send a NACK downstream towards
the receivers to suppress feedback. If the media source receives a the receivers to suppress feedback. If the media source receives a
NACK from another system, it should redistribute that NACK to all NACK from another system, it should redistribute that NACK to all
other systems that would not otherwise receive it. If the media other systems that would not otherwise receive it. If the media
source receives a NACK from another system, but, for some reason source receives a NACK from another system, but, for some reason
(e.g., hiding identity or existing a system sending NACK, cannot (e.g., hiding identity or existing a system sending NACK ), cannot
redistribute that NACK, then it may send a third-party loss report to 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 systems that were unable to receive the NACK, and won't receive
the NACK via other means. 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 multicast SSM stream
from the media source. If one of the BRSes receives downstream loss from the media source. If one of the BRSes receives downstream loss
report (i.e., First loss in Figure 3) on its downstream link, but the report (i.e., First loss in Figure 3) on its downstream link, but the
others BRSes have not, as the packet loss took place on the SSM tree others BRSes have not, as the packet loss took place on the SSM tree
branch that does not impact the other BRSes. In such case, the BRSes branch that does not impact the other BRSes. In such case, the BRSes
not being impacted are not aware of downstream loss at their not being impacted are not aware of downstream loss at their
downstream link, therefore these BRSes will not create new Third downstream link, therefore these BRSes will not create a new Third
Party Loss Report message and send it to receivers in their Party Loss Report message and send it to receivers in their
downstream path. If the BRS impacted by packet loss has been told downstream path. If the BRS impacted by packet loss has been told
the actual packet loss, the BRS MAY choose to create new Third Party 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 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 link. Note that BRS must use its own SSRC as packet sender SSRC for
transmitting the feedback suppress message. 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.,
skipping to change at page 12, line 10 skipping to change at page 12, line 10
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 identify packet loss by receiving a NACK In this case the MCU may identify packet loss by receiving a NACK
from another system or may decide to switch to a new source. In both 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 cases the receiver may lose synchronization with the video stream and
may send a FIR request. If the MCU itself can detect the mis- may send a FIR request. If the MCU itself can detect the mis-
synchronization of the video, the MCU can send the FIR suppression synchronization of the video, the MCU can send the FIR suppression
message to the receivers and send a FIR request to the video source. message to the receivers and send a FIR request to the video source.
As suggested in RFC 5117, this topology is better implemented as an As suggested in RFC 5117, this topology is better implemented as an
Topo-mixer, in which case the mixer's SSRC is used as packet sender Topo-Mixer, in which case the mixer's SSRC is used as packet sender
SSRC for transmitting Third Party Loss Report message. SSRC for transmitting the 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 Third Party Loss Report with wrong sequence number of lost Sending the Third Party Loss Report with wrong sequence number of
packet that makes missing RTP packets can not be compensated. 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 Third Party Loss Reports on behalf of the media source can to send the Third Party Loss Reports on behalf of the media source
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 it is authenticated via SRTCP or
similar. Accepting un-authenticated Third Party Loss Report can lead similar. Accepting un-authenticated Third Party Loss Report can lead
to a denial of service attack, where the endpoint accepts poor to a denial of service attack, where the endpoint accepts poor
quality media that could be repaired. quality media that could be repaired.
8. IANA Consideration 8. IANA Consideration
New feedback type and New parameters for RTCP Third Party Loss Report New feedback type and New parameters for RTCP Third Party Loss Report
are subject to IANA registration. For general guidelines on IANA are subject to IANA registration. For general guidelines on IANA
considerations for RTCP feedback, refer to [RFC4585]. considerations for RTCP feedback, refer to [RFC4585].
This document assigns one new feedback type value x in the RTCP This document assigns one new feedback type value in the RTCP
feedback report registry to "Third Party Loss Report" with the feedback report registry to "Third Party Loss Report" with the
following registrations format: following registrations format:
Name: TPLR Name: TPLR
Long Name: Third Party Loss Report Long Name: Third Party Loss Report
Value: TBD Value: TBD
Reference: This document. Reference: This document.
This document also assigns the parameter value y in the RTCP TPLR This document also assigns the parameter value in the RTCP TPLR
feedback report Registry to " Transport Layer Third Party Loss Early feedback report Registry to " Transport Layer Third Party Loss Early
Indication ", with the following registrations format: Indication ", with the following registrations format:
Name: TLLEI Name: TLLEI
Long name: Transport Layer Third Party Loss Early Indication Long name: Transport Layer Third Party Loss Early Indication
Value: TBD Value: TBD
Reference: this document. Reference: this document.
This document also assigns the parameter value z in the RTCP TPLR This document also assigns the parameter value in the RTCP TPLR
feedback report Registry to "Payload Specific Third Party Loss Early feedback report Registry to "Payload Specific Third Party Loss Early
Indication ", with the following registrations format: Indication ", with the following registrations format:
Name: PSLEI Name: PSLEI
Long name: Payload Specific Third Party Loss Early Indication Long name: Payload Specific Third Party Loss Early Indication
Value: TBD Value: TBD
Reference: this document. Reference: this document.
The contact information for the registrations is: The contact information for the registrations is:
skipping to change at page 17, line 20 skipping to change at page 17, line 20
o Revise SSM use case to address multiple DS issue. o Revise SSM use case to address multiple DS issue.
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
The following are the major changes compared to previous version:
o A few Editorial changes to the whole document.
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. 26 change blocks. 
55 lines changed or deleted 63 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/