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

"Stokking, H.M. (Hans)" <hans.stokking@tno.nl> Wed, 17 December 2014 14:39 UTC

Return-Path: <hans.stokking@tno.nl>
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 37D6C1A8A7D for <avt@ietfa.amsl.com>; Wed, 17 Dec 2014 06:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.115
X-Spam-Level:
X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 a12ehaFM5imz for <avt@ietfa.amsl.com>; Wed, 17 Dec 2014 06:39:49 -0800 (PST)
Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0571A8547 for <avt@ietf.org>; Wed, 17 Dec 2014 06:39:47 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.07,594,1413237600"; d="scan'208,217"; a="35489850"
Received: from exc-cashub01.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 17 Dec 2014 15:39:46 +0100
Received: from EXC-MBX01.tsn.tno.nl ([fe80::fd60:358a:bfaf:ca7c]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 15:39:46 +0100
From: "Stokking, H.M. (Hans)" <hans.stokking@tno.nl>
To: Julius Friedman <juliusfriedman@gmail.com>, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc
Thread-Index: AQHQF8TJWEXFH0YOUkmBG9lIjGA0C5yQPTkAgAOZt06AAAZ6QA==
Date: Wed, 17 Dec 2014 14:39:45 +0000
Message-ID: <7F110B3ECC623C4EADDEB82154F2693D1353A8FD@EXC-MBX01.tsn.tno.nl>
References: <CACFvNHXLk2+2h2wYtTOR-uJm=AB7coBO8O9EQkT44yeZsA5UQA@mail.gmail.com> <CACFvNHWu8Yqs4fccjn4nBiypqXxvDdiDDmR7B=va-Fjnpmff8g@mail.gmail.com> <B1289322-A9FE-4EB1-BAFE-B53B8B57E2CB@tno.nl> <CACFvNHW-unBgBF=nsNW7EPd+-5-4=_y_00eBCg-6_TVLJooODA@mail.gmail.com> <CALw1_Q2QF71goA_W9AVmSrHEMA4yuPSW2vZhYSmu1uQ5p21pWw@mail.gmail.com> <CACFvNHVdBS_sAMjB=N2Ok1R-K9XV4oyri2Q+U-t0AhxyENu-Gg@mail.gmail.com> <FCC100FC8D6B034CB88CD8173B2DA1582031BBFD@EXC-MBX03.tsn.tno.nl> <CACFvNHX9WDgyVL+6crNaXB99ry0+qjSJPnmbn3b6EER2wD9OCw@mail.gmail.com> <FCC100FC8D6B034CB88CD8173B2DA1582031DB12@EXC-MBX03.tsn.tno.nl> <CACFvNHXs+rzoomzfueBKSTWe8noNAjgyVsknq-YnNF9vmqZ00A@mail.gmail.com> <27CF275E-2456-4D18-BB25-75E147411214@tno.nl> <CACFvNHUtz08SjdrhY6e2AokECxM0FK8YepsVcuT=TPwv78f=2A@mail.gmail.com>
In-Reply-To: <CACFvNHUtz08SjdrhY6e2AokECxM0FK8YepsVcuT=TPwv78f=2A@mail.gmail.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.221.225.153]
Content-Type: multipart/alternative; boundary="_000_7F110B3ECC623C4EADDEB82154F2693D1353A8FDEXCMBX01tsntnon_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/zSfvOCDu6X2Xq7W-clpAZYVf0Bk
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: Wed, 17 Dec 2014 14:39:54 -0000

Hi Julius,

Just a question: where does all this come from?

You are being quite aggressive in the e-mails to this list (at least, that’s how your language comes across to me), somewhat out-of-the-blue. All these RFCs have gone through the processes within the IETF, and thus quite some knowledgable people have done extensive reviews on them.

I’m just trying to understand why you are acting the way you are: you are being quite rude (again, that’s how you come across to me) to people who take the time and effort to work together in the IETF process. This is not helping you, in that it doesn’t make people want to help you (again, that is just my guess, if this is true, I don’t know).

