Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01

[Colin Perkins <[e-mail]>]

On 15 Apr 2011, at 11:05, Qin Wu wrote:
> Hi,folks:
> We have updated draft-ietf-avtcore-feedback-suppression-rtp to version 01 to address the comments from Prague meeting and on the list.
> The new version is available at:
> http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/
> the diff from 00 is
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-01
>  
> Also I recall in the meeting there was a comment about use case and we have four use cases in the current draft and I would ask WG do people think these use cases are clear and what use cases are missing and do people think that use cases are needed.


I have several comments on this draft that relate to the use cases, both as written in Section 6, and elsewhere. The draft seems to be written as if it were still generating a feedback suppression packet, rather than a third-party loss report packet that happens to suppress feedback.

1) The title and abstract were appropriate when the draft was solely aimed at feedback suppression, but should be updated now the focus is on third-party loss reports. 

2) The protocol overview in Section 3, in particular the 2nd to 5th paragraphs, seems to have the use case for this third party report backwards. If there is packet loss upstream of a middlebox, that middlebox should send a NACK packet both upstream and downstream, to indicate that it has noticed the loss, and to suppress feedback from other downstream receivers. The third-party loss report is sent downstream by the middlebox when downstream loss is reported to the middlebox in a way that other downstream receivers are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback.

3) The 6th paragraph of Section 3 also confuses this when it states "replace it with a Third Party Loss Report message that reflects the loss pattern they have themselves seen": if they have seen the loss, then a NACK is appropriate. If they've been told about the loss, then a third party loss report is needed.

4) Section 6.1, 2nd paragraph has a similar problem. Upstream loss will cause an SSM Distribution Source to generate a NACK, which it sends upstream and downstream. The third party loss report is used when one downstream receiver reports loss, leaving the Distribution Source with the responsibility of telling the other downstream receivers. Section 6.1.1 gets this correct.

5) Section 6.1.2, 2nd paragraph: same problem. This section also needs to talk about the need to generate and send downstream third party loss reports in response to NACKs received from downstream.

6) Section 6.2: why does a BRS that detects loss send a third-party report, rather than a NACK? The third-party report would be sent in response to downstream receivers sending NACKs, to inform other receivers, no?


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