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>]

Join time and first mcast seqnum would be common to all scenarios. However, what if that information is not available, meaning that the receiver could not join, i.e., could not receive anything at all from the multicast session? In that case, those fields should not exist. Using magical numbers is not a good idea.

So, I suggest the following: If join was successful (so at least one mcast packet was received), these two fields MUST (not may or should) be included in the report. If join was not successful, these fields SHALL NOT exist.

This should address Tom's concerns except that this report will not say much whether acceleration was requested or not (or if yes, which method was requested). I think we can use one of the status codes (we have 256 of them anyway) to indicate this. Or, we can separate a block to indicate the individual acceleration methods.

How does this sound?

-acbegen

> -----Original Message-----
> From: Eric Friedrich (efriedri)
> Sent: Friday, June 19, 2009 11:01 AM
> To: Ali C. Begen (abegen)
> Cc: 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)
> 
> Ali, Tom-
>    I think it would be useful to provide some small base set of fields
> that are required for any MA report. They should be fields that do not
> require any special instrumentation on the RTP Receiver and apply to
> RAMS and non-RAMS acquisitions. Looking over our proposed fields, I'd
> like to suggest that "First Multicast Extended Seq Number" and "SFGMP
> Join Time" be required fields. They would provide a small but useful
> amount of information in cases where receivers do not support the
> other fields.
> 
> Thanks,
> Eric
> 
> On Jun 19, 2009, at 1:43 PM, Ali C. Begen (abegen) wrote:
> 
> > 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
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt