draft-ietf-avtcore-feedback-supression-rtp-00.txt   draft-ietf-avtcore-feedback-supression-rtp-01.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 19, 2011 Huawei Expires: October 17, 2011 Huawei
February 15, 2011 April 15, 2011
RTCP Extension for Feedback Suppression Indication RTCP Extension for Feedback Suppression Indication
draft-ietf-avtcore-feedback-supression-rtp-00 draft-ietf-avtcore-feedback-supression-rtp-01
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 media source or middlebox may experience transient RFC 4585, a media source or middlebox may experience transient
overload if some event causes a large number of receivers to send overload if some event causes a large number of receivers to send
feedback at once. This feedback implosion can be mitigated if the feedback at once. This feedback implosion can be mitigated if the
device suffering from overload can send a third party loss report device suffering from overload can send a third party loss report
message to the receivers to inhibit further feedback. This memo message to the receivers to inhibit further feedback. This memo
defines RTCP extensions for third party loss report, to suppress NACK defines RTCP extensions for third party loss report, to suppress NACK
and FIR feedback requests. It also defines associated SDP and FIR feedback requests. It also defines associated SDP signaling.
signalling.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 19, 2011. This Internet-Draft will expire on October 17, 2011.
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 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 7 4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 6
4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7 4.1. Transport Layer Feedback: Third-party Loss Report . . . . 7
4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 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.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 10 6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 10
6.1.2. Distribution Source Feedback Summary Model . . . . . . 11 6.1.2. Distribution Source Feedback Summary Model . . . . . . 11
6.2. Unicast based Rapid Acquisition of Multicast Stream 6.2. Unicast based Rapid Acquisition of Multicast Stream
(RAMS) use case . . . . . . . . . . . . . . . . . . . . . 12 (RAMS) use case . . . . . . . . . . . . . . . . . . . . . 11
6.3. RTP transport translator use case . . . . . . . . . . . . 13 6.3. RTP transport translator use case . . . . . . . . . . . . 13
6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13 6.4. Multipoint Control Unit (MCU) use case . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Appendix A. Change Log . . . . . . . . . . . . . . . 16
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16
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 defined in SSM [RFC5760]). There are a delegated feedback target defined in SSM [RFC5760]). There are
cases where multiple receivers may initiate the same, or an cases where multiple receivers may initiate the same, or an
equivalent message towards the same media source. When the receiver equivalent message towards the same media source. When the receiver
count is large, this behavior may cause transient overload of the count is large, this behavior may cause transient overload of the
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Another use case involves video Fast Update requests. A storm of Another use case involves video Fast Update requests. A storm of
these feedback messages can occur in conversational multimedia these feedback messages can occur in conversational multimedia
scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario, scenarios like Topo-Video-switch-MCU [RFC5117]. In this scenario,
packet loss may happen on an upstream link of an intermediate network packet loss may happen on an upstream link of an intermediate network
element such as a Multipoint Control Unit(MCU). Poorly designed element such as a Multipoint Control Unit(MCU). Poorly designed
receivers that blindly issue fast update requests (i.e., Full Intra receivers that blindly issue fast update requests (i.e., Full Intra
Request (FIR) described in [RFC5104]), can cause an implosion of FIR Request (FIR) described in [RFC5104]), can cause an implosion of FIR
requests from receivers to the same media source. requests from receivers to the same media source.
RTCP feedback storms may cause short term overload and, and in RTCP feedback storms may cause short term overload, and in extreme
extreme cases to pose a possible risk of increasing network cases to pose a possible risk of increasing network congestion on the
congestion on the control channel (e.g. RTCP feedback), the data control channel (e.g. RTCP feedback), the data channel, or both. It
channel, or both. It is therefore desirable to provide a way of is therefore desirable to provide a way of suppressing unneeded
suppressing unneeded feedback. feedback.
One approach to this, suggested in [DVB-IPTV], involves sending a One approach to this, suggested in [DVB-IPTV], involves sending a
NACK message to the other clients (or receiver) in the same group as NACK message to the other clients (or receiver) in the same group as
the sender of NACK. However sending multicast NACK to the group can the sender of NACK. However sending multicast NACK to the group can
not prevent large amount of unicast NACK addressed to the same media not prevent large amount of unicast NACK addressed to the same media
source or middlebox, for example when the NACK is used as a source or middlebox, for example when the NACK is used as a
retransmission request [RFC4588]. Also NACK is defined as a receiver retransmission request [RFC4588]. Also NACK is defined as a receiver
report sent from a receiver observing a packet loss, therefore it report sent from a receiver observing a packet loss, therefore it
only inform others that sender of NACK detected loss while the case only inform others that sender of NACK detected loss while the case
the sender of the feedback has received reports that the indicated the sender of the feedback has received reports that the indicated
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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 intermediates are variously referred to as the receivers. These intermediates are variously referred to as
Distribution servers, MCUs, RTP translator, or RTP mixers, depending Distribution servers, MCUs, RTP translator, or RTP mixers, depending
on the precise use case. These intermediaries monitor for packet on the precise use case. These intermediaries monitor for packet
loss upstream of themselves by checking RTP sequence numbers, just as loss upstream of themselves by checking RTP sequence numbers, just as
receivers do. Upon observing (or suspecting) an upstream loss, the receivers do. Upon observing (or suspecting) an upstream loss, the
intermediary may send Loss Party Loss Report message towards the intermediary may send Loss Party Loss Report message towards the
receivers as defined in this specification. receivers as defined in this specification.
These intermediate nodes need to take into account such factors as These intermediate nodes need to take into account such factors as
the tolerable application delay, the network dynamics, and the media the tolerable application delay, packet loss recovery techniques, the
type. When the packet loss is detected upstream of the intermediary network dynamics, and the media type. When the packet loss is
and additional latency is tolerable, the intermediate node may itself detected upstream of the intermediary and additional latency is
send a feedback message asking for the suspected lost packet or ask tolerable, loss-repair methods such as Forward Error Correction and
for the correct decoder refresh point. Because it has already retransmission may be used to recover the missing packets. Therefore
provided the necessary feedback toward the source, the intermediate the intermediate node can be reasonably certain that it will help the
node can be reasonably certain that it will help the situation by situation by sending a Third Party Loss Report message to all the
sending a Third Party Loss Report message to all the relevant relevant receivers, thereby indicating to the receivers that they
receivers, thereby indicating to the receivers that they should not should not transmit feedback messages for a period of time.
transmit feedback messages for a period of time.
Alternatively, the media source may directly monitor the amount of Alternatively, the media source may directly monitor the amount of
feedback requests it receives, and send Third Party Loss Report feedback requests it receives, and send Third Party Loss Report
messages to the receivers. messages to the receivers.
When a receiver gets such a Third Party Loss Report message, it When a receiver gets such a Third Party Loss Report message, it
should refrain from sending a feedback request (e.g., NACK or FIR) should refrain from sending a feedback request (e.g., NACK or FIR)
for the missing packets reported in the message for a period of time. for the missing packets reported in the message for a period of time.
A receiver may still have sent a Feedback message according to the A receiver may still have sent a Feedback message according to the
AVPF scheduling algorithm of [RFC4585]before receiving a Third Party AVPF scheduling algorithm of [RFC4585]before receiving a Third Party
Loss Report message, but further feedback messages for those sequence Loss Report message, but further feedback messages for those sequence
numbers will be suppressed by this technique for a period of time. numbers will be suppressed by this technique for a period of time.
Nodes that do not understand the Third Party Loss Report message will Nodes that do not understand the Third Party Loss Report message will
ignore it, and might therefore still send feedback according to the ignore it, and might therefore still send feedback according to the
AVPF scheduling algorithm of [RFC4585]. The media source or AVPF scheduling algorithm of [RFC4585]. The media source or
intermediate nodes cannot assume that the use of a Third Party Loss intermediate nodes cannot assume that the use of a Third Party Loss
Report message actually reduces the amount of feedback it receives. Report message actually reduces the amount of feedback it receives.
skipping to change at page 6, line 23 skipping to change at page 6, line 21
Report message actually reduces the amount of feedback it receives. 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. But unlike RTCP NACK, the third party loss report type as RTCP NACK. But unlike RTCP NACK, the third party loss report
is defined as an indication that the sender of the feedback has is defined as an indication that the sender of the feedback has
received reports that the indicated packets were lost and conveys the received reports that the indicated packets were lost and conveys the
packet receipt/loss events at the sequence number level from the packet receipt/loss events at the sequence number level from the
middlebox to the receivers in the downstream path of middlebox while middlebox to the receivers in the downstream path of middlebox while
NACK [RFC4585]just indicates that the sender of the NACK observed NACK [RFC4585]just indicates that the sender of the NACK observed
that these packets were lost. The Third Party Loss Report message that these packets were lost. The Third Party Loss Report message
can also be generated by RTP middleboxs that has not seen the actual can also be generated by RTP middlebox that has not seen the actual
packet loss and sent to the corresponding receivers. Intermediaries packet loss and sent to the corresponding receivers. Intermediaries
downstream of an intermediary detecting loss obviously SHOULD NOT downstream of an intermediary detecting loss obviously SHOULD NOT
initiate their own additional Third Party Loss Report messages for initiate their own additional Third Party Loss Report messages for
the same packet sequence numbers. They may either simply forward the the same packet sequence numbers. They may either simply forward the
Third Party Loss Report message received from upstream, or replace it Third Party Loss Report message received from upstream, or replace it
with a Third Party Loss Report message that reflects the loss pattern with a Third Party Loss Report message that reflects the loss pattern
they have themselves seen. The Third Party Loss Report does not have they have themselves seen. The Third Party Loss Report does not have
the retransmission request [rfc4588] semantics. 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,
skipping to change at page 10, line 6 skipping to change at page 9, line 51
specific multicast group. specific multicast group.
In order to avoid the forms of Feedback implosion described in In order to avoid the forms of Feedback implosion described in
section 1,the distribution source should be told that the indicated section 1,the distribution source should be told that the indicated
packets were lost. How the distribution source know the indicated packets were lost. How the distribution source know the indicated
packets were lost is beyond of scope of this document. When upstream packets were lost is beyond of scope of this document. When upstream
link or downstream aggregate link packet loss occurs, the link or downstream aggregate link packet loss occurs, the
distribution source creates a Third Party Loss Report and sent it to distribution source creates a Third Party Loss Report and sent it to
all the RTP receivers, over the multicast channel. Another all the RTP receivers, over the multicast channel. Another
possibility is when there may be multiple distribution sources placed possibility is when there may be multiple distribution sources placed
between the media source and the receivers, the upstream distribution between the media source and the receivers, each distribution source
source may inform downstream distribution sources of the detected may send its own Third Party Loss report to downstream receivers
packet loss using Third Party Loss Report messages. In response, the respectively. And also the upstream distribution source may inform
downstream distribution sources in the path of the detected packet
loss using Third Party Loss Report messages. In response, if the
upstream Third Party Loss Report reports the different event, the
downstream distribution sources forward Third Party Loss Report downstream distribution sources forward Third Party Loss Report
received from upstream to all the RTP receivers, over the multicast received from upstream to all the RTP receivers, over the multicast
channel. This Third Party Loss Report message tells the receivers channel. If the same event is reported from upstream distribution
that the sender of the third party loss report has received reports source, the downstream distribution source may suppress creating and
that the indicated packets were lost. The distribution source then sending its own report to the relevant RTP receivers. This Third
can (optionally) ask for the lost packets from the media source on Party Loss Report message tells the receivers that the sender of the
behalf of all the RTP receivers. The lost packets will either be third party loss report has received reports that the indicated
forthcoming from distribution source, or it irretrievably lost such packets were lost. The distribution source then can (optionally) ask
that there is nothing to be gained by the receiver sending a NACK to for the lost packets from the media source or itself on behalf of all
the media source. the RTP receivers. The lost packets will either be forthcoming from
distribution source, or it irretrievably lost such that there is
nothing to be gained by the receiver sending a NACK to the media
source.
The distribution source must be able to communicate with all group The distribution source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing members in order for either mechanism to be effective at suppressing
feedback. feedback.
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. The RTCP Feedback Distribution Source Feedback Summary Model. The RTCP Feedback
extension for Third Party Loss Report specified in the Section 4 of extension for Third Party Loss Report specified in the Section 4 of
this document will work in both Feedback models. Details of this document will work in both Feedback models. Details of
skipping to change at page 11, line 8 skipping to change at page 11, line 8
loss is not needed and should not be sent to the media source(s). If loss is not needed and should not be sent to the media source(s). If
the media source(s) are part of the SSM group for RTCP packet the media source(s) are part of the SSM group for RTCP packet
reflection, the Distribution Source must filter this packet out. If reflection, the Distribution Source must filter this packet out. If
the media source(s) are not part of the SSM group for RTCP packets, the media source(s) are not part of the SSM group for RTCP packets,
the Distribution Source must not forward this RTCP Third Party Loss the Distribution Source must not forward this RTCP Third Party Loss
Report message to the media source(s). Report message to the media source(s).
6.1.2. Distribution Source Feedback Summary Model 6.1.2. Distribution Source Feedback Summary Model
In the distribution source feedback summary model, there may be In the distribution source feedback summary model, there may be
multiple distribution sources and the Loss Detection instances are multiple distribution sources who see the actual packet loss In this
distributed into different distribution sources. In some cases, section, we focus on this generic case to discuss the distribution
these Loss Detection instances for the same session can exist at the Source Feedback Summary Model.
same time, e.g., one Loss Detection instance is implemented in the
upstream distribution source A, a second Loss Detection instance for
the same session is part of feedback target A and feedback target B
respectively within the distribution source B. The distribution
source B is placed in the path between distribution A and downstream
receivers. In this section, we focus on this generic case to discuss
the distribution Source Feedback Summary Model.
The distribution source A must listen on the RTP channel for data. The distribution source A must listen on the RTP channel for data.
When the distribution source A observes RTP packets from a media When the distribution source A observes RTP packets from a media
source are not consecutive by checking the sequence number of source are not consecutive by checking the sequence number of
packets, the distribution source A generates the new RTCP Third Party packets, the distribution source A generates the new RTCP Third Party
Loss Report message described in the Section 4, and then send it to Loss Report message described in the Section 4, and then send it to
receivers in the downstream path via the multicast channel. Note receivers in the downstream path via the multicast channel. Note
that the distribution source A must use its own SSRC value as packet that the distribution source A must use its own SSRC value as packet
sender SSRC for transmitting the new RTCP Third Party Loss Report sender SSRC for transmitting the new RTCP Third Party Loss Report
message. message.
a second detection instance within the Distribution Source B must The Distribution Source B must also listen for RTCP data sent to the
also listen for RTCP data sent to the RTCP port. Upon receiving the RTCP port. Upon receiving the RTCP Third Party Loss Report from the
RTCP Third Party Loss Report from the Distribution Source A, the Distribution Source A, the Distribution Source B needs to check
distribution source B needs to check whether it sees upstream third whether it sees upstream third party loss report from distribution
party loss report from distribution source A reporting the same source A reporting the same event. If the upstream Third Party Loss
event. If the upstream Third Party Loss Report reports the different Report reports the different event, the distribution source B passes
event, the distribution source B passes through any Third Party Loss through any Third Party Loss Report message it receives from the
Report message it receives from the upstream direction. If the same upstream direction. If the same event is reported from distribution
event is reported from distribution source A, the distribution source source A, the distribution source B may suppress creating and sending
B replaces it with the summary Third Party Loss Report with the its own report with the same event to the downstream RTP receiver.
information summarization received from two loss detection instances Also the Distribution Source B may create and send its own summary
within the Distribution Source B. In order to reduce the processing Third Party Loss Report described in the Section 4 to the group over
load at the distribution source, each loss detection instance may the multicast RTCP channel. . In order to reduce the processing load
provide preliminary summarization report. at the distribution source, the distribution source B may provide
preliminary summarization Third Party Loss Report.
During the summary third party loss report creating, the Distribution
Source B must use its own SSRC value as packet sender SSRC for
transmitting summarization information and MUST perform proper SSRC
collision detection and resolution.
The distribution source B may send this new RTCP summary third party
loss report described in the Section 4to the group on the multicast
RTCP channel and meanwhile send a packet loss request to the media
source.
In some case, the distribution source B may receive RTCP NACK In some case, the distribution source B may receive RTCP NACK
messages from the receivers behind the Distribution Source before the messages from the receivers behind the Distribution Source before the
distribution source detects the packet loss which may cause potential distribution source detects the packet loss which may cause potential
Feedback implosion. In such case, the distribution source B may Feedback implosion. In such case, the distribution source B may
filter them out if it already detected the same loss or sent a packet filter them out if it already detected the same loss.
loss request for the missing packet to the media source.
When the host receives the RTCP Third Party Loss Report message, if
the host understands this message it will not send packet loss
request (e.g., NACK) for the missing packets reported in the message.
If it did not understand this new message, the host MAY send packet
loss request(e.g., NACK messages) to the specified media source.
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 The typical RAMS architecture
[I-D.ietf-avt-rapid-acquisition-for-rtp]may have several Burst/ [I-D.ietf-avt-rapid-acquisition-for-rtp]may have several Burst/
Retransmission Sources(BRS) behind the multicast source (MS) These Retransmission Sources(BRS) behind the multicast source (MS) These
BRSes will receive the multicast SSM stream from the media source. BRSes will receive the multicast SSM stream from the media source.
If one of the BRSes detects packet loss (i.e., First loss in If one of the BRSes detects packet loss (i.e., First loss in
Figure 3) on its upstream link between the MS and BRS, but the others Figure 3) on its upstream link between the MS and itself, but the
BRSes have not, as the packet loss took place on SSM tree branch that others BRSes have not, as the packet loss took place on the SSM tree
does not impact the other BRSes. In such case, the BRSes with loss branch that does not impact the other BRSes. In such case, the BRSes
detection functionality support cannot detect packet loss at their not being impacted cannot detect packet loss at their upstream link,
upstream link, therefore these BRSes will not create new Third Party therefore these BRSes will not create new Third Party Loss Report
Loss Report message and send it to receivers in their downstream message and send it to receivers in their downstream path. If the
path. If the BRS impacted by packet loss has loss detection support, BRS impacted by packet loss has seen the actual packet loss, the BRS
the BRS MAY choose to create new Third Party Loss Report message and MAY choose to create new Third Party Loss Report message and send it
send it to the receivers in the downstream link. Note that BRS must to the receivers in the downstream link. Note that BRS must use its
use its own SSRC as packet sender SSRC for transmitting the feedback own SSRC as packet sender SSRC for transmitting the feedback suppress
suppress message. 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.,
second loss in the Figure 3) on the downstream link. In order to second loss in the Figure 3) on the downstream link. In order to
deal with this issue, the downstream receiver can start a timeout deal with this issue, the downstream receiver can start a timeout
clock in which it expected to get a retransmission packet. When this clock in which it expected to get a retransmission packet. When this
timeout expires and there is no retransmitted packet or a new Third timeout expires and there is no retransmitted packet or a new Third
Party Loss Report message, it can take its normal behavior as if Party Loss Report message, it can take its normal behavior as if
there is no current retransmission suppression in place. there is no current retransmission suppression in place.
skipping to change at page 17, line 18 skipping to change at page 16, line 40
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
November 2010. November 2010.
[I-D.hunt-avt-monarch-01] [I-D.hunt-avt-monarch-01]
Hunt, G. and P. Arden, "Monitoring Architectures for RTP", Hunt, G. and P. Arden, "Monitoring Architectures for RTP",
August 2008. August 2008.
[I-D.ietf-pmol-metrics-framework-02] [I-D.ietf-pmol-metrics-framework-02]
Clark, A., "Framework for Performance Metric Development". Clark, A., "Framework for Performance Metric Development".
Appendix A. Appendix A. Change Log
Note to the RFC-Editor: please remove this section prior to
publication as an RFC.
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01
The following are the major changes compared to previous version:
o Remove the merge report from SSM use case and addional text to
address report merging issue.
o Revise section 3 and section 6 to address FEC packet dealing issue
and Leave how to repair packet loss beyond the scope.
o Modify the SSM use case and RAMS use case to focus on uses.
o Other 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. 20 change blocks. 
91 lines changed or deleted 89 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/