[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 am concerned about introducing too much complexity into this XR report. I tend to agree to have a field that indicates the method used for the multicast join (simple join vs RAMS vs others) where we can have an IANA-maintained list.
However, the success/failure terminology seems to complicate things, so I believe we should refrain from interpreting anything at the reporting instant and let the monitoring agent interpret whatever the clients report. This keeps the client side simple and every client provides objective (not subjective) numbers even when they use different methods.
Of course, if very method-specific and/or vendor-specific information is desired, we have the appropriate extension mechanisms.
So, in summary, we should include the "Join time" and "first mcast seqnum" in all reports whenever possible. Specifically, if join was successful (so at least one mcast packet was received), these two fields MUST be included in the report. If join was not successful, these fields SHALL NOT exist. Everything else is optional.
-acbegen
> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
> Sent: Monday, June 22, 2009 9:29 AM
> To: Ali C. Begen (abegen); Eric Friedrich (efriedri)
> Cc: 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,
>
> I think your proposal is +/- OK. However, I believe there is some room
> for improvement here. Suppose we have :
>
>
> - a dedicated field X (3 bit is sufficient) "acquisition_method" with a
> code indicating which kind of acquisition process was initiated by the
> receiver (we can already define two codes in this draft : normal SFGMP
> process and RAMS process)
>
> E.g.
>
> X =001 = Normal MC Acquisition Process
> X =011 = RAMS-based MC Acquisition Process
>
> - a dedicated field Y indicating the MC acquisition "status code" . For
> normal acquisition process, only two codes can be defined (success or no
> success), and for the RAMS process, your proposal was to refer to codes
> defined in RAMS draft, but to me it makes more sense to (additionally)
> define a code that provides the success/non success from the receiver
> point of view. E.g. "success" code received by the receiver from the
> retransmission server in the RAMS-I does not mean the RAMS is a success.
> Note also that it would make sense to clearly make a distinction whether
> the RAMS was successful or not, and also whether the MC join -following
> and as part of the RAMS -was successful. It gives immediate insight by
> the retransmission server which part failed. We then can also define per
> code which fields must be present, for an RTP receiver supporting this
> kind of XR reports.
>
> E.g. the Y code for RAMS could be composed of two sub-fields
>
> -Subfield Y1 (2 bits):
>
> 00=RAMS unsuccessful, MC join unsuccessful
> 01=RAMS unsuccessful, MC join successful
> 11=RAMS successful, MC join successful
>
> What does 'RAMS successful (/unsuccessful)" mean here? This is not easy
> to answer, but I think it should represent the status from the point of
> view of the receiver, i.e. receiving a RAMS-I message with code
> "successful" is not sufficient (e.g. the RTP burst may not be delivered
> to the receiver, e.g. because of bad configuration of the NAPT). So,
> reception of the RTP data burst by the receiver as response on a
> RAMS-Request, looks like a better condition to call RAMS successful or
> not. As discussed in the RAMS draft, if RAMS-I or RAMS-T messages get
> dropped in between the receiver and the server, both server and receiver
> should be able to cope with that. However, if there is a gap between the
> burst and the MC, which was not closed despite retransmission
> (attempts), do we still call this a "successful" process from the
> receiver point of view? I tend to say "no", so.. "successful RAMS" would
> mean that the complete RAMS process -including the MC join- was
> succesful, resulting in the fact that all expected RTP data (unicast and
> multicast) was successfully and timely transferred by the RTP end-point
> to the application. This makes of course the "10=RAMS successful, MC
> join unsuccessful" code obsolete.
>
>
> -Subfield Y2 (same size as defined in RAMS draft) containing the
> "Retransmission server response code" Note that for the Y2 field, we
> also need to define a code, when there was no RAMS-I response from the
> server.
>
>
> With the definitions for subfield Y1 as per above, we can make a
> selection of which fields are to be provided mandatory by the RTP
> receiver
>
>
>
> E.g. for normal acquisition process (X= 001),
>
> Only if Y = 1, the following fields shall be present:
> -SN of 1st MC packet
> -delta time between 1st IGMP join and 1st received MC packet
> -(others?)
>
> E.g. for RAMS based acquisition process (X= 011):
>
> Y1 = 11 (Y2 code= "success") where expected fields must be :
>
> -SN of 1st MC packet
> -delta time between 1st RAMS-R and 1st received burst packet
> -delta time between 1st IGMP join and 1st received MC packet
> -(others?)
>
> Y1 = 01 (Y2 code = could be any code!)where expected fields must be :
>
> -SN of 1st MC packet
> -delta time between 1st RAMS-R and 1st received MC packet
> -delta time between 1st IGMP join and 1st received MC packet
> -(others?)
>
>
> Y1 = 00 (Y2 code = could be any code!): no fields are mandatory.
>
>
> What do you think?
>
> Regards
> Tom
>
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: zaterdag 20 juni 2009 0:07
> To: Eric Friedrich (efriedri)
> 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)
>
> 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