draft-ietf-avtcore-feedback-supression-rtp-14.txt   draft-ietf-avtcore-feedback-supression-rtp-15.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 3, 2012 Huawei Expires: September 10, 2012 Huawei
March 2, 2012 March 9, 2012
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-14 draft-ietf-avtcore-feedback-supression-rtp-15
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 3, 2012. This Internet-Draft will expire on September 10, 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 3, line 5 skipping to change at page 3, line 5
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 . . . . . . 17
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 . . . . . . 18
A.15. draft-ietf-avtcore-feedback-suppression-rtp-15 . . . . . . 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 39 skipping to change at page 4, line 39
an implosion of FIR requests from receivers to the same media source. an 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. 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 for a feedback for a particular packet or frame loss is not needed and can
period of time and can provide an early indication before the provide an early indication before the receiver reacts to the loss
receiver reacts to the loss and invokes its packet loss repair and invokes its packet loss repair machinery. Section 6 provides
machinery. Section 6 provides some examples of when to send the some examples of when to send the Third Party Loss Report message.
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 - 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 RAMS - Unicast based Rapid Acquisition of Multicast Stream [RFC6285]
[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/
skipping to change at page 6, line 6 skipping to change at page 6, line 4
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 RFC 4585 if the message is integrity for NACK suppression in RFC4585 [RFC4585]and refrain from sending a
protected and authenticated and refrain from sending a feedback feedback request (e.g., NACK or FIR) for the missing packets reported
request (e.g., NACK or FIR) for the missing packets reported in the in the message,which is dealt with in the same way as receiving NACK.
message,which is dealt with in the same way as receiving NACK.
To increase the robustness to the loss of a TPLR, The RTCP TPLR may To increase the robustness to the loss of a TPLR, The RTCP TPLR may
be retransmitted. If the additional TPLR arrives at receiver, the be retransmitted. If the additional TPLR arrives at receiver, the
receiver SHOULD deal with the additional TPLR in the same way as receiver SHOULD deal with the additional TPLR in the same way as
receiving the first TPLR for the same packet and no additional receiving the first TPLR for the same packet and no additional
behavior for receiver is required. behavior for receiver is required.
A receiver may have sent a Feedback message according to the RTP/AVPF A receiver may have sent a Feedback message according to the RTP/AVPF
scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP scheduling algorithm of RFC4585 [RFC4585] before receiving a RTCP
TPLR message, but further feedback messages for those sequence TPLR message, but further feedback messages for those sequence
numbers SHOULD be suppressed for a period of time after receiving the numbers SHOULD be suppressed after receiving the RTCP TPLR. Nodes
RTCP TPLR. Nodes that do not understand the RTCP TPLR message will that do not understand the RTCP TPLR message will ignore it, and
ignore it, and might therefore still send feedback according to the might therefore still send feedback according to the AVPF scheduling
AVPF scheduling algorithm of RFC4585 [RFC4585]. The media source or algorithm of RFC4585 [RFC4585]. The media source or intermediate
intermediate nodes cannot be certain that the use of a RTCP TPLR nodes cannot be certain that the use of a RTCP TPLR message actually
message actually reduces the amount of feedback it receives. reduces the amount of feedback it receives.
4. Format of RTCP Feedback Messages 4. Format of RTCP Feedback Messages
This document introduces two new RTCP Feedback messages for Third This document introduces 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 RTCP TPLR together with their existing repair methods MAY use the RTCP TPLR together with their existing
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. In other words, receivers MAY ignore RTCP TPLR messages, session.
but SHOULD react to them unless they have good reason to still send
feedback messages despite having been requested to suppress them.
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
skipping to change at page 12, line 14 skipping to change at page 12, line 14
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 the security is in place to be well-advised to ignore it, unless the security is in place to
authenticate the sender of the Third Party Loss Report. Accepting authenticate the sender of the Third Party Loss Report. Accepting
Third Party Loss Report from un-authenticated sender can lead to a Third Party Loss Report from un-authenticated sender can lead to a
denial of service attack, where the endpoint accepts poor quality denial of service attack, where the endpoint accepts poor quality
media that could be repaired. media that could be repaired.
8. IANA Consideration 8. IANA Consideration
This document instructs IANA to add two values in "ack" and "nack" This document instructs IANA to add two values to the '"ack" and
Attribute Values registry for use with "nack"[RFC4585]: "nack" Attribute Values' sub-registry [RFC4585] of the 'Session
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
skipping to change at page 18, line 23 skipping to change at page 18, line 23
o Revise IANA section to clarify whether to create new registry or o Revise IANA section to clarify whether to create new registry or
add new value to the existing registry. add new value to the existing registry.
o Revise Security section to clarify ill effect of accepting o Revise Security section to clarify ill effect of accepting
unauthenticated messages. unauthenticated messages.
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
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. 11 change blocks. 
37 lines changed or deleted 40 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/