Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 07 May 2013 11:47 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 922B221F8EFE for <avt@ietfa.amsl.com>; Tue, 7 May 2013 04:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.892
X-Spam-Level:
X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, 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 LN+oN7nlbWXp for <avt@ietfa.amsl.com>; Tue, 7 May 2013 04:47:51 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1305821F8EB1 for <avt@ietf.org>; Tue, 7 May 2013 04:47:50 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-35-5188e9e5d172
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6C.AB.01956.5E9E8815; Tue, 7 May 2013 13:47:50 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 7 May 2013 13:47:49 +0200
Message-ID: <5188E9E4.8050904@ericsson.com>
Date: Tue, 07 May 2013 13:47:48 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Kevin Gross <kevin.gross@avanw.com>
References: <5163DF09.7050606@ericsson.com> <CALw1_Q08JKDV9W8yCiTa_+thX1NodzUojbrPjTzt4vAR9wKLrw@mail.gmail.com> <517636E0.2020607@ericsson.com> <CALw1_Q3cAy3-9xHGQ0xOoig3ZCiP_O-4rDf0_nndCY2pMwxXrA@mail.gmail.com> <5187C204.1060907@ericsson.com> <CALw1_Q1MhZ1oj90xOnpzmT3o_nGdVX6M7jMZNDKzoihn21YjNg@mail.gmail.com>
In-Reply-To: <CALw1_Q1MhZ1oj90xOnpzmT3o_nGdVX6M7jMZNDKzoihn21YjNg@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvfZy45Ag80neCxe9qxkt3hxqJ3N gcnj39XtzB5LlvxkCmCK4rJJSc3JLEst0rdL4MroX3qdpWBBfMWmmYoNjI89uhg5OSQETCTm bTrBBGGLSVy4t56ti5GLQ0jgFKPE74f9zBDOMkaJT6dWs4BU8QpoS8x89gLI5uBgEVCR+P4t CiTMJmAhcfNHIxtIWFQgWGJrawxEtaDEyZlPwDpFBNQlHu16CLaLWUBJYu7S18wgtrCAvcTb ywdZIFbtYpLoX/WBDSTBKRAoceH7P2aI4yQltrxoZ4do1pOYcrWFEcKWl2jeOhusRgjotIam DtYJjEKzkOyehaRlFpKWBYzMqxjZcxMzc9LLzTcxAgP14JbfBjsYN90XO8QozcGiJM6bzNUY KCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExsdvX6bDd3q8PVHZqnC26lJ18PX41B9Oc7l1G uuudexl+T15zPUtjm5mm5+wPJguPbHZ8p6q4caou3/LMI+8+z3ZavGbjBdbZntv7JAT/ydku z70utu41i6RGjoh0PEfKJZMwjaPbN846EBv6qPbZvyM6V+c8lq+ddnyhV+f3jJWf5pi/lIyS UWIpzkg01GIuKk4EAEsn4AEiAgAA
Cc: IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03
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: Tue, 07 May 2013 11:47:56 -0000

Hi,

see inline.

On 2013-05-07 02:58, Kevin Gross wrote:
> Hi Magnus,
> 
> Thanks for the quick response. Please have a look at my answers below.
> If it looks like we're on the right track, let me know and I'll prepare
> some text changes for closer review.
> 
> Kevin Gross
> +1-303-447-0517 <tel:%2B1-303-447-0517>
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
> <http://www.X192.org>
> 
> 
> On Mon, May 6, 2013 at 8:45 AM, Magnus Westerlund
> <magnus.westerlund@ericsson.com
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=magnus.westerlund@ericsson.com>>
> wrote:
> 
>     Hi,
> 
>     Rereading the O/A I think I understand what my misunderstandings are.
>     However, that still makes me unclear if even the basic cases for
>     a=ts-refclk can be announced by each side.
> 
>     Lets do an example:
> 
>     A: sends an Offer:
> 
>     v=0
>     o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1
>     s=SDP Seminar
>     i=A Seminar on the session description protocol
>     c=IN IP4 233.252.0.1/64 <http://233.252.0.1/64>
>     t=2873397496 2873404696
>     a=ts-refclk:gps
>     m=audio 49170 RTP/AVP 0
>     m=video 51372 RTP/AVP 99
>     a=rtpmap:99 h263-1998/90000
> 
>     Where A is simply telling that his reference clock is GPS based.
> 
>     The other party wants to inform similar that its clock is NTP based and
>     uses the official swedish time from "ntp1.sp.se <http://ntp1.sp.se>"
>     is in the answer.
> 
> 
> First thing to note about this offer is that it does not contain a media
> clock specification. In this case an asynchronous media clock is assumed
> - there is no predictable relationship between the reference clock
> specified (gps in this case) and the media clock. The relationship is
> announced as we go in sender reports. 

