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

["VAN CAENEGEM Tom" <Tom.Van_Caenegem at alcatel-lucent.be>]

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