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