Yes, I know I didn't specify the mediaclk.

This actually lets me add an additional question here. My understanding
is that the offerer's a=ts-refclk above indicates which type of clock it
has for determine the NTP timestamp in its RTCP SR packets. However, is
it always clear who the offerer is. In the RTCP domain, the actual used
clock is bound to one or even more CNAMEs. Should this be explicitly
expressed?

> 
> 
>     The below O/A rules doesn't appear to answer if that can be done or not.
> 
> 
>     6.1.  Usage in Offer/Answer
> 
>        An answer to an offer with direct-referenced media clock and
>        reference clock specification must include the same media clock and
>        reference clock signalling in which case a connection is established
>        using the specified synchronisation.  Alternatively the answer may
>        omit both the signals or return only the reference clock
>        specification.  In this case, a connection is established assuming an
>        asynchronous media clock.
> 
>        An answer to an offer with media-referenced media clock specification
>        must include the same media clock specification.  The answer MUST
>        include the same reference clock signalling or may drop the reference
>        clock signalling.  If reference clock signalling is not present in
>        the answer, either due to not being present in the offer or due to
>        being dropped by the answerer, the stream may be established as rate
>        synchronized but not time synchronized.
> 
>        An asynchronous media clock is the default media clock mode.  This
>        mode may be explicitly signalled or presumed due to lack of
>        signalling.  Asynchronous media clocking does not require reference
>        clock signalling.  An offer with asynchronous media clocking MAY
>        include reference clock signalling.  Because the asynchronous media
>        clock is the default mode, the answerer is not required to explicitly
>        signal this even if it is explicitly signalled in the offer.
> 
> 
>     Maybe I am misreading the above. There are some unclarity in the spec.
> 
>     First paragraph appears to say that an answer to an offer including both
>     ts-refclk and mediaclk (direct-referenced) must include the same media
>     clock and reference clock. If not both can be given (due to not being
>     the same), then one can send only the reference clock or nothing. Then a
>     default behavior that is unclear if it applies to both cases of
>     alternative behavior.
> 
> 
> First paragraph does not apply because the offer does not specify a
> direct-referenced media clock (see section 5.2).

Agreed.

> 
> 
>     Second paragraph:
>     If one uses media clock that is media-referecend then the answer MUST
>     have the same clock or remove it. Then what happens if the
>     reference-clock is not included in the answer is specified. However, no
>     rules for if it is included.
> 
> 
> There's a terminology error in this paragraph. "media-refereneced"
> should read "stream-referenced". This paragraph does not apply because
> the offer does not specify a stream-referenced media clock (see section
> 5.3).

Ok, lets fix this issue. Agree that it doesn't apply as no a=mediaclk is
specified.

> 
> 
>     Third paragraph:
>     The interpretation of not signalling explicitly any media clock. And
>     that
>     it can be dropped in the answer even if explicitly given the default in
>     the offer.
> 
> 
> This is the applicable paragraph. It does allow you to specify a
> reference clock in the offer as your described answer does. It defines
> media clock signaling options for the answer but does not discuss the
> reference clock answer. We need to add a requirement that the answer
> MUST include the same reference clock specification as the offer.

Yes, but it doesn't say anything of what the rules are beyond deriving a
default value. That needs to be changed as below discussion indicates.

> 
> 
> 
>     My current understanding of the issue is that the O/A rules intended to
>     describe the following:
> 
>     1) When including a=mediaclk one MUST include also a reference clock.
> 
> 
> Correct with one exception: a=mediaclk:sender is the same as not
> specifying a media clock. In this case, no reference clock signaling is
> required.

Please be explicit about this exception.

