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

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 18 Jun 2009 16:17:17 +0200

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. 

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 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 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
-a response code which you have indeed defined and its interpretation
should be dependent on the previously mentioned flag/field
-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).
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)

Regards
Tom

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 18 Jun 2009 08:33:32 -0700

Hi Tom,

Thanks for reading the draft.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN CAENEGEM Tom
> Sent: Thursday, June 18, 2009 7:17 AM
> To: [email-masked]
> Subject: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR"
> (draft-begen-avt-rapid-sync-rtcp-xr-01)
> 
> Hi Ali,
> 
> 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.
> 
> -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

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 19 Jun 2009 12:40:20 +0200

Hi Ali,

Look for "TOM" ...

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: donderdag 18 juni 2009 17:34
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Some comments on " Multicast Acquisition Report Block
Typefor RTCP XR" (draft-begen-avt-rapid-sync-rtcp-xr-01)

Hi Tom,

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

> 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
 
"success", etc).

"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)

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

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

> 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

> 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

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. 

"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.

T,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 19 Jun 2009 10:43:57 -0700

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

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Friday, June 19, 2009 3:40 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR"

---

From: efriedri <[email-masked]>
Date: Fri, 19 Jun 2009 14:00:52 -0400

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
>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf  
>>> Of
>>> VAN CAENEGEM Tom
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 19 Jun 2009 15:07:09 -0700

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

> From: Eric Friedrich (efriedri)
> Sent: Friday, June 19, 2009 11:01 AM
> To: Ali C. Begen (abegen)
> Cc: VAN CAENEGEM Tom; [email-masked]
> Subject: Re: [AVT] Some comments on " Multicast Acquisition Report Block Typefor RTCP XR"

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 22 Jun 2009 18:28:52 +0200

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:[email-masked]] 
Sent: zaterdag 20 juni 2009 0:07
To: Eric Friedrich (efriedri)
Cc: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Some comments on " Multicast Acquisition Report Block

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

> >> Subject: RE: [AVT] Some comments on " Multicast Acquisition Report 
> >> Block Typefor RTCP XR" (draft-begen-avt-rapid-sync-rtcp-xr-01)
> >>
> >> Hi Tom,
> >>

> >>> Of VAN CAENEGEM Tom
> >>> Subject: [AVT] Some comments on " Multicast Acquisition Report 
> >>> Block
> >> Typefor RTCP XR"
> >>> 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
> >> 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
> >>>
> >> "TOM" : OK, but most codes only apply to a rapid acquisition 
> >> process, so it makes sense to indicate additionally whether 
> >> "normal" or "rapid"
> >>> 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
> >>
> >> "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.
> >>

> >>> acquisition (based on SFGMP) or rapid MC RTP acquisition (or 
> >>> rather the intention by the RR to perform  a rapid
> >> 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
> >>>
> >> 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")
> >> "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
> >>> processes and fit in the base report, but they should be 
> >>> application independent (e.g. delta to presentation time is 
> >>> clearly app
> >>> dependent)
> >>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 26 Jun 2009 10:27:29 -0700

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

> Sent: Monday, June 22, 2009 9:29 AM
> To: Ali C. Begen (abegen); Eric Friedrich (efriedri)
> Cc: [email-masked]