Subject: [xrblock] Fw: I-D Action: draft-asaeda-xrblock-rtcp-xr-synchronization-03.txt

From: Fernando Boronat Seguí <[email-masked]>
Date: Fri, 10 Feb 2012 11:07:38 +0100

Hi all,

We (my colleague Mario Montagud and me) have reviewed 
draft-asaeda-xrblock-rtcp-xr-synchronization-03 and we think this draft 
is very interesting because the XR blocks proposed in it can be very 
useful for synchronization in layered video sessions and in correlated 
multimedia sessions.

Here you are our comments and suggestions:

We find a bit confusing the descriptions of the ‘Initial Synchronization 
Delay’ field in the Initial Synchronization Delay Report Block, and the 
‘General Synchronization Offset of packet I’ field in the Initial 
Synchronization Delay Report Block. Maybe example of uses cases and of 
how calculate these metrics could help the readers to better understand 
these fields and the utilities of the blocks.

The number of packets for which the general Synch Offset is included in 
the Initial Synchronization Delay Report Block could be discussed and 
some cases could be presented. Why more than one packet? Why the ens_seq 
field is the ‘The last sequence number that this block reports on plus 
one’ and not the ‘The last sequence number that this block reports on’?

Some text indicating who are the originators/senders of the new defined 
block reports could also be included. “This new report block will be 
sent by …. to allow/report …”.

As the draft defines 2 new independent report blocks (i.e. Initial Sync 
Delay and General Sync Offset), the abstract and introduction sections 
should be adapted accordingly (this document defines AN RTCP XR Report … 
this draft defines A NEW BLOCK TYPE …).

The draft includes a new metric block for reporting Synchronization 
Offset Time of each RTP stream relative to a reference RTP stream. It is 
not necessary but, maybe, some reference to any mechanism to select that 
reference (i.e. master) stream to synchronize with could be included.

The sentence “…beyond the information carried in the standard RTCP 
packet format” is repeated too many times in the draft. Maybe it could 
be avoided in most of the sentences.

Section 1.

offset status “of an arbitrary two streams” -> offset status “between 
two arbitrary streams”

“with the same CNAME in the multimedia session” -> “with the same CNAME 
item included in RTCP SDES packets [RFC3550]”

Section 3

(line 12)
For multicast session, such initial synchronization delay varies with 
the session bandwidth and the number of members, the number of senders 
in the session. -> For multicast session, such initial synchronization 
delay varies with the session bandwidth, the number of members, and the 
number of senders in the session.

Section 4

(line 3) Remove the duplicated “the”.

Section 4.2 and Section 5.2

SSRC of source field: Capitalize the verb shall -> SHALL

(Page 7, line 6) between AN arbitrary…

“… to equal to…” -> to be equal to

Section 5.

“…in a separate RTP streams” -> “…in a separate RTP stream”

It should be better to separate the first paragraph into two paragraphs. 
The second one should begin with the sentence: “This new block reports 
the general …”

The rest of the document looks nice for us.

Regards from Spain

Fernando & Mario.

>   >  A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >  Title           : RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting
> >  Author(s)       : Hitoshi Asaeda
> >                           Rachel Huang
> >                           Qin Wu
> >  Filename        : draft-asaeda-xrblock-rtcp-xr-synchronization-03.txt
> >  Pages           : 10
> >  Date            : 2012-02-02
> >
> >    This document defines an RTCP XR Report Block and associated SDP
> >    parameters that allow the reporting of synchronization delay and
> >    offset metrics for use in a range of RTP applications.
> >
> >
> >  A URL for this Internet-Draft is:
> >  http://www.ietf.org/internet-drafts/draft-asaeda-xrblock-rtcp-xr-synchronization-03.txt
> A few update to Synchronization Delay and Offset XR Block draft. This draft is used to report
> initial synchronization delay to establish multimedia session and synchronization offset between
> RTP streams that belong to the same multimedia session. We think this draft is well cooked and
> ready for Chairs review and moving forward.
>

-- 
Saludos/Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 24 Feb 2012 01:40:51 +0900 (JST)

Hi Fernando,

Sorry for late reply.

> draft-asaeda-xrblock-rtcp-xr-synchronization-03 and we think this
> draft is very interesting because the XR blocks proposed in it can be
> very useful for synchronization in layered video sessions and in
> correlated multimedia sessions.

Thank you for your interests and support.

> We find a bit confusing the descriptions of the ‘Initial
> Synchronization Delay’ field in the Initial Synchronization Delay
> Report Block, and the ‘General Synchronization Offset of packet I’
> field in the Initial Synchronization Delay Report Block. Maybe example
> of uses cases and of how calculate these metrics could help the
> readers to better understand these fields and the utilities of the
> blocks.

Do you think the example specified in Applicability section
(i.e. Section 3) is not sufficient?
Regarding how calculate these metrics, we think section 4.2 and
section 5.2 describe it.
If additional text makes readers understand clearer, we will add it.
If you find something to be added, please tell us.

> The number of packets for which the general Synch Offset is included
> in the Initial Synchronization Delay Report Block could be discussed
> and some cases could be presented. Why more than one packet?

I may not understand this question correctly, but general Synch Offset
can be reported based on only one packet.

> Why the
> ens_seq field is the ‘The last sequence number that this block reports
> on plus one’ and not the ‘The last sequence number that this block
> reports on’?

This follows the example format of Loss RLE Report Block defined in
RFC3611. In this case, the number of packets to be reported on can be
easily calculated by subtracting begin_seq from end_seq.

> Some text indicating who are the originators/senders of the new
> defined block reports could also be included. “This new report block
> will be sent by …. to allow/report …”.

Thank you for your suggestion.
We have submitted the revised draft that includes this.

> As the draft defines 2 new independent report blocks (i.e. Initial
> Sync Delay and General Sync Offset), the abstract and introduction
> sections should be adapted accordingly (this document defines AN RTCP
> XR Report … this draft defines A NEW BLOCK TYPE …).

Done, thanks.

> Offset Time of each RTP stream relative to a reference RTP stream. It
> is not necessary but, maybe, some reference to any mechanism to select
> that reference (i.e. master) stream to synchronize with could be
> included.

Good suggestion.
We added "Synchronization offset" in the ternimology section.

> be avoided in most of the sentences.

Done. Thanks.

> offset status “of an arbitrary two streams” -> offset status “between

We changed to "offset time of two arbitrary streams (e.g., between
audio and video streams)".

> “with the same CNAME in the multimedia session” -> “with the same
> CNAME item included in RTCP SDES packets [RFC3550]”

Done.

> delay varies with the session bandwidth, the number of members, and
> the number of senders in the session.

Done.

> (line 3) Remove the duplicated “the”.

Done.

> SSRC of source field: Capitalize the verb shall -> SHALL

Done.

> “… to equal to…” -> to be equal to

Done.

> “…in a separate RTP streams” -> “…in a separate RTP stream”

Done.

> It should be better to separate the first paragraph into two
> paragraphs. The second one should begin with the sentence: “This new
> block reports the general …”

Done.

> The rest of the document looks nice for us.

Thank you for your review.

Regards,
--
Hitoshi Asaeda