Re: [xrblock] ??: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01

[Qin Wu <[e-mail]>]

Thanks Moria.:-)!
Please see my reply to your last comment.

Regards!
-Qin
----- Original Message ----- 
From: "Mario Montagud Climent" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>; "Huangyihong (Rachel)" <[e-mail]>; "Hitoshi Asaeda" <[e-mail]>
Sent: Monday, November 26, 2012 9:43 PM
Subject: Re: ??: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01


>>>> - For both XR blocks defined in this draft, it is stated that: "If the
>>>> measurement is unavailable, the value of this field with all bits set
>>>> to 1 SHOULD be reported". But, if the measurements are unavailable,
>>>> why these XR blocks are needed? Would not it be better to simply not
>>>> sending these XR blocks?
>>>>
>>>> [Qin]: these XR block may be sent in each RTCP report interval, if
>>>> we not send them to the receiver of XRBLOCK,
>>>> the receiver will regard these XRBLOCK are lost, which is not what
>>>> we expected.
>>>>
>>>> - Finally, we think that this draft should indicate when the proposed
>>>> XR blocks are sent. Should the RFISD block be sent only once per media
>>>> session? Should the RFSO block be sent in each RTCP report interval in
>>>> a compound RTCP packet?
>>>>
>>>> [Qin]: For RFISD, both allows, but I think it more makes sense to
>>>> send only once per media session.
>>>
>>>
>>> [F & M] We assume that these RTCP report blocks will be sent in
>>> compound RTCP packets. Regarding the RFSI block, we assume that it is
>>> only needed once per session (since it reports on INITIAL Sync Delay,
>>> it is not needed during the session lifetime). Regarding the RFSO
>>> block, we think that two options could be employed: 1) to send this
>>> block in each RTCP report interval, independently of the value of the
>>> "sync offset"; 2) to send this block only if the value of the "sync
>>> offset" exceeds a configurable allowed asynchrony threshold.
>>>
>>> Therefore, if these XR blocks are not included in the received RTCP
>>> compound packet, we think it can be assumed that the metrics these
>>> blocks report on are not available, without the need of sending the
>>> block reports (because in such a case, these reports do not contain
>>> any further statistics).
>>
>> [Qin]: What about these RTCP report block is not sent in the  
>> compound RTCP packet?
>>
> 
> [F&M] Do you mean sending these reports as immediate and reduced-size  
> RTCP packets?

[Qin]: You misunderstand what I said. Sorry for bringing you confusion.
I think for the option 1) to send this
block in each RTCP report interval, independently of the value of the
"sync offset", the RTCP report block MUST be sent to the XR BLOCK receiver 
in each report interval, otherwise XR Block receiver will assume RTCP report block is
lost rather than measurement is not available, one extreme case, is all the XR report blocks 
carried in the same compound packet is lost. So if the sender of XR block fail to measure
 the results, the sender of XR block still send
the XR report block with all bits set to 1 to show that the measurement is available.

However for option 2) you mentioned, i.e., to send this block only if the value of the "sync
offset" exceeds a configurable allowed asynchrony threshold. In this case, I agree with you
the XR Block sender can choose not to send report block in the Compound packet.

We will think about whether we should support only option 1 ) or need to support both option1) and option 2).


> Best Regards,
> 
> Fernando & Mario
> 
> 
>>>
>>> Best Regards,
>>>
>>> Fernando & Mario.
>>>
> 
> 
>