Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt

From: [email-masked]
Date: Fri, 06 May 2011 02:39:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : RTCP Extension for Third-party Loss Report
	Author(s)       : Qin Wu
                          Frank Xia
                          Roni Even
	Filename        : draft-ietf-avtcore-feedback-supression-rtp-02.txt
	Pages           : 18
	Date            : 2011-05-06

   In a large RTP session using the RTCP feedback mechanism defined in
   RFC 4585, a media source or middlebox may experience transient
   overload if some event causes a large number of receivers to send
   feedback at once.  This feedback implosion can be mitigated if the
   device suffering from overload can send a third party loss report
   message to the receivers to inhibit further feedback.  This memo
   defines RTCP Extension for third party loss report, to suppress NACK
   and FIR feedback requests.  It also defines associated SDP signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-02.txt

---

From: Qin Wu <[email-masked]>
Date: Fri, 06 May 2011 17:53:06 +0800

Hi,
The new version of draft-ietf-avtcore-feedback-suppression-rtp is available at
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-02.txt
which address the recent comments from Colin on the list.
The main change is to clarify the use of third party loss report and update the title and relevant sections 
to focus on third party loss report.
The diff is at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-02
Please check if you are comfortable with the changes in this version.
Any comments?

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 06, 2011 5:39 PM
Subject: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 11 May 2011 17:04:50 +0100

Qin,

This version is better, but I'm still not sure it fully clarifies when third-party loss reports should be sent in place of NACKs. In particular:

- The abstract still reads as-if the draft is solely focussed on feedback suppression. I suggest it could be rephrased something like: “In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are certain cases where it is not possible to forward feedback reports, and this may allow feedback implosion. This memo defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined.”

