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

[Colin Perkins <[e-mail]>]

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:
>> 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.”
> [Qin]: Sorry, I forgot to update the abstract.
> Yes, Your proposed change is resonable and clear. Thanks.
> 
>> - 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).
> [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.
> "

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.


>> - 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.
> [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.
> "

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.


>> - 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.
>  
> [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
>> 
> 
> 
> 
> On 6 May 2011, at 10:53, Qin Wu wrote:
> > 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: <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Friday, May 06, 2011 5:39 PM
> > Subject: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt
> > 
> > 
> >> 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
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> [e-mail]
> >> 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
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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