Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

Colin,

What you say makes sense, but my feeling is that the rationale for defining the 3rd party loss report should be much better defined in the WG document, potentially along the lines you mentioned (but does it go beyond SSM in summary mode architectures?). The only rationale explicitly provided, is the one in the introduction which contains other reasoning which are partly incorrect. So I call upon the authors of the WG draft to revise the text. 
Tom

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org] 
Sent: dinsdag 21 juni 2011 17:13
To: Van Caenegem, Tom (Tom)
Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04

On 21 Jun 2011, at 16:04, Van Caenegem, Tom (Tom) wrote:
> Hi Colin,
> 
> Thx for sharing your view. See below. 
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@csperkins.org]
>> Sent: dinsdag 21 juni 2011 16:08
>> To: Van Caenegem, Tom (Tom)
>> Cc: Qin Wu; 'IETF AVTCore WG'; Roni Even
>> Subject: Re: [AVTCORE] Comments on 
>> draft-ietf-avtcore-feedback-supression-rtp-04
>> 
>> On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote:
>>> Hi,
>>> 
>>> as promised, these are comments I have on the draft " RTCP Extension for Third-party Loss Report"
>>> 
>>> -IMO the draft does not provide a good rationale on the use case for sending this new report. The section 3 (protocol overview) says:
>>> 
>>> "If an intermediary receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it.  An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems.   
>>> If an intermediary receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]."
>>> 
>>> My questions: 
>>> 
>>> -why would the intermediary not be able or capable to send the received NACK to the "systems" that were unable to receive the NACK, whereas it would be able or capable to send the 3rd party loss report to those same "systems"? 
>> 
>> Because the intermediary is trying to hide the identity or existence of those systems, and cannot forward the NACK from them without revealing that information.
>> 
> Tom: well.. This is a  new element you bring in here.. I can only guess why this rationale has not been explicitly included before in a WG document? Did I miss this discussion? It is certainly not aligned with the text/reasoning in the draft because a DS operating in simple FB mode is an example where the forwarding of NACKs seems to be the right thing to do (and not sending the 3rd party loss report) whereas a DS in summary FB mode is an example that would send 3rd party loss message. Why is hiding the identity an issue for the latter case (SSM in summary mode) and not for the former case (simple FB mode)? 

This is the purpose of summary feedback mode of RTCP-SSM: to limit the distribution of state for all participants, and instead give a summary. 

> Also, the draft is about FB storm suppression which is also realised with NACKs as you know... An incoming NACK can also be "anonimised" by having the DS or the FT acting as a translator for this NACK message. See draft-vancaenegem-avtcore-retransmission-for-ssm-00.

I know that NACKs suppress feedback. That doesn't invalidate the need for a third party loss report that also suppresses feedback, for the cases where it's not appropriate to use a NACK, such as the summary feedback mode of RTCP-SSM.

>>> -The DS in RTCP-SSM operating in FB summary mode is mentioned as an example for a case where a NACK cannnot be forwarded. Why is this?  RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00"
>> 
>> RFC 5760 allows the NACK to be forwarded, but this would cause the other receivers to become aware of, and keep state for, the participant that sent the NACK. If a third-party loss report is used, the other receivers don't become aware of the participant that signalled the loss, they just know that the loss occurred. 
>> 
> Tom: why is keeping state "required" here? Keeping state of what? 

RTCP state, since they'll see a NACK from a participant of which they were previously unaware.

>> -This section 3 makes a distinction between an intermediate that does check the RTP stream for missing packets itself, and an intermediate that does not, but still the behaviour in terms of FW-ing the NACKs received from other "systems" is exactly the same. Why make this distinction then?
>> 
>> I still have an outstanding comment which has not been resolved yet. The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined ONE SINGLE DS. Please clarify this.
>> 
>> Regards
>> Tom
>> _______________________________________________
>> Audio/Video Transport Core Maintenance avt@ietf.org 
>> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 

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