draft-ietf-avtcore-feedback-supression-rtp-08.txt   draft-ietf-avtcore-feedback-supression-rtp-09.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: April 27, 2012 Huawei Expires: June 1, 2012 Huawei
October 25, 2011 November 29, 2011
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-08 draft-ietf-avtcore-feedback-supression-rtp-09
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 April 27, 2012. This Internet-Draft will expire on June 1, 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 2, line 18 skipping to change at page 2, line 18
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 5 4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 5
4.1. Transport Layer Feedback: Third-party Loss Report . . . . 6 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 5
4.2. Payload Specific Feedback: Third-party Loss Report . . . . 7 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 6
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8 6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 8 6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 8
6.2. Unicast based Rapid Acquisition of Multicast Stream 6.2. Unicast based Rapid Acquisition of Multicast Stream
(RAMS) use case . . . . . . . . . . . . . . . . . . . . . 9 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 9
6.3. RTP Transport Translator use case . . . . . . . . . . . . 9 6.3. RTP Transport Translator use case . . . . . . . . . . . . 9
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 10 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 9
6.5. Mixer use case . . . . . . . . . . . . . . . . . . . . . . 10 6.5. Mixer use case . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 14 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 13
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 . . . . . . 14 A.3. draft-ietf-avtcore-feedback-suppression-rtp-03 . . . . . . 14
A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 15 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 14
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 . . . . . . 15 A.6. draft-ietf-avtcore-feedback-suppression-rtp-06 . . . . . . 15
A.7. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 16 A.7. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 15
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 . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RTCP feedback messages [RFC4585] allow the receivers in an RTP RTCP feedback messages [RFC4585] allow the receivers in an RTP
session to report events and ask for action from the media source (or session to report events and ask for action from the media source (or
a delegated feedback target when using unicast RTCP feedback with SSM a delegated feedback target when using unicast RTCP feedback with SSM
[RFC5760]). There are cases where multiple receivers may initiate [RFC5760]). There are cases where multiple receivers may initiate
the same, or an equivalent message towards the same media source. the same, or an equivalent message towards the same media source.
When the receiver count is large, this behavior may cause transient When the receiver count is large, this behavior may cause transient
skipping to change at page 4, line 42 skipping to change at page 4, line 42
receive a Third Party Loss Report SHOULD NOT send their own receive a Third Party Loss Report 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 Third Party Loss sequence numbers. They should simply forward the Third Party Loss
Report message received from upstream direction, additionally, they Report message received from upstream direction, additionally, they
may generate their own Third Party Loss Report that reports a set of may generate their own Third Party Loss Report that reports a set of
the losses they see, which are different from ones reported in the the losses they see, which are different from ones reported in the
Third Party Loss report they received. The Third Party Loss Report Third Party Loss report they received. The Third Party Loss Report
does not have the retransmission request [RFC4588] semantics. does not have the retransmission request [RFC4588] semantics.
When a receiver gets a Third Party Loss Report message, it should When a receiver gets a Third Party Loss Report message, it should
start a timer for the retransmitted data packet and this message and follow the rules for NACK suppression in RFC 4585 and refrain from
refrain from sending a feedback request (e.g., NACK or FIR) for the sending a feedback request (e.g., NACK or FIR) for the missing
missing packets reported in the message during the lifetime of the packets reported in the message,which is dealt with in the same way
timer. If the sender of retransmitted packet is the media source, as receiving NACK.
the timer value shall be based on the observed time difference
between the round-trip time from the receiver to the original media
source and the round-trip time from the receiver to the sender of the
TPLR. A receiver should compute an estimate of the round-trip time
(RTT) to the original media source or the sender of retransmitted
data packet from Sender Report (SR) packets for the original stream,
or any other means. The round-trip time from the receiver to the
sender of the TPLR can be calculated from RTCP report round-trip time
if available, or any other means.
To increase the robustness to the loss of a TPLR or of a transmission To increase the robustness to the loss of a TPLR or of a transmission
RTP data packet, TPLR for the same Packet may be generated and sent RTP data packet, TPLR or the RTP packet for the same missing Packet
out. The receiver should view the TPLR as a retransmission if this may be retransmitted when RTP systems are aware that the same packet
TPLR is received from the same media source after the timer set loss occurs again. If the additional TPLR arrives at receiver, the
previously expires. In the case where the first TPLR is lost and the receiver should deal with the additional TPLR in the same way as
additional TPLR arrives at the receiver, the receiver should receiving the first TPLR for the same packet and no additional
immediately refresh the timer to the same value as the previous timer behavior for receiver is required. When the retransmitted packet is
it set for the the retransmitted data packet. When the timer expires received by the receiver,it should take its normal behavior as if
and there is no retransmitted packet or a new Third Party Loss Report there is no current feedback suppression.
message, the receiver should take its normal behavior as if there is
no current feedback suppression.
A receiver may still have sent a Feedback message according to the A receiver may still have sent a Feedback message according to the
RTP/AVPF scheduling algorithm of [RFC4585] before receiving a Third RTP/AVPF scheduling algorithm of [RFC4585] before receiving a Third
Party Loss Report message, but further feedback messages for those Party Loss Report message, but further feedback messages for those
sequence numbers SHOULD be suppressed for a period of time after sequence numbers SHOULD be suppressed for a period of time after
receiving the TPLR. Nodes that do not understand the Third Party receiving the TPLR. Nodes that do not understand the Third Party
Loss Report message will ignore it, and might therefore still send Loss Report message will ignore it, and might therefore still send
feedback according to the AVPF scheduling algorithm of [RFC4585]. feedback according to the AVPF scheduling algorithm of [RFC4585].
The media source or intermediate nodes cannot be certain that the use The media source or intermediate nodes cannot be certain that the use
of a Third Party Loss Report message actually reduces the amount of of a Third Party Loss Report message actually reduces the amount of
skipping to change at page 16, line 36 skipping to change at page 16, line 22
section 3. section 3.
o Editorial changes to the Introduction, Protocol Overview, SDP o Editorial changes to the Introduction, Protocol Overview, SDP
Signaling, Message Format, Use case,Security Consideration and Signaling, Message Format, Use case,Security Consideration and
IANA sections. IANA sections.
o Remove Seq Nr field in the figure 2 for payload specific feedback. o Remove Seq Nr field in the figure 2 for payload specific feedback.
o References reorganizing. o References reorganizing.
A.9. draft-ietf-avtcore-feedback-suppression-rtp-09
The following are the major changes compared to previous version:
o Clarify to suppression interval with regard to how long to receive
the retransmitted packet. Treating TPLR in the same way as
receiving NACK .Replace timer based approach with timeless based
approach
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
Frank Xia Frank Xia
Huawei Huawei
1700 Alma Dr. Suite 500 1700 Alma Dr. Suite 500
Plano, TX 75075 Plano, TX 75075
USA USA
Phone: +1 972-509-5599 Phone: +1 972-509-5599
Email: xiayangsong@huawei.com Email: xiayangsong@huawei.com
Roni Even Roni Even
Huawei Huawei
14 David Hamelech 14 David Hamelech
Tel Aviv 64953 Tel Aviv 64953
Israel Israel
Email: even.roni@huawei.com Email: even.roni@huawei.com
 End of changes. 16 change blocks. 
36 lines changed or deleted 35 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/