[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR" (draft-begen-avt-rapid-sync-rtcp-xr-01)
Hi Tom,
I just feel that mandating some fields but not requiring the receivers to fill them in is not a good solution. As I mentioned earlier, I'd prefer using a stronger language than "optional" but I prefer not to mandate such fields.
Any other opinions?
-acbegen
> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> Sent: Friday, June 19, 2009 3:40 AM
> To: Ali C. Begen (abegen); avt at ietf.org
> Subject: RE: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR"
> (draft-begen-avt-rapid-sync-rtcp-xr-01)
>
> Hi Ali,
>
> Look for "TOM" ...
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: donderdag 18 juni 2009 17:34
> To: VAN CAENEGEM Tom; avt at ietf.org
> Subject: RE: [AVT] Some comments on " Multicast Acquisition Report Block
> Typefor RTCP XR" (draft-begen-avt-rapid-sync-rtcp-xr-01)
>
> 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?
>
> "TOM" : OK
>
> > 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.
>
> "TOM" : OK, but most codes only apply to a rapid acquisition process, so
> it makes sense to indicate additionally whether "normal" or "rapid"
> acquisition was initiated by the receiver (that is an additional flag)
>
> > 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.
>
> "TOM" : indeed mandatory : when by means of declarative SDP, the RTP
> receivers are instructed to send RTCP XR with multicast acquisition
> report blocks, AND RTP recievers support these XR messages, these fields
> are always there.
>
> > 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?
>
> "TOM" : for a 1-bit flag, that should be the latter : normal or rapid
> (in whatever way). Alternatively considering a multiple bit field (e.g.
> 3 bits) where e.g. 001 = normal aquisition, 002 = RAMS, and all other
> codes unspecified at this stage looks to me a good solution as well...
>
> > -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?
>
> "TOM" : see above
>
>
> > -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?
>
> "TOM" : the reason to have the field in the base report, is to make sure
> that a minimum of information is conveyed back to the server/feedback
> target. Otherwise, as all TLV fields are optional, how can a server
> indicate to a client which TLV fields it is interested in and which ones
> not? The proposed fields I selected/defined are those that provide
> useful information for both a normal and RAMS process, but there may be
> other fields equally appropriate to be always present. Whether we need
> an RTP receiver to mandate to fill out these fields (with the right
> value) is a separate discussion, IMO.
>
> > 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