Cheers, Hans

From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Julius Friedman
Sent: woensdag 17 december 2014 15:10
To: Brandenburg, R. (Ray) van; avt@ietf.org
Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc


Ntp synchronized receivers.

This mechanism is additional and allows for more error for the reasons I already stated.

You can synchronize with rtcp alone.

Additionally if my speakers are not ip compatible then your notion and reference makes little sense.

There is no reason for a new sdp line and new semantics for clocks without properly defining the scenarios i have outlined and their resulting effects on existing systems.

Hence my position is unchanged.
On Dec 17, 2014 8:51 AM, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>> wrote:
Hi Julius,

>Disagree all you like, until you can articulate a succinctly defined scenario which also handles the issues I cite then I will file errata for them and will not comply with them until such time.

The decision whether to comply or implement this RFC is completely up to you. Nobody is forcing you to implement something you don’t think is necessary. Implementing any RFC is optional, including this one. If you don’t agree with the use case or solution provided, no problem, don’t implement it

>The latter scenario is made up

No, it’s not. As an example: http://en.wikipedia.org/wiki/AES67. This is an A/V Networking  specification that is implemented and used by a number of companies, as announced in various public press releases. The clock source RFC that we’re discussing here is a normative reference in that specification. Another example is RFC7272, which present a solution for synchronising playback on different receivers.

Ray



From: Julius Friedman <juliusfriedman@gmail.com<mailto:juliusfriedman@gmail.com>>
Date: Wednesday 17 December 2014 14:29
To: Ray van Brandenburg <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>>
Subject: RE: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc


Ray / AVT

On Dec 17, 2014 4:10 AM, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>> wrote:
>
> Hi Julius,
>
> Unfortunately I disagree.
>
> Rtp connected speakers dont have to be synchronized to each other. If they did each speaker would adhere to the spec as it's own reciever and handle loss as indicated in the standard.  They could also have their own mechanism for synchronicity as provided by the transport layer.
>
> This is not about loss. This is not about the transport layer. This is about making sure that if I have a room in which I have multiple RTP-connected speakers, they all play out the audio or video at exactly the same time. How would the transport layer help with that?

Ntp helps with this.  Each speaker would recieve data from a mixer and would play out.

How will knowing the clock rate of the media prevent a unit from malfunction?

What if someone spilled something?  Or there was interference?

What is knowing the clock rate going to do for you then?

Lastly how come that scenario isnt made use of in the draft and instead we have examples with video walls and iptv systems which have their own mechanism for clocks.

>
> The scenario is no different than a conference where all the participants are spread out over vast distances or routes with congestion.
>
> No, it’s not. There is a difference between a scenario where the primary goal is low-delay (conference systems) and a scenario where the primary goal is high quality and synchronicity, in which adding a few seconds of delay to make sure everything is synchronized is acceptable. You seem to be focused on the former, without considering the latter scenario.
>

The latter scenario is made up, and if I didn't consider it I wouldn't feel so strongly about it.

Just because your proprietary system benefits from this doesn't mean mine will nor that I will want to take measures to comply with something which raises several concerns which are not addressed.

> There is no reason to obtain or know the clock rate other than how it had already been specified because the senders report provides this functionality for multiple streams and single streams.
>
> No, it doesn’t. The SR doesn’t specify a reference clock, not its source. All it does  is specify at what time a specific sample was sent.
>

The ntp tells you a reference clock of the sender and also tells you that the rtptimestamp belongs to that time.

How are you calculating jitter and transit?

Wont those still be applied?

> Doing so in the manner specified by this draft is not backwards compatible and provides nothing to prevent the clock rate from changing right after it has been conveyed.
>

The clock source which may not be accessible,  correct or ever change reference or rate?

> That is ­_exactly_ the reason why we don’t convey the clock rate but communicate the clock source. And I don’t see how making use of this RFC has any impact on backwards compatibility.
>

Its easy,  if I didn't need to look for or account for the source now and now I need to this is not compatible.