> 
> 
>     2) If a mediaclock is provided the answer must support that same clock,
>     (type and identity?)
> 
> 
> Yes. 

I suggest that you are very explicit, especially when discussing clocks
that have identifiers on how they are to be compared.

> 
> 
>     3) If no media clock is provided then it is asynchronous, which is not
>     required to be signalled. If included in offer, answer can rely on
>     default and not include it.
> 
> 
> Yes. 
> 
> 
>     In addition to this I think some additional rules are missing.
> 
>     A) Regarding the values that can be included in each sides attribute. It
>     might be indication elsewhere of this as I think I remember such rules
>     but can't find it. Especially as it may be that a=ts-refclk works
>     declarative, and each side can provide whatever clock it actually uses
>     and simply declare it, while mediaclk requires to use the same. This
>     must be made explicit for each of the attributes.
> 
> 
> The answer must specify a reference clock compatible with the offer.
> Compatible means offer and answer must be exactly the same or offer and
> answer must both be some form of "traceable" clock. This is discussed in
> general in section 4.6 but perhaps the offer/answer implications need to
> be spelled out in section 6.


Yes, please ensure that there are explicit rules.

I also think you need to be explicit about when multiple attributes may
occur. I see this being present in Figure 3 in Section 4.7.1. Is this
only for expressing the multiple server instances of the same NTP clock, or?


I understand that you have use-cases like IDMS where offer and answer
needs to agree on which reference clock is used.

Are there no use-cases for cases when the parties just informs and are
explicit about which clock they are using. There is after all a big
difference knowing that the reference clock is driven by good quality
source or just a free running system clock in the endpoint.

But, as I don't have an explicit requirement on this I guess we leave
this for now, and can in the future define a variant of the attribute
that simply informs about which clock one uses.


> 
> 
>     B) Is it good to fallback to default, as it doesn't allow an offerer to
>     determine if the peer supports clock signaling? Even if it uses default,
>     maybe that should always be made explicit to indicate the support. Note,
>     I am not saying that you don't need to define what default is. I am
>     saying that a O/A agent that supports this signalling and uses the same
>     clock as default shall make that explicit in the offer.
> 
>     Is this the authors intention and desire to have such capabilities in
>     the signalling?
> 
> 
> I believe it is safe for the offerer to assume the answerer supports
> media clock signaling if it learns that the answerer
> supports reference clock signaling. This issue does not exist
> with reference clock signaling. But I appreciate that allowing a default
> response (no mediaclk specification) to an explicit offer
> (a=mediaclk:sender) is not useful flexibility and is a lost opportunity
> for a sanity check. I propose to remove the last sentence of the third
> paragraph in section 6.1. We'll also add some additional discussion of
> answer requirements to clarify this as well as the things that we
> touched on above.

I think that is fine.

> 
> 
> 
>     The above issues are the most import to resolve as the signalling
>     capabilities you intended to describe is not clear. At least not to me.
> 
>     The next question is do you intended to have any negotiation of which
>     clock(s) should be used? From your answer I get the impression that you
>     think not, and that media capneg will be sufficient to express the
>     alternative combinations of mediaclk and ts-refclk that the offerer
>     supports and thus enable selection of a common set?
> 
> 
> Yes, that's my position. I need to check with my coauthors to be sure
> they're in agreement with me on this.

Ok, and just to be clear. There is no support for expressing in an
offer, here are my set of supported clocks. Pick one in the answer.

> 
> 
>     I don't have any strong views on this. My personal opinion is that I
>     don't think media capneg will be particular well implemented and if one
>     wants negotiation one needs to support that in the signalling one
>     defines. IF the authors have no interest and there is no consensus for
>     such requirements then I will hold my silence regarding this capability.
> 
> 
> It is a concern if RFC 5939 is a dead end. What is your reason for your
> concern about capneg adoption? I think I have already proposed to add
> a reference to RFC 5939 in section 6.2. I can also add some discussion
> about the available functionality of one or both parties does not
> support capneg.

Usage of Capneg for profile negotiation that has been rejected by most
standards bodies for appearing to complex. If that is applicable also
for this type of usage I don't know.

There has been spent a lot of energy avoiding capneg. Likely more than
was required to actually implement it. But there is a significant
perception problem here.

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