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

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 03 November 2011 13:48 UTC

Return-Path: <magnus.westerlund@ericsson.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 269E011E811F for <avt@ietfa.amsl.com>; Thu, 3 Nov 2011 06:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.579
X-Spam-Level:
X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 evdwhfqrVmPU for <avt@ietfa.amsl.com>; Thu, 3 Nov 2011 06:48:29 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0106711E8087 for <avt@ietf.org>; Thu, 3 Nov 2011 06:48:28 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-a9-4eb29ba6f865
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.C1.13753.6AB92BE4; Thu, 3 Nov 2011 14:48:23 +0100 (CET)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 3 Nov 2011 14:48:22 +0100
Message-ID: <4EB29BA5.9080509@ericsson.com>
Date: Thu, 3 Nov 2011 14:48:21 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>
References: <4EA12119.4090900@ericsson.com> <0C80BD8E8293426DB3C50CC7F1ECB0F1@china.huawei.com> <F3153DC2249E4F83B5290A559BFC8B80@china.huawei.com>
In-Reply-To: <F3153DC2249E4F83B5290A559BFC8B80@china.huawei.com>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: IETF AVTCore WG <avt@ietf.org>, "draft-ietf-avtcore-monarch@tools.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: Thu, 03 Nov 2011 13:48:30 -0000

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.


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

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

> 
> 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 reflect the draft to reflect this.

Ok, I think the new text is good enough.

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


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