- Section 3, 2nd paragraph: this doesn’t clearly differentiate when a third-party loss report should be used compared to a NACK. In particular, the sentence “Upon downstream loss is reported to the intermediary, the intermediary SHOULD send the Third Party Loss report to the other downstream receivers which are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback” needs to be expanded to discuss what “are not aware of the loss reports” means in this context (i.e., when it's not possible to distribute the NACKs to all receivers).

- Section 3, 3rd paragraph: this would be much clearer if it discussed when it’s appropriate to monitor the feedback and send a third-party loss report to downstream receivers, rather than just reflect NACKs back downstream.

- Section 6.1, 2nd paragraph: when in Simple Feedback Mode, NACKs are reflected and there’s no need for the third-party loss report. The downstream third-party loss report is only generated when in Distribution Source Feedback Summary mode. I’m not sure it makes sense to write generic rules in Section 6.1, instead of writing specific rules for each of the two feedback modes in Section 61.1 and 6.1.2.

Cheers,
Colin

On 6 May 2011, at 10:53, Qin Wu wrote:
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 May 2011 11:56:34 +0800

[Qin]: Sorry, I forgot to update the abstract.
Yes, Your proposed change is resonable and clear. Thanks.

[Qin]: Yes, you are correct. How about the following proposal:
"
However, in some cases where packet loss occurs in the downstream of these intermediates, 
it is not possible for the intermediates to distribute the NACKs to all receivers. In such cases, downstream loss needs
 to be firstly reported to the intermediary in some way. Upon downstream loss is reported to the
 intermediary, the intermediary SHOULD send the Third Party Loss report to the other downstream receivers.
"

[Qin]: Okay. I think the answer to when is 
"
Upon receiving downstream loss report in the way of such feedback report only destined for media source, the media source SHOULD send the Third
Party Loss Report messages to the receivers.
"

[Qin]: Yes, it more make sense to make it in the section 6.1. I will update section 6.1, section 6.1.1 and section 6.1.2 to reflect this.

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 16 May 2011 12:14:23 +0100

Qin,

[I have fixed the quoting to me clear who wrote what]

On 12 May 2011, at 04:56, Qin Wu wrote:
> On 11 May 2011, at 17:04, Colin Perkins wrote:

I don't think this, nor the text in draft-ietf-avtcore-feedback-supressions-rtp-03 is correct. Section 3, 2nd paragraph of the -03 draft says “However, in some cases where packet loss occurs in the downstream of these intermediates, it is not possible for them to distribute the NACKs to all receivers since they are unable to observe downstream loss.  In such cases, downstream loss needs to be firstly reported to the intermediary.  When downstream loss is reported to the intermediary, the intermediary SHOULD create and send the Third Party Loss report to the other downstream receivers which are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback.  Therefore the intermediate node can be reasonably certain that it will help the situation by sending a Third Party Loss Report message to all the relevant receivers,”. This makes it sound like the intermediary always uses a third-party loss report to tell other receivers about downstream loss. That’s not the case. In many scenarios, the intermediary can reflect NACKs it receives from one downstream receiver to the other receivers without using a third party loss report. The third-party loss report is only needed in those cases where NACKs cannot be distributed to all receivers.

> Party Loss Report messages to the receivers.

I don't think that's correct. In most cases, loss feedback destined to the sender should be reflected downstream to suppress further feedback.  This draft needs to discuss the scenarios, for example SSM sessions using Distribution Source Feedback Summary mode, where this is not possible. It is these scenarios where third party loss reports are needed.

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Tue, 24 May 2011 14:05:29 +0800

Hi, Colin:
Please check if the following changes address your comments.

Regards!
-Qin
----- Original Message ----- 
  From: Colin Perkins 
  To: Qin Wu 
  Cc: [email-masked] ; [email-masked] 
  Sent: Monday, May 16, 2011 7:14 PM
  Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt

  Qin,

  [Qin]: You are right. As for downstream loss, in some cases, the intermediary may send NACK, e.g., RTCP-SSM in Simple feedback model, in some cases, the intermediary must send the third party loss report instead of NACK,e.g., RTCP-SSM in Summary Feedback Model. Therefore I propose the changes in Paragraph 2, section 3 of draft-ietf-avtcore-feedback-supression-rtp as follows:
  OLD TEXT:
  "
   Upon observing (or suspecting) an upstream loss, the
     intermediary Should send NACK both downstream towards the receivers
     and upstream towards the media source, to indicate that it has
     noticed the loss, and to suppress feedback from other downstream
     receivers.  However, in some cases where packet loss occurs in the
     downstream of these intermediates, it is not possible for them to
     distribute the NACKs to all receivers since they are unable to
     observe downstream loss.  In such cases, downstream loss needs to be
     firstly reported to the intermediary.  When downstream loss is
     reported to the intermediary, the intermediary SHOULD create and send
     the Third Party Loss report to the other downstream receivers which
     are not aware of the loss reports, to inform those receivers of the
     loss and suppress their feedback.  
  "
  NEW TEXT:

  "
     If an intermediary notices the loss itself, then it
     may send a NACK both downstream towards the receivers and upstream
     towards the media source, to indicate that it has noticed the loss,
     and to suppress feedback from other downstream receivers.  If an
     intermediary receives a NACK from another system, it should
     redistribute that NACK to all other systems that would not otherwise
     receive it.  An example of this is RTCP-SSM in simple feedback model
     [RFC5760], where the distribution source reflects NACKs to other
     systems.  If an intermediary receives a NACK from another system,
     but, for some reason, cannot redistribute that NACK, then it may send
     a third-party loss report to the systems that were unable to receive
     the NACK, and won't receive the NACK via other means.  An example
     would be a distribution source using RTCP-SSM in Distribution Source
     Feedback Summary model [RFC5760]. 
  "

  - Section 3, 3rd paragraph: this would be much clearer if it discussed when it’s appropriate to monitor the feedback 
  and send a third-party loss report to downstream receivers, rather than just reflect NACKs back downstream.

  I don't think that's correct. In most cases, loss feedback destined to the sender should be reflected downstream to suppress further feedback.  
  This draft needs to discuss the scenarios, for example SSM sessions using Distribution Source Feedback Summary mode, where this is not possible. 
  It is these scenarios where third party loss reports are needed.

  [Qin]: Agree, Proposed the following changes:
  OLD TEXT:
  "
     Upon receiving
     downstream loss report in the form of such feedback report which is
     only destined for media source, the media source SHOULD create and
     send the Third Party Loss Report messages to the other downstream
     receivers which are not aware of the loss reports, to inform those
     receivers of the loss and suppress their feedback.

  "
  NEW TEXT:
  "
     If the media source
     receives a NACK from another system, it should redistribute that NACK
     to all other systems that would not otherwise receive it.  An example
     of this is RTCP-SSM in simple feedback model [RFC5760], where the
     distribution source reflects NACKs to other systems.  If an
     intermediary receives a NACK from another system, but, for some
     reason, cannot redistribute that NACK, then it may send a third-party
     loss report to the systems that were unable to receive the NACK, and
     won't receive the NACK via other means.  An example would be a
     distribution source using RTCP-SSM in Distribution Source Feedback
     Summary model [RFC5760].

  "

  -- 
  Colin Perkins
  http://csperkins.org/

  -- 
  Colin Perkins
  http://csperkins.org/