draft-ietf-avtcore-feedback-supression-rtp-10.txt   draft-ietf-avtcore-feedback-supression-rtp-11.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: August 9, 2012 Huawei Expires: August 13, 2012 Huawei
February 6, 2012 February 10, 2012
RTCP Extension for Third-party Loss Report RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-10 draft-ietf-avtcore-feedback-supression-rtp-11
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 August 9, 2012. This Internet-Draft will expire on August 13, 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 45 skipping to change at page 2, line 45
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 13 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 13
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 13 A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 13
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 . . . . . . 14 A.4. draft-ietf-avtcore-feedback-suppression-rtp-04 . . . . . . 14
A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 14 A.5. draft-ietf-avtcore-feedback-suppression-rtp-05 . . . . . . 14
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 . . . . . . 15 A.7. draft-ietf-avtcore-feedback-suppression-rtp-07 . . . . . . 15
A.8. draft-ietf-avtcore-feedback-suppression-rtp-08 . . . . . . 15 A.8. draft-ietf-avtcore-feedback-suppression-rtp-08 . . . . . . 15
A.9. draft-ietf-avtcore-feedback-suppression-rtp-09 . . . . . . 16 A.9. draft-ietf-avtcore-feedback-suppression-rtp-09 . . . . . . 16
A.10. draft-ietf-avtcore-feedback-suppression-rtp-10 . . . . . . 16 A.10. draft-ietf-avtcore-feedback-suppression-rtp-10 . . . . . . 16
A.11. draft-ietf-avtcore-feedback-suppression-rtp-11 . . . . . . 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 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 24 skipping to change at page 4, line 24
referred to as Distribution source, Burst/Retransmission Sources referred to as Distribution source, Burst/Retransmission Sources
(BRS), MCUs, RTP translator, or RTP mixers, depending on the precise (BRS), MCUs, RTP translator, or RTP mixers, depending on the precise
use case described in section 6. use case described in section 6.
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 or Full Intra Request Command. However, the Third type as RTCP NACK or Full Intra Request Command. However, the Third
Party Loss Report is defined as an indication that the sender of the Party Loss Report is defined as an indication that the sender of the
feedback has received reports that the indicated packets were lost, feedback has received reports that the indicated packets were lost,
while NACK [RFC4585] just indicates that the sender of the NACK while NACK [RFC4585] just indicates that the sender of the NACK
observed that these packets were lost. The Third Party Loss Report observed that these packets were lost. The Third Party Loss Report
(TPLR) message is generated by a intermediary that may not seen the (TPLR) message is generated by an intermediary that may not seen the
actual packet loss. It is sent following the same timing rule as actual packet loss. It is sent following the same timing rule as
sending NACK defined in [RFC4585]. The TPLR feedback message may be sending NACK defined in [RFC4585]. The TPLR feedback message may be
sent in a regular full compound RTCP packet or in an early RTCP sent in a regular full compound RTCP packet or in an early RTCP
packet, as per the RTP/AVPF rules. Intermediaries in the network packet, as per the RTP/AVPF rules. Intermediaries in the network
that receive a Third Party Loss Report SHOULD NOT send their own that 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 to the receiver(s), Report message received from upstream direction to the receiver(s),
additionally, they may generate their own Third Party Loss Report additionally, they may generate their own Third Party Loss Report
that reports a set of the losses they see, which are different from that reports a set of the losses they see, which are different from
skipping to change at page 4, line 51 skipping to change at page 4, line 51
sending a feedback request (e.g., NACK or FIR) for the missing sending a feedback request (e.g., NACK or FIR) for the missing
packets reported in the message,which is dealt with in the same way packets reported in the message,which is dealt with in the same way
as receiving NACK. as receiving NACK.
To increase the robustness to the loss of a TPLR, TPLR may be To increase the robustness to the loss of a TPLR, TPLR may be
retransmitted. If the additional TPLR arrives at receiver, the 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 still have sent a Feedback message according to the A receiver may have sent a Feedback message according to the RTP/AVPF
RTP/AVPF scheduling algorithm of [RFC4585] before receiving a Third scheduling algorithm of [RFC4585] before receiving a Third Party Loss
Party Loss Report message, but further feedback messages for those Report message, but further feedback messages for those sequence
sequence numbers SHOULD be suppressed for a period of time after numbers SHOULD be suppressed for a period of time after receiving the
receiving the TPLR. Nodes that do not understand the Third Party TPLR. Nodes that do not understand the Third Party Loss Report
Loss Report message will ignore it, and might therefore still send message will ignore it, and might therefore still send feedback
feedback according to the AVPF scheduling algorithm of [RFC4585]. according to the AVPF scheduling algorithm of [RFC4585]. The media
The media source or intermediate nodes cannot be certain that the use source or intermediate nodes cannot be certain that the use of a
of a Third Party Loss Report message actually reduces the amount of Third Party Loss Report message actually reduces the amount of
feedback it receives. feedback it receives.
4. Format of RTCP Feedback Messages 4. Format of RTCP Feedback Messages
This document registers two new RTCP Feedback messages for Third This document registers two new RTCP Feedback messages for Third
Party Loss Report. Applications that are employing one or more loss- Party Loss Report. Applications that are employing one or more loss-
repair methods MAY use the Third Party Loss Report together with repair methods MAY use the Third Party Loss Report together with
their existing loss-repair methods either for every packet they their existing loss-repair methods either for every packet they
expect to receive, or for an application-specific subset of the RTP expect to receive, or for an application-specific subset of the RTP
packets in a session. In other words, receivers MAY ignore Third packets in a session. In other words, receivers MAY ignore Third
skipping to change at page 6, line 18 skipping to change at page 6, line 18
| PID | BLP | | PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Syntax of an FCI Entry in the TLLEI Feedback Message Figure 1: Syntax of an FCI Entry in the TLLEI Feedback Message
Packet ID (PID): 16 bits Packet ID (PID): 16 bits
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 proceeding 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 4.2. Payload Specific Feedback: Third-party Loss Report
This message is an extension to the RTCP Payload Specific Feedback This message is an extension to the RTCP Payload Specific Feedback
report and identified by RTCP packet type value PT=PSFB and FMT=TBD, report and identified by RTCP packet type value PT=PSFB and FMT=TBD,
skipping to change at page 16, line 24 skipping to change at page 16, line 24
A.10. draft-ietf-avtcore-feedback-suppression-rtp-10 A.10. draft-ietf-avtcore-feedback-suppression-rtp-10
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Fix the definition of Synchronization source for TPLR in section o Fix the definition of Synchronization source for TPLR in section
4.2. 4.2.
o Associate SDP parameters tllei and pslei with "nack". o Associate SDP parameters tllei and pslei with "nack".
o Remove the packet loss recovery from TPLR loss handling part. o Remove the packet loss recovery from TPLR loss handling part.
o Other typo fixed. o Other typo fixed.
A.11. draft-ietf-avtcore-feedback-suppression-rtp-11
The following are the major changes compared to previous version:
o Additional 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. 8 change blocks. 
15 lines changed or deleted 22 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/