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

Qin Wu <bill.wu@huawei.com> Tue, 27 November 2012 02:37 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8460521F8499 for <xrblock@ietfa.amsl.com>; Mon, 26 Nov 2012 18:37:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.846
X-Spam-Level:
X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jxx6xUafmD0 for <xrblock@ietfa.amsl.com>; Mon, 26 Nov 2012 18:37:32 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDA3E21F8466 for <xrblock@ietf.org>; Mon, 26 Nov 2012 18:37:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANF00522; Tue, 27 Nov 2012 02:37:29 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 02:37:20 +0000
Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 02:37:26 +0000
Received: from w53375 (10.138.41.149) by szxeml451-hub.china.huawei.com (10.82.67.194) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 10:37:12 +0800
Message-ID: <9D19CE70D13C442A903465C9CCB5FDD2@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Mario Montagud Climent <mamontor@posgrado.upv.es>
References: <51E6A56BD6A85142B9D172C87FC3ABBB4438F1AB@szxeml539-mbx.china.huawei.com> <20121103195158.715146ywbr8lhqz2@webmail.upv.es> <B8F9A780D330094D99AF023C5877DABA4304850D@szxeml523-mbx.china.huawei.com> <20121108203028.18646pziiczpi6vo@webmail.upv.es> <4DA06E997ACD400DA0B6B2D1E9948078@china.huawei.com> <20121126144319.111456x6edehp5o7@webmail.upv.es>
Date: Tue, 27 Nov 2012 10:37:12 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: xrblock@ietf.org
Subject: Re: [xrblock] ??: Comments on draft-ietf-xrblock-rtcp-xr-synchronization-01
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2012 02:37:32 -0000

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

Regards!
-Qin
----- Original Message ----- 
From: "Mario Montagud Climent" <mamontor@posgrado.upv.es>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: <xrblock@ietf.org>rg>; "Huangyihong (Rachel)" <rachel.huang@huawei.com>om>; "Hitoshi Asaeda" <asaeda@sfc.wide.ad.jp>
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.
>>>
> 
> 
>