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

[Qin Wu <[e-mail]>]

On 6 May 2011, at 09:26, Qin Wu wrote:
>> 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.
>> 
>> [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=
> 
> [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.

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

[Qin]: Okay. I tend to agree.