draft-ietf-avtcore-feedback-supression-rtp-15.txt   draft-ietf-avtcore-feedback-supression-rtp-16.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: September 10, 2012 Huawei Expires: October 1, 2012 Huawei
March 9, 2012 March 30, 2012
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-15 draft-ietf-avtcore-feedback-supression-rtp-16
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 September 10, 2012. This Internet-Draft will expire on October 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 19 skipping to change at page 2, line 19
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 6 4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 6
4.1. Transport Layer Feedback: Third Party Loss Report 4.1. Transport Layer Feedback: Third-Party Loss Report
(TPLR) . . . . . . . . . . . . . . . . . . . . . . . . . . 6 (TPLR) . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Payload Specific Feedback: Third Party Loss Report 4.2. Payload Specific Feedback: Third-Party Loss Report
(TPLR) . . . . . . . . . . . . . . . . . . . . . . . . . . 7 (TPLR) . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 9
6.2. Unicast based Rapid Acquisition of Multicast Stream 6.2. Unicast based Rapid Acquisition of Multicast Stream
(RAMS) use case . . . . . . . . . . . . . . . . . . . . . 10 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 10
6.3. RTP Transport Translator use case . . . . . . . . . . . . 10 6.3. RTP Transport Translator use case . . . . . . . . . . . . 10
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 10 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 10
6.5. Mixer use case . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Mixer use case . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 14 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 14
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 14 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 14
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 15 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 15
A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 15 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 15
A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 15 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 15
A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 16 A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 16
A.7. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 16 A.7. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 16
A.8. draft-ietf-avtcore-feedback-suppression-rtp-08 . . . . . . 16 A.8. draft-ietf-avtcore-feedback-suppression-rtp-08 . . . . . . 16
A.9. draft-ietf-avtcore-feedback-suppression-rtp-09 . . . . . . 17 A.9. draft-ietf-avtcore-feedback-suppression-rtp-09 . . . . . . 16
A.10. draft-ietf-avtcore-feedback-suppression-rtp-10 . . . . . . 17 A.10. draft-ietf-avtcore-feedback-suppression-rtp-10 . . . . . . 17
A.11. draft-ietf-avtcore-feedback-suppression-rtp-11 . . . . . . 17 A.11. draft-ietf-avtcore-feedback-suppression-rtp-11 . . . . . . 17
A.12. draft-ietf-avtcore-feedback-suppression-rtp-12 . . . . . . 17 A.12. draft-ietf-avtcore-feedback-suppression-rtp-12 . . . . . . 17
A.13. draft-ietf-avtcore-feedback-suppression-rtp-13 . . . . . . 17 A.13. draft-ietf-avtcore-feedback-suppression-rtp-13 . . . . . . 17
A.14. draft-ietf-avtcore-feedback-suppression-rtp-14 . . . . . . 18 A.14. draft-ietf-avtcore-feedback-suppression-rtp-14 . . . . . . 17
A.15. draft-ietf-avtcore-feedback-suppression-rtp-15 . . . . . . 18 A.15. draft-ietf-avtcore-feedback-suppression-rtp-15 . . . . . . 18
A.16. draft-ietf-avtcore-feedback-suppression-rtp-16 . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
RTCP feedback messages [RFC4585] allow the receivers in an RTP RTCP feedback messages [RFC4585] allow the receivers in an RTP
session to report events and ask for action from the media source (or session to report events and ask for action from the media source (or
a delegated feedback target 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 or the same, or an equivalent message towards the same media source or
the same feedback target. When the receiver count is large, this the same feedback target. When the receiver count is large, this
skipping to change at page 4, line 42 skipping to change at page 4, line 42
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. This document specifies a new third-party loss report for feedback. This document specifies a new third-party loss report for
this function. It supplements the existing the use of RTCP NACK this function. It supplements the existing the use of RTCP NACK
packet and further is more precise in the uses where the network is packet and further is more precise in the uses where the network is
active to suppress feedback. It tells receivers explicitly that active to suppress feedback. It tells receivers explicitly that
feedback for a particular packet or frame loss is not needed and can feedback for a particular packet or frame loss is not needed and can
provide an early indication before the receiver reacts to the loss provide an early indication before the receiver reacts to the loss
and invokes its packet loss repair machinery. Section 6 provides and invokes its packet loss repair machinery. Section 6 provides
some examples of when to send the Third Party Loss Report message. some examples of when to send the Third-Party Loss Report message.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "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 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
2.1. Glossary 2.1. Glossary
TPLR - Third Party Loss Report TPLR - Third-Party Loss Report
TLLEI - Transport layer third party loss Early Indication TLLEI - Transport Layer Third-Party Loss Early Indication
PSLEI - Third Party Loss Early Indication PSLEI - Payload Specific Third-Party Loss Early Indication
FCI - Feedback Control Information [RFC4585] FCI - Feedback Control Information [RFC4585]
AVPF - The Audio-Visual Profile with RTCP-based feedback [RFC4585] AVPF - The Audio-Visual Profile with RTCP-based feedback [RFC4585]
SSRC - Synchronization Source SSRC - Synchronization Source
BRS - Burst/Retransmission Sources [RFC6285] BRS - Burst/Retransmission Sources [RFC6285]
FIR - Full Intra Request [RFC5104] FIR - Full Intra Request [RFC5104]
PLI - Picture Loss Indication [RFC4585] PLI - Picture Loss Indication [RFC4585]
SSM - Source Specific Multicast [RFC5760] SSM - Source Specific Multicast [RFC5760]
RAMS - Unicast based Rapid Acquisition of Multicast Stream [RFC6285] RAMS - Unicast based Rapid Acquisition of Multicast Stream [RFC6285]
MCU - Multipoint Control Unit [RFC5117] MCU - Multipoint Control Unit [RFC5117]
3. Protocol Overview 3. Protocol Overview
This document extends the RTCP feedback messages defined in the RTP/ This document extends the RTCP feedback messages defined in the RTP/
AVPF [RFC4585] defining a RTCP Third Party Loss Report (TPLR) AVPF [RFC4585] defining a RTCP Third-Party Loss Report (TPLR)
message. The RTCP TPLR message can be used by the intermediaries to message. The RTCP TPLR message can be used by the intermediaries to
inform the receiver that the sender of the RTCP TPLR has received inform the receiver that the sender of the RTCP TPLR 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. Intermediaries not to send feedback to it regarding these packets. Intermediaries
are variously referred to as Distribution source, Burst/ are variously referred to as Distribution source, Burst/
Retransmission Sources (BRS), MCUs, RTP translator, or RTP mixers, Retransmission Sources (BRS), MCUs, RTP translator, or RTP mixers,
depending on the precise use case described Section 6. depending on the precise use case described Section 6.
RTCP TPLR follows the similar format of message type as RTCP NACK or RTCP TPLR follows the similar format of message type as RTCP NACK or
Full Intra Request Command. However, the RTCP TPLR is defined as an Full Intra Request Command. However, the RTCP TPLR is defined as an
indication that the sender of the feedback has received reports that indication that the sender of the feedback has received reports that
the indicated packets were lost, while NACK [RFC4585] just indicates the indicated packets were lost, while NACK [RFC4585] just indicates
that the sender of the NACK observed that these packets were lost. that the sender of the NACK observed that these packets were lost.
The RTCP TPLR message is generated by an intermediary that may not The RTCP TPLR message is generated by an intermediary that may not
have seen the actual packet loss. It is sent following the same have seen the actual packet loss. It is sent following the same
timing rule as sending NACK defined in RFC4585 [RFC4585]. The RTCP timing rule as sending NACK defined in RFC4585 [RFC4585]. The RTCP
TPLR message may be sent in a regular full compound RTCP packet or in TPLR message may be sent in a regular full compound RTCP packet or in
an early RTCP packet, as per the RTP/AVPF rules. Intermediaries in an early RTCP packet, as per the RTP/AVPF rules. Intermediaries in
the network that receive a RTCP TPLR SHOULD NOT send their own the network that receive a RTCP TPLR SHOULD NOT send 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 SHOULD simply forward the RTCP TPLR message sequence numbers. They SHOULD simply forward the RTCP TPLR message
received from upstream direction to the receiver(s), additionally, received from upstream direction to the receiver(s), additionally,
they may generate their own RTCP TPLR that reports a set of the they may generate their own RTCP TPLR that reports a set of the
losses they see, which are different from ones reported in the RTCP losses they see, which are different from ones reported in the RTCP
TPLR they received. The RTCP TPLR does not have the retransmission TPLR they received. The RTCP TPLR does not have the retransmission
request [RFC4588] semantics. request [RFC4588] semantics.
When a receiver gets a RTCP TPLR message, it MUST follow the rules When a receiver gets a RTCP TPLR message, it MUST follow the rules
for NACK suppression in RFC4585 [RFC4585]and refrain from sending a for NACK suppression in RFC4585 [RFC4585]and refrain from sending a
feedback request (e.g., NACK or FIR) for the missing packets reported feedback request (e.g., NACK or FIR) for the missing packets reported
skipping to change at page 6, line 39 skipping to change at page 6, line 39
loss-repair methods either for every packet they expect to receive, loss-repair methods either for every packet they expect to receive,
or for an application-specific subset of the RTP packets in a or for an application-specific subset of the RTP packets in a
session. session.
The following two sections each define a RTCP TPLR message. Both The following two sections each define a RTCP TPLR message. Both
messages are feedback messages as defined in section 6.1 of RFC4585 messages are feedback messages as defined in section 6.1 of RFC4585
[RFC4585], and use the header format defined there. Each section [RFC4585], and use the header format defined there. Each section
defines how to populate the PT, FMT,length SSRC of packet sender, defines how to populate the PT, FMT,length SSRC of packet sender,
SSRC of media source, and FCI fields in that header. SSRC of media source, and FCI fields in that header.
4.1. Transport Layer Feedback: Third Party Loss Report (TPLR) 4.1. Transport Layer Feedback: Third-Party Loss Report (TPLR)
This TPLR message is identified by RTCP packet type value PT=RTPFB This TPLR message is identified by RTCP packet type value PT=RTPFB
and FMT=TBA1. and FMT=TBA1.
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined in
section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source" indicates the source of the request, and the "SSRC of media source"
denotes the media sender of the flow for which the indicated losses denotes the media sender of the flow for which the indicated losses
are being suppressed. are being suppressed.
The Feedback Control Information (FCI) field MUST contain one or more The Feedback Control Information (FCI) field MUST contain one or more
entries of transport layer third party loss Early Indication (TLLEI). entries of transport layer third-party loss Early Indication (TLLEI).
Each entry applies to the same media source identified by the SSRC Each entry applies to the same media source identified by the SSRC
contained in the SSRC of media source field of Feedback header. The contained in the SSRC of media source field of Feedback header. The
length field in the TLLEI feedback message MUST be set to 2+1*N, length field in the TLLEI feedback message MUST be set to 2+1*N,
where N is the number of FCI entries. where N is the number of FCI entries.
The FCI field for TLLEI uses the similar format of message Types The FCI field for TLLEI uses the similar format of message Types
defined in the section 6.2.1 of RFC4585 [RFC4585]. The format is defined in the section 6.2.1 of RFC4585 [RFC4585]. The format is
shown in Figure 1. shown in Figure 1.
0 1 2 3 0 1 2 3
skipping to change at page 7, line 34 skipping to change at page 7, line 34
The PID field is used to specify a lost packet. The PID field The PID field is used to specify a lost packet. The PID field
refers to the RTP sequence number of the lost packet. refers to the RTP sequence number of the lost packet.
bitmask of lost packets (BLP): 16 bits bitmask of 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 the section 6.2.1 BLP's definition is identical to that given in the section 6.2.1
of [RFC4585]. of [RFC4585].
4.2. Payload Specific Feedback: Third Party Loss Report (TPLR) 4.2. Payload Specific Feedback: Third-Party Loss Report (TPLR)
This TPLR message is identified by RTCP packet type value PT=PSFB and This TPLR message is identified by RTCP packet type value PT=PSFB and
FMT=TBA2, which is used to suppress FIR [RFC5104] and PLI [RFC4585]. FMT=TBA2, which is used to suppress FIR [RFC5104] and PLI [RFC4585].
Within the common packet header for feedback messages (as defined in Within the common packet header for feedback messages (as defined in
section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field section 6.1 of RFC4585 [RFC4585]), the "SSRC of packet sender" field
indicates the source of the request, and the "SSRC of media source" 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 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. which this message applies are in the corresponding FCI entries.
The FCI field for a Payload Specific Third Party Loss Early The FCI field for a Payload Specific Third-Party Loss Early
Indication (PSLEI) consists one or more FCI entries. Each entry Indication (PSLEI) consists one or more FCI entries. Each entry
applies to a different media Source, identified by its SSRC. the applies to a different media Source, identified by its SSRC. the
content of which is depicted in Figure 2. The length field in the content of which is depicted in Figure 2. The length field in the
PSLEI feedback message MUST be set to 2+1*N, where N is the number of PSLEI feedback message MUST be set to 2+1*N, where N is the number of
FCI entries. FCI entries.
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
skipping to change at page 8, line 29 skipping to change at page 8, line 29
synchronization with the media stream and for which the PSLEI synchronization with the media stream and for which the PSLEI
receiver's own response to any such error is suppressed. receiver's own response to any such error is suppressed.
5. SDP Signaling 5. SDP Signaling
The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb, The Session Description Protocol (SDP) [RFC4566] attribute, rtcp-fb,
is defined in the Section 4 of RFC4585 [RFC4585] and may be used to is defined in the Section 4 of RFC4585 [RFC4585] and may be used to
negotiate the capability to handle specific AVPF commands and negotiate the capability to handle specific AVPF commands and
indications. The ABNF for rtcp-fb is described in section 4.2 of indications. The ABNF for rtcp-fb is described in section 4.2 of
RFC4585 [RFC4585]. In this section, we extend the rtcp-fb attribute RFC4585 [RFC4585]. In this section, we extend the rtcp-fb attribute
to include the commands and indications that are described for third to include the commands and indications that are described for third-
party loss report in the present document. party loss report in the present document.
In the ABNF [RFC5234] for rtcp-fb-val defined in RFC4585 [RFC4585], In the ABNF [RFC5234] for rtcp-fb-val defined in RFC4585 [RFC4585],
the feedback type "nack", without parameters, indicates use of the the feedback type "nack", without parameters, indicates use of the
Generic NACK feedback format as defined in Section 6.2.1of RFC4585 Generic NACK feedback format as defined in Section 6.2.1of RFC4585
[RFC4585]. In this document, we define two parameters that indicate [RFC4585]. In this document, we define two parameters that indicate
the third party loss supported for use with "nack", namely: the third-party loss supported for use with "nack", namely:
o "tllei" denotes support of transport layer third party loss early o "tllei" denotes support of transport layer third-party loss early
indication. 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.
The ABNF for these two parameters for "nack" is defined here (please The ABNF for these two parameters for "nack" is defined here (please
refer to section 4.2 of RFC4585 [RFC4585] for complete ABNF syntax). refer to section 4.2 of RFC4585 [RFC4585] for complete ABNF syntax).
rtcp-fb-val =/ "nack" rtcp-fb-nack-param rtcp-fb-val =/ "nack" rtcp-fb-nack-param
rtcp-fb-nack-param = SP "tllei" rtcp-fb-nack-param = SP "tllei"
;transport layer third party ;transport layer third party
; loss early indication ; loss early indication
/ SP "pslei" / SP "pslei"
skipping to change at page 9, line 26 skipping to change at page 9, line 26
Refer to Section 4.2 of RFC4585 [RFC4585] for a detailed description Refer to Section 4.2 of RFC4585 [RFC4585] for a detailed description
and the full syntax of the "rtcp-fb" attribute. and the 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 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 "RTP Control Protocol (RTCP) In SSM RTP sessions as described in "RTP Control Protocol (RTCP)
Extensions for Single-Source Multicast Sessions with Unicast Extensions for Single-Source Multicast Sessions with Unicast
Feedback" [RFC5760], one or more Media Sources send RTP packets to a Feedback" [RFC5760], one or more Media Sources send RTP packets to a
Distribution Source. The Distribution Source relays the RTP packets Distribution Source. The Distribution Source relays the RTP packets
to the receivers using a source- specific multicast group. to the receivers using a source- specific multicast group.
skipping to change at page 11, line 23 skipping to change at page 11, line 23
received video. If so the mixer may initiate FIR or PLI towards the received video. If so the mixer may initiate FIR or PLI towards the
media source on behalf of all the session participants and send out a media source on behalf of all the session participants and send out a
RTCP TPLR message to these session participants that may or are RTCP TPLR message to these session participants that may or are
expected to send a PLI or FIR. Alternatively, when the mixer starts expected to send a PLI or FIR. Alternatively, when the mixer starts
to receive FIR or PLI from some participants and like to suppress the to receive FIR or PLI from some participants and like to suppress the
remaining session participants from sending FIR or PLI by forwarding remaining session participants from sending FIR or PLI by forwarding
the FIR/PLI from one session participant to others. the FIR/PLI from one session participant to others.
7. Security Considerations 7. Security Considerations
The defined messages have certain properties that have security The security considerations documented in [RFC4585] are also
implications. These must be addressed and taken into account by applicable for the TPLR messages defined in this document.
users of this protocol.
Spoofed or maliciously created feedback messages of the type defined
in this specification can have the following implications:
Sending the spurious Third Party Loss Report packet(e.g., the RTCP More specifically, spoofed or maliciously created TPLR feedback
TPLR with the wrong sequence number of lost packet) that causes messages cause missing RTP packets to not be repaired in a timely
missing RTP packets to not be repaired in a timely fashion. If a fashion and add risk of (undesired) feedback supression at RTCP
receiver accepts such unauthenticated packet, an attacker could cause receivers that accept such TPLR messages. Any packet loss detected
packet loss disrupting an important part of a session, preemptively by a receiver and where this RTP receiver also receives a TPLR
sending feedback suppression. An attacker that is also a receiver message for the same missing packet(s), will negatively impact the
has enough information to suppress all the feedbacks from any other application that relies on the (timely) RTP retransmission
listeners that don't accept unauthenticated packets. capabilities.
To prevent these attacks, there is a need to apply authentication and A solution to prevent such attack with maliciously sent TPLR
integrity protection of the feedback messages. This can be messages, is to apply an authentication and integrity protection
accomplished against threats external to the current RTP session framework for the feedback messages. This can be accomplished using
using the RTP profile that combines Secure RTP [RFC3711] and AVPF the RTP profile that combines Secure RTP [RFC3711] and AVPF into
into SAVPF [RFC5124]. SAVPF [RFC5124].
Note that intermediaries that are not visible at the RTP layer that Note that intermediaries that are not visible at the RTP layer that
wish to send the Third Party Loss Reports on behalf of the media wish 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. source can only do so if they spoof the SSRC of the media source.
This is difficult in case SRTP is in use. If the intermediary is This is difficult in case SRTP is in use. If the intermediary is
visible at the RTP layer, this is not an issue, provided the visible at the RTP layer, this is not an issue, provided the
intermediary is part of the security context for the session. intermediary is part of the security context for the session.
Also note that endpoints that receive a Third Party Loss Report would
be well-advised to ignore it, unless the security is in place to
authenticate the sender of the Third Party Loss Report. Accepting
Third Party Loss Report from un-authenticated sender can lead to a
denial of service attack, where the endpoint accepts poor quality
media that could be repaired.
8. IANA Consideration 8. IANA Consideration
This document instructs IANA to add two values to the '"ack" and This document instructs IANA to add two values to the '"ack" and
"nack" Attribute Values' sub-registry [RFC4585] of the 'Session "nack" Attribute Values' sub-registry [RFC4585] of the 'Session
Description Protocol (SDP) Parameters' registry. Description Protocol (SDP) Parameters' registry.
The value registration for the attribute value "nack": The value registration for the attribute value "nack":
Value name: tllei Value name: tllei
Long name: Transport Layer Third Party Loss Early Indication Long name: Transport Layer Third-Party Loss Early Indication
Usable with: nack Usable with: nack
Reference: RFC 4585. Reference: RFC 4585.
Value name: pslei Value name: pslei
Long name: Payload Specific Third Party Long name: Payload Specific Third-Party Loss Early Indication
Usable with: nack Usable with: nack
Reference: RFC 4585. Reference: RFC 4585.
The following value have been registered as one FMT value in the "FMT The following value have been registered as one FMT value in the "FMT
Values for RTPFB Payload Types" registry located at the time of Values for RTPFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters publication at: http://www.iana.org/assignments/rtp-parameters
RTPFB range RTPFB range
Name Long Name Value Reference Name Long Name Value Reference
-------------- --------------------------------- ----- --------- -------------- --------------------------------- ----- ---------
TLLEI Transport Layer Third Party TBA1 [RFCXXXX] TLLEI Transport Layer Third-Party TBA1 [RFCXXXX]
Loss Early Indication Loss Early Indication
The following value have been registered as one FMT value in the "FMT The following value have been registered as one FMT value in the "FMT
Values for PSFB Payload Types" registry located at the time of Values for PSFB Payload Types" registry located at the time of
publication at: http://www.iana.org/assignments/rtp-parameters publication at: http://www.iana.org/assignments/rtp-parameters
PSFB range PSFB range
Name Long Name Value Reference Name Long Name Value Reference
-------------- --------------------------------- ----- -------- -------------- --------------------------------- ----- --------
PSLEI Payload Specific Third Party TBA2 [RFCXXXX] PSLEI Payload Specific Third-Party TBA2 [RFCXXXX]
Loss Early Indication Loss Early Indication
9. Acknowledgement 9. Acknowledgement
The authors would like to thank David R Oran, Magnus Westerlund, The authors would like to thank David R Oran, Magnus Westerlund,
Colin Perkins, Ali C. Begen, Tom VAN CAENEGEM, Ingemar Johansson S, Colin Perkins, Ali C. Begen, Tom VAN CAENEGEM, Ingemar Johansson S,
Bill Ver Steeg, Jonathan Lennox, WeeSan Lee for their valuable Bill Ver Steeg, Jonathan Lennox, WeeSan Lee for their valuable
comments and suggestions on this document. comments and suggestions on this document.
10. References 10. References
skipping to change at page 14, line 48 skipping to change at page 14, line 38
o Other Editorial changes. o Other Editorial changes.
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o In Section 4.1, fix typo: change Section 4.3.1.1 of section o In Section 4.1, fix typo: change Section 4.3.1.1 of section
[RFC5104] to section 6.2.1 of [RFC4585]. [RFC5104] to section 6.2.1 of [RFC4585].
o In Section 3: Clarify how to deal with downstream loss using Third o In Section 3: Clarify how to deal with downstream loss using
party loss report and upstream loss using NACK. Third-party loss report and upstream loss using NACK.
o Update title and abstract to focus on third party loss report. o Update title and abstract to focus on third-party loss report.
o In Section 6.1: Update this section to explain how third party o In Section 6.1: Update this section to explain how third party
loss report is used to deal with downstream loss. loss report is used to deal with downstream loss.
o In section 6.1.2: Update this section to explain how third party o In section 6.1.2: Update this section to explain how third party
loss report is used to deal with downstream loss. loss report is used to deal with downstream loss.
o In section 6.2: Rephrase the text to discuss how BRS deal with the o In section 6.2: Rephrase the text to discuss how BRS deal with the
third party loss report. third-party loss report.
A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 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. -> Appendix 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.
skipping to change at page 15, line 39 skipping to change at page 15, line 28
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 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Remove 3rd and 4th paragraphs of section 6.1 and replaced them o Remove 3rd and 4th paragraphs of section 6.1 and replaced them
with 2nd and 3rd paragraphs of section 3. with 2nd and 3rd paragraphs of section 3.
o Remove section 6.1.1.1. o Remove section 6.1.1.1.
o Revise the last paragraph of section 1 to clarify the rationale of o Revise the last paragraph of section 1 to clarify the rationale of
using new message. using new message.
o Update RTP transport translator case in section 6.3 to correct the o Update RTP transport translator case in section 6.3 to correct the
use of the third party loss report. use of the third-party loss report.
o Update MCU case in section 6.4 to correct the use of the third o Update MCU case in section 6.4 to correct the use of the third
party loss report. party loss report.
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.
skipping to change at page 18, line 29 skipping to change at page 18, line 18
o Add a glossary to fix acronym issue. o Add a glossary to fix acronym issue.
o Other Editorial changes. o Other Editorial changes.
A.15. draft-ietf-avtcore-feedback-suppression-rtp-15 A.15. draft-ietf-avtcore-feedback-suppression-rtp-15
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Some Editorial changes. o Some Editorial changes.
A.16. draft-ietf-avtcore-feedback-suppression-rtp-16
The following are the major changes compared to previous version:
o Some Editorial changes.
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. 38 change blocks. 
69 lines changed or deleted 65 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/