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

From: Colin Perkins <[email-masked]>
Date: Thu, 5 May 2011 17:30:08 +0100

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/

---

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

Thanks for your valuable comments, please see below.
  ----- Original Message ----- 
  From: Colin Perkins 
  To: Qin Wu 
  Cc: [email-masked] ; [email-masked] 
  Sent: Friday, May 06, 2011 12:30 AM
  Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01

  [Qin]: Good point, will reflect this update in the new version.

  [Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document.

  [Qin]: Okay.

  [Qin]: Okay.

  [Qin]: Okay.

  [Qin]: Okay, how about rephrase 
  "
  a BRS that detects loss
  "
  as
  "
  a BRS that receives downstream loss report
  "
  In this case, BRS need to send handle third-party report rather than NACK..

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 6 May 2011 09:11:53 +0100

> [Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document.

The NACK is a notification of loss: it's independent of the packet loss recovery mechanism used. I do not believe this is out of scope of this document.

Colin

---

From: Qin Wu <[email-masked]>
Date: Fri, 06 May 2011 16:26:42 +0800

Colin=

[Qin]: But NACK also can be used for retransmission. Retransmission is one kind of packet loss repairement mechanism. And there was consensus that how to repair the packet loss should be beyond scope of this document. 
If I am wrong, please correct me.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 6 May 2011 10:02:16 +0100

> If I am wrong, please correct me.

According to RFC 4585, a "Generic NACK is used to indicate the loss of one or more RTP packets". An endpoint that receives a NACK might decide to retransmit the lost packet, but that's not required, and by sending a NACK, we are not requiring retransmission. 

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

---

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

-- 
Colin Perkins

[Qin]: Okay. I tend to agree.