Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04

Qin Wu <bill.wu@huawei.com> Fri, 04 November 2011 02:13 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200CF1F0C3D for <avt@ietfa.amsl.com>; Thu, 3 Nov 2011 19:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.346
X-Spam-Level:
X-Spam-Status: No, score=-4.346 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aLY6v5fthFR for <avt@ietfa.amsl.com>; Thu, 3 Nov 2011 19:13:49 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B521F86A1 for <avt@ietf.org>; Thu, 3 Nov 2011 19:13:49 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU400A8766T04@szxga03-in.huawei.com> for avt@ietf.org; Fri, 04 Nov 2011 10:13:42 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU40003W66TSS@szxga03-in.huawei.com> for avt@ietf.org; Fri, 04 Nov 2011 10:13:41 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW18374; Fri, 04 Nov 2011 10:13:41 +0800
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 10:13:35 +0800
Received: from w53375q (10.138.41.130) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 10:13:33 +0800
Date: Fri, 04 Nov 2011 10:13:32 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-id: <060F172CB45D4D49A13B930494895B84@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <4EA12119.4090900@ericsson.com> <0C80BD8E8293426DB3C50CC7F1ECB0F1@china.huawei.com> <F3153DC2249E4F83B5290A559BFC8B80@china.huawei.com> <4EB29BA5.9080509@ericsson.com>
Cc: IETF AVTCore WG <avt@ietf.org>, draft-ietf-avtcore-monarch@tools.ietf.org
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 02:13:50 -0000

----- Original Message ----- 
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "IETF AVTCore WG" <avt@ietf.org>rg>; <draft-ietf-avtcore-monarch@tools.ietf.org>
Sent: Thursday, November 03, 2011 9:48 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04


> Hi,
> 
> Removing all issues that don't need additional discussion or commenting.
> 
> 
> 
> On 2011-10-25 07:45, Qin Wu wrote:
>> 
>> 9. Section 4:
>> "It is also
>>       fixed across multiple RTP sessions from the same source."
>> 
>> I interpret "source" in the above as an end-point or RTP node. Which
>> causes me to have the following comment.
>> 
>> This is very commonly true, but not universally true. As CNAME
>> identifies a synchronziation context, a given end-point could have media
>> sources that belong to multiple synchronization contexts in the same
>> session. For example have microphones and cameras from multiple rooms,
>> where each room will be its own synchronization context.
>> 
>> 
>> 
>> [Qin]: Agree with your thinking, but here what we emphasize is "across multiple RTP session"
>> 
>> Does this really conflict with what you said?
>> 
>> Anyway I will reword this in the new vesion.
>> 

> No, as long as we consider source as media recording device(s) in a
> given synchronization context they will be fixed across multiple sessions.
> 


[Qin]: Okay, do we have other use cases besides the above one you gave?

>> 
>> 12. Section 4. bullet 3:
>> This issues does not have a recommendation in the next section. I think
>> we should document the WG consensus on this issue. Even if it was that
>> this issue wasn't significant enough to do something about. Or am I
>> remembering the WG consensus wrong?
>> 
>> 
>> 
>> [Qin]: Yes, the issue wasn't significant and I remembered the consensus is 
>> 
>> to replace tag with the SSRC and use SSRC to identify and correlate and group
>> 
>>  participants between reports. The sequence numbering information and
>> 
>>  measurement interval can be defined in a new RTCP XR block if needed, 
>> 
>> but is not related to identity. Therefore I will add one section to talk about how to deal with this issue.
>> 
> 
> Thanks, I think it is strange if we don't document the consensus
> resolution when it is listed as an issue.

[Qin]: Yes, I have documented them in the new version 05 I submitted before the deadline.

>> 
>> 21. Section 7.1:
>> 
>> Strictly the RTP end
>>    system can only conclude that its RTP has been lost in the network,
>>    though an RTP end system complying with the robustness principle of
>>    [RFC1122] should survive with essential functions unimpaired.
>> 
>> What is the purpose with this sentence? And what is actually seen as
>> "essential functions"?
>> 
>> 
>> 
>> [Qin]: I think essential functions are referred to as "media distribution"
> 
> So you mean that a robustly built end-point will still be able to send
> its media despite the fact that media it should receive has been lost in
> between the sender and this receiver?

[Qin]: That's my understanding, is that okay with you?

>> 
>> 22. Section 7.2:
>> For bidirectional unicast, an RTP system may usually detect RTCP XR
>>    from a translator by noting that the sending SSRC is not present in
>>    any RTP media packet.
>> 
>> So the assumption here is that the translator has its own SSRC to send
>> these monitoring reports. But, how does an RTP node determine that an
>> SSRC is associated with a translator rather than a receiver only
>> end-point? From a session participant I don't think you can determine if
>> a give SSRC is a receiver or just a monitor. They will not look
>> different. One needs session configuration information, and in that case
>> configuration information where the translator announces its node type
>> to the management system.
>> 
>> 
>> 
>> [Qin]: That's what I want to said in part. And I agree that node type should also be announced.
>> 
>> I will revise the draft to reflect this.
> 
> Ok, I think the new text is good enough.

[Qin]: Thanks.

>> 
>> 23. Section 8. I agree that this draft shouldn't have a IANA
>> Consideration other to say that it is has no actions. However, I think
>> the document should consider if it has some guidance on IANA actions for
>> the monitoring architecture. Some part of this is clearly about the
>> consumption of XR block code points that isn't a major issue. And if we
>> do run out a second RTCP packet type for XR block 2 could be assigned.
>> 
>> 
>> 
>> [Qin]: The WG consensus is space depletion is not issue
>> 
>> if you really want space expansion, you can define one XR block type
>> 
>>  for vendor-specific extensions, with an enterprise number included 
>> 
>> to identify the vendor making the extension. So I prefer to say
>> 
>> "There is no IANA action in this document"
> 
> Yes, but if that is the conclusion, shouldn't we document it?

[Qin]: Okay, I can put them in the new version.

> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>