Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc

Julius Friedman <juliusfriedman@gmail.com> Mon, 15 December 2014 14:53 UTC

Return-Path: <juliusfriedman@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490E21A3BA7 for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 06:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbMSxGZJtceE for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 06:53:06 -0800 (PST)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF4F1A1B64 for <avt@ietf.org>; Mon, 15 Dec 2014 06:53:06 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id v10so11773148pde.15 for <avt@ietf.org>; Mon, 15 Dec 2014 06:53:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=as3WjaBLyOc4ASUOUmJr1GY+wiey9Q2N0s2rVuS3NRE=; b=dQHDoHftiiTklf8N1d4XNsZKFI8RpoIxqYK3yf6cdLpkOW3yrePDTemZ48yMyZc3tq VwF3VvPqm6mdDrF5OcsSxNMHzB0hjFdoP6LQLH5HfEVfz261x3TFaX1M5qE1/q3kXoMz 2HLvnlrk+rgCFkbFRQrtD1/yFZ0bb0ns2VRq9j8zdbSEdC+h49jhJGy9j9X1N8zlQ2ue qGKpBctd1zh+AOeGHW924OTkkPE0OO56Jd7slu0m49Uow5vTbPDJsCQnirdDG23iyOm2 GJT3fOuPVQ8SyPRK4rVnFvokn43Z5MQ7BKdy4V9fOHMEP9IF78WBLl+/LGWK8pG6/S/T V6iA==
MIME-Version: 1.0
X-Received: by 10.68.251.37 with SMTP id zh5mr32617190pbc.120.1418655185724; Mon, 15 Dec 2014 06:53:05 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 06:53:05 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 06:53:05 -0800 (PST)
In-Reply-To: <B1289322-A9FE-4EB1-BAFE-B53B8B57E2CB@tno.nl>
References: <CACFvNHXLk2+2h2wYtTOR-uJm=AB7coBO8O9EQkT44yeZsA5UQA@mail.gmail.com> <CACFvNHWu8Yqs4fccjn4nBiypqXxvDdiDDmR7B=va-Fjnpmff8g@mail.gmail.com> <B1289322-A9FE-4EB1-BAFE-B53B8B57E2CB@tno.nl>
Date: Mon, 15 Dec 2014 09:53:05 -0500
Message-ID: <CACFvNHW-unBgBF=nsNW7EPd+-5-4=_y_00eBCg-6_TVLJooODA@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>, avt@ietf.org
Content-Type: multipart/alternative; boundary="047d7b5d4ddc676d8f050a426665"
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/uq0IER0yzzShMOShvgFxwduQSgU
Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 15 Dec 2014 14:53:09 -0000

I'll check out that section and re-write in if necessary.

One thing on your response I have to clarify.
The sr allowed this synchronization.

The reference clock is virtually set to the time difference between the ntp
timestamp in the sender report and the receiver.

That's seems synchronized to me.

What difference does it make if his clock is wrong? Furthermore if sender
uses a clock on mars.

Can you succinctly state why we need to know more details about clock rate
than already available 20 years later?

How does my application benefit from this?

Furthermore it seems dynamic clock rates are not addressed.

Thanks for responding.
On Dec 15, 2014 3:11 AM, "Brandenburg, R. (Ray) van" <
ray.vanbrandenburg@tno.nl> wrote:

>  Hi Julius,
>
>  Thanks for your constructive and positively-formulated feedback.
>
>  I advise you to read section 2 on Applications. It will answer most of
> your questions.
>
>  Furthermore, you seem to have missed a number of aspects:
>
>  - There is a difference between a media clock and a reference clock. I
> don’t see how any RTP profile or current SDP is going to help you to know
> which reference clock you’re using. Without that information, how are you
> going to synchronize two different receivers?
> - There is a difference between specifying a media clock rate (which is
> done in an RTP profile) and specifying how that clock rate is determined.
>
>  If you have any more questions, I encourage you to voice your opinion on
> the AVT mailing list.
>
>  Best regards,
>
>  Ray
>
>
>   From: Julius Friedman <juliusfriedman@gmail.com>
> Date: Sunday 14 December 2014 18:37
> To: "draft-ietf-avtcore-clksrc@tools.ietf.org" <
> draft-ietf-avtcore-clksrc@tools.ietf.org>
> Subject: Mail regarding draft-ietf-avtcore-clksrc
> Resent-To: "aidan.williams@audinate.com" <aidan.williams@audinate.com>, <
> hans.stokking@tno.nl>, Kevin Gross <kevin.gross@avanw.com>, Ray van
> Brandenburg <ray.vanbrandenburg@tno.nl>
>
>   What is the purpose of this rfc?
>
> After reading it several times I just cannot come to terms with anything
> it suggests.
>
> Rfc 3550 conveys the ntp time information via rtcp et al.
>
> There is no reason to signal rate of media in sdp beyond where each rtp
> profile registered has a default clock rate assigned especially when the
> document provides no mechanism to align the clocks in which it declared
> might not be synchronized. (Even though that is the purpose of ntp... )
>
> Here is a simple explanation.
> http://www.cs.columbia.edu/~hgs/rtp/faq.html#sr-timestamp
>
> Furthermore each implementation already has the clock rate as a parameter
> of the rtpmap or fmtp or the profile default is used.
>
> This document makes sdp content longer and more complex without any added
> benefit or explanation of the mechanism introduced.
>
> Lastly Video walls wouldn't need a specified rate to work as they would
> have their own rate and update displays based on that rate.
>
> Any such required information would be an optimiZation to their display
> driver through the operating system, do you really want a rtp sender to be
> able to control the clock rate of your display? If you do use snmp or
> something else.
>
> Things have worked like this for as long as rtp has been specified and
> thus this rfc only allows information to be given which is redundant given
> the fact a profile which would be required for playback through
> depacketization anyway.
>
> This document also makes no change to any calculation used by a receiver
> or sender.
>
> It is for all intents and purposes useless.
>
> Please feel free to correct me.
>
> Sincerely,
> Julius Friedman.
>
>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>