draft-ietf-avtcore-feedback-supression-rtp-01.txt   draft-ietf-avtcore-feedback-supression-rtp-02.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: October 17, 2011 Huawei Expires: November 7, 2011 Huawei
April 15, 2011 May 6, 2011
RTCP Extension for Feedback Suppression Indication RTCP Extension for Third-party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-01 draft-ietf-avtcore-feedback-supression-rtp-02
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 Extension for third party loss report, to suppress NACK
and FIR feedback requests. It also defines associated SDP signaling. and FIR feedback requests. It also defines associated SDP signaling.
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 October 17, 2011. This Internet-Draft will expire on November 7, 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 . . . . . . . . . . . . . . . . 6 4. Format of RTCP Feedback Messages . . . . . . . . . . . . . . . 7
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 . . . . 7 4.2. Payload Specific Feedback: Third-party Loss Report . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 11 (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 . . . . . . . . . . . . . . . . . . . 13 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 Appendix A. Appendix A. Change Log . . . . . . . . . . . . . . . 16
A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16 A.1. draft-ietf-avtcore-feedback-suppression-rtp-01 . . . . . . 16
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02 . . . . . . 17
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 5, line 29 skipping to change at page 5, line 29
for particular packets (indicated by their RTP sequence numbers) for particular packets (indicated by their RTP sequence numbers)
independent of whether the receiver detected the packet loss or independent of whether the receiver detected the packet loss or
detected a need for a decoder refresh point. detected a need for a decoder refresh point.
In order to observe packet loss before the receivers perceive it, one In order to observe packet loss before the receivers perceive it, one
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. These intermediate nodes need to take into account
intermediary may send Loss Party Loss Report message towards the such factors as the tolerable application delay, packet loss recovery
receivers as defined in this specification. techniques, the network dynamics, and the media type. Loss-repair
methods such as retransmission and Forward Error Correction may be
These intermediate nodes need to take into account such factors as used to recover the missing packet. Upon observing (or suspecting)
the tolerable application delay, packet loss recovery techniques, the an upstream loss, the intermediary Should send NACK both downstream
network dynamics, and the media type. When the packet loss is towards the receivers and upstream towards the media source, to
detected upstream of the intermediary and additional latency is indicate that it has noticed the loss, and to suppress feedback from
tolerable, loss-repair methods such as Forward Error Correction and other downstream receivers. Upon downstream loss is reported to the
retransmission may be used to recover the missing packets. Therefore intermediary, the intermediary SHOULD send the Third Party Loss
the intermediate node can be reasonably certain that it will help the report to the other downstream receivers which are not aware of the
situation by sending a Third Party Loss Report message to all the loss reports, to inform those receivers of the loss and suppress
relevant receivers, thereby indicating to the receivers that they their feedback. Therefore the intermediate node can be reasonably
should not transmit feedback messages for a period of time. certain that it will help the situation by sending a Third Party Loss
Report message and NACK message to all the relevant receivers,
thereby indicating to the receivers that they should not 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 from downstream, and send the Third
messages to the receivers. Party Loss Report messages to the downstream 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.
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 is
can also be generated by RTP middlebox that has not seen the actual generated by RTP middlebox that has not seen the actual packet loss
packet loss and sent to the corresponding receivers. Intermediaries and sent to the corresponding receivers. Intermediaries downstream
downstream of an intermediary detecting loss obviously SHOULD NOT of an intermediary receiving the upstream report 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 send its
with a Third Party Loss Report message that reflects the loss pattern own Third Party Loss Report message that reflects the loss they have
they have themselves seen. The Third Party Loss Report does not have been told. The Third Party Loss Report does not have the
the retransmission request [rfc4588] semantics. retransmission request [RFC4588] semantics.
Since Third Party Loss Report interacts strongly with repair timing, Since Third Party Loss Report interacts strongly with repair timing,
it has to work together with feedback to not adversely impact the it has to work together with feedback to not adversely impact the
repair of lost source packets. One example is the middle box gets repair of lost source packets. One example is the middle box gets
the retransmitted packet by sending a NACK upstream and sent it the retransmitted packet by sending a NACK upstream and sent it
downstream. This retransmitted packet was lost on the downstream downstream. This retransmitted packet was lost on the downstream
link. In order to deal with this, the downstream receiver can start link. In order to deal with this, the downstream receiver can start
a timeout in which it expected to get a retransmission packet. When a timeout in which it expected to get a retransmission packet. When
this timeout expires and there is no retransmitted packet or a new this timeout expires and there is no retransmitted packet or a new
third party loss report message, it can take its normal behavior as third party loss report message, it can take its normal behavior as
if there is no current retransmission suppression. In some cases if there is no current retransmission suppression. In some cases
where the loss was detected and repair initiated much closer to the where the loss was detected and repair initiated much closer to the
source, the delay for the receiver to recover from packet loss can be source, the delay for the receiver to recover from packet loss can be
reduced through the combination of intermediary feedback to the reduced through the combination of intermediary feedback to the
source and Third Party Loss Report downstream. In all (properly source and Third Party Loss Report downstream. In all (properly
operating) cases, the risk of increasing network congestion is operating) cases, the risk of increasing network congestion is
decreased. decreased.
4. RTCP Feedback Report Extension 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 Third Party Loss Report together with their repair methods MAY use Third Party Loss Report together with their
existing loss-repair methods either for every packet they expect to existing loss-repair methods either for every packet they expect to
receive, or for an application-specific subset of the RTP packets in receive, or for an application-specific subset of the RTP packets in
a session. In other words, receivers MAY ignore Third Party Loss a session. In other words, receivers MAY ignore Third Party Loss
Report messages, but SHOULD react to them unless they have good Report messages, but SHOULD react to them unless they have good
reason to still send feedback messages despite having been requested reason to still send feedback messages despite having been requested
to suppress them. to suppress them.
skipping to change at page 7, line 24 skipping to change at page 7, line 28
This Third Party Loss Report message is an extension to the RTCP This Third Party Loss Report message is an extension to the RTCP
Transport Layer Feedback Report and identified by RTCP packet type Transport Layer Feedback Report and identified by RTCP packet type
value PT=RTPFB and FMT=TBD. value PT=RTPFB and FMT=TBD.
The FCI field MUST contain one or more entries of transport layer The FCI field MUST contain one or more entries of transport layer
third party loss Early Indication (TLLEI). Each entry applies to a third party loss Early Indication (TLLEI). Each entry applies to a
different media source, identified by its SSRC. different media source, identified by its SSRC.
The Feedback Control Information (FCI) for TLLEI uses the similar The Feedback Control Information (FCI) for TLLEI uses the similar
format of message Types defined in the section 4.3.1.1 of [RFC5104]. format of message Types defined in the section 6.2.1 of [RFC4585].
The format is shown in Figure 1. The format is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP | | PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Message Format for the Third Party Loss Report Figure 1: Message Format for the Third Party Loss Report
skipping to change at page 9, line 46 skipping to change at page 9, line 48
6.1. Source Specific Multicast (SSM) use case 6.1. Source Specific Multicast (SSM) use case
In SSM RTP sessions as described in [RFC5760], one or more Media In SSM RTP sessions as described in [RFC5760], one or more Media
Sources send RTP packets to a Distribution Source. The Distribution Sources send RTP packets to a Distribution Source. The Distribution
Source relays the RTP packets to the receivers using a source- Source relays the RTP packets to the receivers using a source-
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 one
link or downstream aggregate link packet loss occurs, the downstream receiver reports loss, the distribution source creates a
distribution source creates a Third Party Loss Report and sent it to Third Party Loss Report and sent it to all the RTP receivers, over
all the RTP receivers, over the multicast channel. Another the multicast channel. Another possibility is when there may be
possibility is when there may be multiple distribution sources placed multiple distribution sources placed between the media source and the
between the media source and the receivers, each distribution source receivers, each distribution source may send its own Third Party Loss
may send its own Third Party Loss report to downstream receivers report to downstream receivers respectively when downstream loss is
respectively. And also the upstream distribution source may inform reported to each distribution source. And also the upstream
downstream distribution sources in the path of the detected packet distribution source may inform downstream distribution sources in the
loss using Third Party Loss Report messages. In response, if the path of the detected packet loss using the Third Party Loss Report
upstream Third Party Loss Report reports the different event, the messages. In response, if the upstream Third Party Loss Report
downstream distribution sources forward Third Party Loss Report reports the different event, the downstream distribution sources
received from upstream to all the RTP receivers, over the multicast forward Third Party Loss Report received from upstream to all the RTP
channel. If the same event is reported from upstream distribution receivers, over the multicast channel. If the same event is reported
source, the downstream distribution source may suppress creating and both from upstream distribution source and from downstream receiver,
sending its own report to the relevant RTP receivers. This Third the downstream distribution source may suppress creating and sending
Party Loss Report message tells the receivers that the sender of the its own report to the relevant RTP receivers. This Third Party Loss
third party loss report has received reports that the indicated Report message tells the receivers that the sender of the third party
packets were lost. The distribution source then can (optionally) ask loss report has received reports that the indicated packets were
for the lost packets from the media source or itself on behalf of all lost. The distribution source then can (optionally) ask for the lost
the RTP receivers. The lost packets will either be forthcoming from packets from the media source or itself on behalf of all the RTP
receivers. The lost packets will either be forthcoming from
distribution source, or it irretrievably lost such that there is distribution source, or it irretrievably lost such that there is
nothing to be gained by the receiver sending a NACK to the media nothing to be gained by the receiver sending a NACK to the media
source. 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
skipping to change at page 11, line 15 skipping to change at page 11, line 19
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 who see the actual packet loss In this multiple distribution sources who see the actual packet loss In this
section, we focus on this generic case to discuss the distribution section, we focus on this generic case to discuss the distribution
Source Feedback Summary Model. 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 NACK message, and
Loss Report message described in the Section 4, and then send it to then send it to receivers in the downstream path via the multicast
receivers in the downstream path via the multicast channel. Note channel.
that the distribution source A must use its own SSRC value as packet
sender SSRC for transmitting the new RTCP Third Party Loss Report
message.
The Distribution Source B must also listen for RTCP data sent to the The Distribution Source B must also listen for RTCP data sent to the
RTCP port. Upon receiving the RTCP Third Party Loss Report from the RTCP port. Upon receiving the RTCP Third Party Loss Report from the
Distribution Source A, the Distribution Source B needs to check Distribution Source A, the Distribution Source B needs to check
whether it sees upstream third party loss report from distribution whether it sees the same event reported both from upstream
source A reporting the same event. If the upstream Third Party Loss distribution source A and downstream receiver. If the upstream Third
Report reports the different event, the distribution source B passes Party Loss Report reports the different event, the distribution
through any Third Party Loss Report message it receives from the source B passes through any Third Party Loss Report message it
upstream direction. If the same event is reported from distribution receives from the upstream direction. If the same event is reported
source A, the distribution source B may suppress creating and sending from both distribution source A and downstream receiver of
its own report with the same event to the downstream RTP receiver. distribution source B, the distribution source B may suppress
Also the Distribution Source B may create and send its own summary creating and sending its own report with the same event to the
Third Party Loss Report described in the Section 4 to the group over downstream RTP receiver.
the multicast RTCP channel. . In order to reduce the processing load
at the distribution source, the distribution source B may provide
preliminary summarization Third Party Loss Report.
In some case, the distribution source B may receive RTCP NACK Also the Distribution Source B may create and send its own Third
messages from the receivers behind the Distribution Source before the Party Loss Report described in the Section 4 to the group over the
distribution source detects the packet loss which may cause potential multicast RTCP channel in response to NACKs received from downstream.
Feedback implosion. In such case, the distribution source B may if downstream loss is reported using NACK to the distribution source
filter them out if it already detected the same loss. B.
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 receives downstream loss report (i.e., First loss
Figure 3) on its upstream link between the MS and itself, but the in Figure 3) on its downstream link, but the others BRSes have not,
others BRSes have not, as the packet loss took place on the SSM tree as the packet loss took place on the SSM tree branch that does not
branch that does not impact the other BRSes. In such case, the BRSes impact the other BRSes. In such case, the BRSes not being impacted
not being impacted cannot detect packet loss at their upstream link, are not aware of downstream loss at their downstream link, therefore
therefore these BRSes will not create new Third Party Loss Report these BRSes will not create new Third Party Loss Report message and
message and send it to receivers in their downstream path. If the send it to receivers in their downstream path. If the BRS impacted
BRS impacted by packet loss has seen the actual packet loss, the BRS by packet loss has been told the actual packet loss, the BRS MAY
MAY choose to create new Third Party Loss Report message and send it choose to create new Third Party Loss Report message and send it to
to the receivers in the downstream link. Note that BRS must use its the receivers in the downstream link. Note that BRS must use its own
own SSRC as packet sender SSRC for transmitting the feedback suppress SSRC as packet sender SSRC for transmitting the feedback 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.
First +------------+ +----------+ +------------+ First Loss +----------+
loss |Burst and |Second Loss | | |Burst and |Second Loss | |
+-----X-----| Retrans. |----X------>| | +-----------| Retrans. |----X--X--->| |
| Upstream |Source1(BRS)| Downstream | | | Upstream |Source1(BRS)| Downstream | |
Link close | link 1 +------------+ link 1 | | Link close | link 1 +------------+ link 1 | |
to multicast | | | to multicast | | |
source | | | source | | |
| | | | | | | |
| | +------------+ | RTP | | | +------------+ | RTP |
+---------+ | +-----++ |Burst and | | Receiver | +---------+ | +-----++ |Burst and | | Receiver |
|Multicast| V| | +----------| Retrans. |----------->| | |Multicast| V| | +----------| Retrans. |----------->| |
| Source +-----|Router|Upstream |Source2(BRS)| Downstream | RTP_Rx | | Source +-----|Router|Upstream |Source2(BRS)| Downstream | RTP_Rx |
+---------+ | |link 2 +------------+ link 2 | | +---------+ | |link 2 +------------+ link 2 | |
skipping to change at page 17, line 10 skipping to change at page 17, line 10
The following are the major changes compared to previous version: The following are the major changes compared to previous version:
o Remove the merge report from SSM use case and addional text to o Remove the merge report from SSM use case and addional text to
address report merging issue. address report merging issue.
o Revise section 3 and section 6 to address FEC packet dealing issue o Revise section 3 and section 6 to address FEC packet dealing issue
and Leave how to repair packet loss beyond the scope. 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 Modify the SSM use case and RAMS use case to focus on uses.
o Other Editorial changes. o Other Editorial changes.
A.2. draft-ietf-avtcore-feedback-suppression-rtp-02
The following are the major changes compared to previous version:
o In Appendix A, fix typo: Appendix A. Appendix A. -> Appdendix A.
o In Section 4.1, fix typo: Section 4.3.1.1 of section [RFC5104]->
section 6.2.1 of [RFC4585].
o In Section 3: Clarify how to deal with downstream loss using Third
party loss report and upstream loss using NACK.
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
loss report is used to deal with downstream loss.
o In section 6.1.2: Update this section to explain how third party
loss report is used to deal with downstream loss.
o In section 6.2: Rephrase the text to discuss how BRS deal with the
third party loss report.
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. 21 change blocks. 
94 lines changed or deleted 109 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/