Re: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR" (draft-begen-avt-rapid-sync-rtcp-xr-01)

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Tom,

Thanks for reading the draft.

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of VAN CAENEGEM Tom
> Sent: Thursday, June 18, 2009 7:17 AM
> To: avt at ietf.org
> Subject: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR"
> (draft-begen-avt-rapid-sync-rtcp-xr-01)
> 
> Hi Ali,
> 
> I have a few comments/questions related to the draft:
> 
> Comment 1:  The abstract now has a sentence: "For quality reporting, monitoring and
> diagnostics purposes, it is important to collect detailed information from the RTP
> receivers about their acquisition experiences."  Doesn't it go beyond "RTP (receivers)"
> and "acquisition" as you also define e.g. a TLV related to presentation time delay
> (sometimes the MC RTP delivered content may not even be displayed) and application delay.
> I have no problem with the definition of such fields, but IMO it makes sense to make this
> clear in the abstract.

I am not sure what else I can use instead of "RTP receivers" as I don't wanna specifically say decoders, set-tops, etc. Instead of "acquisition experiences", maybe we can call it "acquisition and presentation experiences"?

Would that help?
 
> Comment 2: Base Report
> 
> The only informational field here is "response". It is still not defined, but you refer to
> the response code in RAMS draft (e.g. "success", etc).

I believe using the same codes will make it more useful.

 
> I guess it is not possible to signal to an RR which additional info to send, i.e which TLV
> fields to use…From that point of view, would it not make sense to have some basic
> information -now defined in some TLV fields in the base report- that is always present, to

By always present, you mean "mandatory"? If yes, we indeed need to decide which ones.

> enhance interoperability. I know we need to find the right balance between useful
> information reporting ,  bandwidth efficiency, and receiver reporting capabilities.
> 
> Candidate fields that could be inside this fixed base report are:
> -flag/field indicating whether the report refers to a normal acquisition (based on SFGMP)
> or rapid MC RTP acquisition (or rather  the intention by the RR to perform  a rapid
> acquisition) for instance by means of RAMS

One reason behind this base report vs extensions separation was to be able to handle other rapid multicast acquisition methods. So, IMO, if we will have to make something mandatory, it should not relate to a specific method. It is true that I am heavily considering RAMS in designing this report, but it just works for other methods, if they become interested in supporting this report.

Will this flag/field be able to specify which method was used? Or will it simply specify whether it was a rapid or normal acquisition?

> -a response code which you have indeed defined and its interpretation should be dependent
> on the previously mentioned flag/field

So, the flag/field above will indeed specify which method was use to make RR rapidly acquire the content. Yes/no?

 
> -initial launched request (either 1st RAMS-R for rapid acquisition, either 1st IGMP-join
> in case of normal acquisition) to 1st received RTP packet (always a multicast packet for
> normal acquisition and "normally" a burst packet when a rapid acquisition process was
> involved) delta time
> 
> -application request to initial launched request (either 1st RAMS-R for rapid acquisition,
> either 1st IGMP-join in case of normal acquisition) delta time
> 
> For these last two fields, a value must be specified that would indicate that the field is
> not filled out (because the receiver client implementation may not support it).

Oh, then these fields are not mandatory since the client has the option to leave them blank. Then, I would recommend leaving the current report as it is, but we can use a stronger language (like "SHOULD/RECOMMENDED") for some of the fields (like the ones you have above) to promote interoperability. 

Would you be OK with that?

 
> There could still be other fields that apply to both acquisition processes and fit in the
> base report, but they should be application independent (e.g. delta to presentation time
> is clearly app dependent)

Agree, application dependent fields are optional and should stay so.

T,
-acbegen

> 
> Regards
> Tom