[AVTCORE] ***SPAM*** 5.977 (5) RE: Mail regarding draft-ietf-avtcore-clksrc
Julius Friedman <juliusfriedman@gmail.com> Wed, 17 December 2014 14:51 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 D50431A8A94 for <avt@ietfa.amsl.com>; Wed, 17 Dec 2014 06:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 5.977
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 zyDrEpVvFabi for <avt@ietfa.amsl.com>; Wed, 17 Dec 2014 06:51:09 -0800 (PST)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CA21A871B for <avt@ietf.org>; Wed, 17 Dec 2014 06:51:08 -0800 (PST)
Received: by mail-pa0-f51.google.com with SMTP id ey11so16619823pad.10 for <avt@ietf.org>; Wed, 17 Dec 2014 06:51:08 -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=Y5rTGIeyf/xVcmM4CxgucGuSIMdTT7KCNHnUTganHWk=; b=nXHRsep7Ji8B58InFMBjrDNpPg25CF2JvKG+mr4/0dN7/SypOxgC8/RIioa3nBcPBG wfL7TrHCXgdtIfeqg0e3Vr2FzgWUugkSk80m/JGSpEO3reMojj2qJxtGNFdglvShXUec nELnsgjEbfyrwq2Dz4KKRvFzB4RJtSvo8qcknELCFj+9WhRfaBAz5tPTV2yvsmlIEsB3 AXWeBFkVLlo6wq9//2jiEQ3wmc9dVRdrqHBHWrOG+hV/CcWQYY5TUwe5Afmk/XPneNVP DPH/gnd5eaPpjIWN5c/puGZ0K74hxX3y7VrLEeyB9iJKh7e8lX+efwFq/X60v/GwM8Ss ZPZw==
MIME-Version: 1.0
X-Received: by 10.70.128.15 with SMTP id nk15mr69428413pdb.121.1418827868110; Wed, 17 Dec 2014 06:51:08 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Wed, 17 Dec 2014 06:51:08 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Wed, 17 Dec 2014 06:51:08 -0800 (PST)
In-Reply-To: <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> <7F110B3ECC623C4EADDEB82154F2693D1353A8FD@EXC-MBX01.tsn.tno.nl>
Date: Wed, 17 Dec 2014 09:51:08 -0500
Message-ID: <CACFvNHXJjLxAYnfgXGCiZH-Y2yCJvOPfRM8ZHZ=kajQPqPOV1w@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: "Stokking, H.M. (Hans)" <hans.stokking@tno.nl>, avt@ietf.org
Content-Type: multipart/alternative; boundary="001a11c3d33c1388ce050a6a9ba7"
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/kesirpA8JJ2nRQaVpATUh2UsrKs
X-Mailman-Approved-At: Wed, 17 Dec 2014 10:03:39 -0800
Subject: [AVTCORE] ***SPAM*** 5.977 (5) RE: 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:51:14 -0000
Well I don't feel I should need to apologize for rudeness which is a matter of interpretation but I will anyway. I am only showing you the same level of respect I received when initially writing in. These issues are legitimate none the less. Im sorry I feel they are in error. My position is unchanged. Its my goal to fix existing issues in the spec and well as simplify it where possible. These documents stand in the way of that goal. With all due respect if they have such expertise and required new mechanisms for points I show as achieved without such then what difference does it make? On Dec 17, 2014 9:39 AM, "Stokking, H.M. (Hans)" <hans.stokking@tno.nl> wrote: > 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> 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> > *Date: *Wednesday 17 December 2014 14:29 > *To: *Ray van Brandenburg <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> 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> 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] On Behalf Of Julius Friedman > > Sent: maandag 15 december 2014 17:37 > > To: Kevin Gross; 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> 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> 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> 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. >
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Julius Friedman
- [AVTCORE] ***SPAM*** 7.478 (5) Re: Mail regarding… Kevin Gross
- [AVTCORE] ***SPAM*** 5.861 (5) RE: Mail regarding… Brandenburg, R. (Ray) van
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Brandenburg, R. (Ray) van
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Simon Perreault
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Marc Petit-Huguenin
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Brandenburg, R. (Ray) van
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-c… Stokking, H.M. (Hans)
- [AVTCORE] ***SPAM*** 5.861 (5) RE: Mail regarding… Brandenburg, R. (Ray) van
- [AVTCORE] ***SPAM*** 5.977 (5) RE: Mail regarding… Julius Friedman
- Re: [AVTCORE] ***SPAM*** 5.977 (5) RE: Mail regar… Dale R. Worley
- [AVTCORE] ***SPAM*** 5.977 (5) RE: RE: Mail regar… Roni Even