Re: [AVT] Review of draft-brandenburg-avt-rtcp-for-idms-02

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 26 November 2010 10:43 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0689D3A6A10 for <avt@core3.amsl.com>; Fri, 26 Nov 2010 02:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.554
X-Spam-Level:
X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2waK6hnZU2+X for <avt@core3.amsl.com>; Fri, 26 Nov 2010 02:43:45 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C02173A686D for <avt@ietf.org>; Fri, 26 Nov 2010 02:43:44 -0800 (PST)
X-AuditID: c1b4fb3d-b7b8cae0000016b1-db-4cef8f9f6d16
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.05.05809.F9F8FEC4; Fri, 26 Nov 2010 11:44:47 +0100 (CET)
Received: from [147.214.183.21] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Fri, 26 Nov 2010 11:44:47 +0100
Message-ID: <4CEF8F9E.9060900@ericsson.com>
Date: Fri, 26 Nov 2010 11:44:46 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: "draft-brandenburg-avt-rtcp-for-idms@tools.ietf.org" <draft-brandenburg-avt-rtcp-for-idms@tools.ietf.org>
References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBA920@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBA920@xmb-sjc-215.amer.cisco.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVT] Review of draft-brandenburg-avt-rtcp-for-idms-02
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 26 Nov 2010 10:43:46 -0000

Hi,

As Ali provided his feedback on this I can provide my high level points
about the proposal and what I think needs fixing if one goes forward
with an IETF version. I think it makes sense to produce a specification
for this.

1. Use the appropriate RTP and RTCP mechanisms. RTCP XR is a good match
for the report about how the reception and playback point are in
relation to NTP from the receiver to the master. However, information on
when a particular RTP TS should be played in relation to the master
clock I don't find RTCP XR a suitable mechanism. I see that a new RTCP
message type for dynamic configuration of playback, or an RTP header
extension seems a better match.

2. There is need to have a architectural discussion around how the
common clock is distributed to the session participants. First of all
different NTP servers have different precision and different path
characteristics. In addition there is in fact different clocks being
distributed on different servers and their lower stratas. For example
here in sweden there is swedish time produced by a governmental agency.
Yes, it has a certain relation to the UTC, and the clocks used for
swedish time do contribute to UTC. But there exact relation can only be
known after the fact.

As one goes down the stratas it is likely that one has bigger
variations. Adding in the path variations it is quite likely that
peoples clock are actually off with more than a few ms (which seems to
be a reasonable precision requirement) even if running NTP. Thus there
might be need to discuss what a suitable architecture are and how to
handle clock sources. Should one run against a common clock, or should
one try to determine what the differences are etc.


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