Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt

[Kevin Gross <[e-mail]>]

Thanks for your continued help improving this. Let me know what you think
about my answers and proposed revisions below.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Mon, May 13, 2013 at 2:45 AM, Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> I have reivewed the changes and I don't think Section 6.1 nor 6.2 is clear.
>
> Intro and the clarification of the relationship between media clock and
> reference clock is good.
>
> "Usage of reference clock and media clock signalling in offer/answer
>    allows the offerer to declare the reference clock and media clock in
>    use and allows the answerer to acknowledge that a connection
>    according to these declarations will be successful or, in limited
>    cases described below, specify a simplified synchronization mode."
>
> This implies that the rules also for reference clock handling is to be
> specified. That is not the case. There is no explanation what an
> Reference clock offer means and what the limiations on that offer is,
> nor what the answerer should send back.
>

Reference clock requirements are discussed in parallel with media clock in
the paragraphs that follow.

>
> To my understanding something like this is needed.
>
> An offer MAY include multiple a=ts-refclk attributes, however if there
> is more than one attribute, they MUST be for multiple instances of the
> same clock type and reference type and be possible to use
> interchangeable. If an answerer supports and can access the proposed
> reference clock it SHALL include all reference clock attributes offered
> that it supports. If none are supported and accessible then the
> a=ts-refclk attribute SHALL NOT be included in the answer.
>

The meaning of multiple reference clock specifications is described in
section 4.2 and now also 4.3. I think it would be useful to reiterate and
expand on the meaning of this in the context of offer/answer as you have
suggested.

>
> Question: Should as alternative to no a=ts-refclk in the answer
> a=ts-refclk:private be allowed as indication that the answer will run on
> its clock?
>
> And in this case when it is not supported, are there no benefit in the
> answerer identifying the clock it will actually use, despite that a
> common clock sync was not achieved?
>

I don't think it is useful for an answer to contain a reference clock
specification that is not in the offer. This proposed semantic doesn't fit
the normal offer/answer paradigm where the answer describes the connection
that will actually be made. When there is no common reference clock, the
connection that is made is without a reference clock.

>
> Then I think it makes sense to follow this by:
>
>   "While full negotiation of reference clock and media clock attributes
>    is not directly supported in the clock source signalling defined in
>    this document, negotiation MAY be accomplished using capabilities
>    negotiation procedures defined in [RFC5939]."
>
> I think this already covered in the second paragraph of section 6.1. I
don't think we want to describe media clock and reference clock
offer/answer as separate topics because there are interactions: some media
clock modes do not require a reference clock, others do.

>
> Then we have  the use of SHOULD:
>
>    An answer to an offer with direct-referenced media clock SHOULD
>    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 signals or include only the
>    reference clock specified in the offer.  In this case, a connection
>    with asynchronous media clock is established.
>
>
> What are the exceptions for this SHOULD? Using SHOULD allows for other
> cases of excluding it then specified. If there are a one or few
> exceptions, it is much better to write SHALL, except for ...
>
> At least make clear what the exceptions are and how to interpret when it
> not present. So what does it mean to the answerer to receive an OFFER
> with different Media clock and reference clock. How should it answer it.
>

The answerer options we're trying to document are:

   1. Include the same media and reference signaling - establish connection
   as offered - expected behavior for an answerer supporting Clksrc
   2. Omit media and reference signaling - establish asynchronous
   connection - expected behavior for a legacy device
   3. Reject the offer - establish no connection - always an option under
   the offer/answer model

The offer/answer examples I was working from treat this in a manner similar
to what's currently in the draft. There will some restating of RFC 3264
involved but I can revise to be more explicit about these options.

>
>    An answer to an offer with stream-referenced media clock signalling
>    SHOULD include the same media clock specification.  If the offer
>    contains reference clock signalling, the answer SHOULD include the
>    same reference clock specification.  The answer MAY omit 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 in the answer, the stream may be established as rate
>    synchronised but not time synchronised.
>
>
> I also think this above section mixes up reference clock signalling
> (a=ts-refclk) with a=mediaclk. I think it would better with a clearer
> full spec for just the reference clock, like my proposal above, then
> followed by the a=mediaclk rules, especially in relation to the ts-refclk.
>
> It might be also good to write more rules on what applies for the
> Offerer constructing the offer.
>

I guess this is getting tangled because it is describing two different
types of offer:

   1. Stream-reference media clock with reference clock
   2. Stream-referenced media clock without reference clock

Perhaps splitting this into separate paragraphs or subsections would
clarify things.

>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>