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

[Colin Perkins <[e-mail]>]

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:
> 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/