Also since you don't specifically define how changes are handled in the clock among other issues i brought up.

> There is no benefit, we didn't need this mechanism 20 years ago and we certainly dont now.
>
> Thanks for sharing your opinion. I disagree.
>

The facts are still the facts.

I have worked with several types of video walls and iptv systems.

In no aspect did a source clock ever come up or present itself as an issue.

I would have loved to hear how this solves an issue in real life rather then made up scenarios.

I could also argue that each speaker could have it's own dynamic content and due to handicap or special content not require the same play out as other speakers.

Disagree all you like, until you can articulate a succinctly defined scenario which also handles the issues I cite then I will file errata for them and will not comply with them until such time.

Sincerely,
Julius Richard Friedman

> Ray
>
> Because of those reasons as well as the others i have cited my position is firm until a succinctly defined scenario is defined in which prior mechanisms fail or it is shown a clear and hassle free benefit of complying with this draft.
>
> After all if I ignored it I would play data the exact same way as if it was in use.
>
> The sr would adapt receiver losses as it always has.
>
> This might be better as some informational document and even then I question its applicability in face of existing mechanisms which are better defined and more reliable.
>
> Sincerely,
> Julius Richard Friedman
>
> On Dec 16, 2014 11:02 AM, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl<mailto:ray.vanbrandenburg@tno.nl>> wrote:
>
> Hi Julius,
>
>
>
> I think we’re talking about two different use cases. The use you seem to have in mind is one where the issue at hand is synchronization of two or more streams on a single device. For that purpose, you’re right that it doesn’t matter which clock you’re using (as you mention, it might as well be a Mars-based one).
>
>
>
> The use case that is discussed in the RFC is where you have multiple receivers and where the goal is to make sure that the streams being played out are synchronized between the various receivers. Imagine a stadium where you have multiple RTP-connected speakers. In that case, it is very important that the reference clock they are using is the same, or at least that you know the offset between those clocks.
>
> > This literally makes no sense because even if I knew what clock the sender was using I might not be able to access it.
>
> Well, this draft solves the former problem, knowing which clock the sender was using. Not having access to that particular server is another problem altogether. As long as that is not the case in the overwhelming majority of the cases, I don’t think that is reason to disqualify this work.
>
>
>
> Ray
>
>
>
> From: avt [mailto:avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>] On Behalf Of Julius Friedman
> Sent: maandag 15 december 2014 17:37
> To: Kevin Gross; avt@ietf.org<mailto:avt@ietf.org>
> Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc
>
>
>
> This literally makes no sense because even if I knew what clock the sender was using I might not be able to access it.
>
> What if there is confusing information about a source?  E.g. its true identity.
>
> How is this any better then just adjusting to the sender's time any why..
>
> After all the sender could just as well switch clocks again.
>
> Multiple streams are combined by a mixer and hence the mixer accounts for the rate adjusting if required to mix each sample.
>
> This doesn't really help a mixer perform that function any easier for the reasons stated and only would under situations where it was designed to.
>
> Receivers using legacy algorithms or profiles would still be able to do this if required by their system when required based on better information than conveyed as indicated in this draft.
>
> On Dec 15, 2014 11:25 AM, "Kevin Gross" <kevin.gross@avanw.com<mailto:kevin.gross@avanw.com>> wrote:
> >
> > The timestamp in SRs is NTP format but RFC 3550 does not require you to get those time stamps from a specific clock. This RFC (7273) allows you to signal what clock you're using so senders and receivers can synchronize. Prior to RFC 7273, receivers made undisclosed assumptions about clocks or simply adjusted empirically to whatever clocking the sender is doing. The improvement here is to have a common clock for multiple senders so that streams can be readily combined at a receiver that is receiving multiple streams from different senders.
> >
> > Kevin Gross - AVA Networks
> >
> > On Mon, Dec 15, 2014 at 7:53 AM, Julius Friedman <juliusfriedman@gmail.com<mailto:juliusfriedman@gmail.com>> wrote:
> >>
> >> 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<mailto: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

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.