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

[Magnus Westerlund <[e-mail]>]

Hi,

I think we are making progress on this. O/A is challenging to describe
in sufficient detail. I can try to find time for a phone call if you
think that would significantly speed up the progress. Contact me of list
in that case.

Comments inline.

On 2013-05-13 22:38, Kevin Gross wrote:
> Thanks for your continued help improving this. Let me know what you
> think about my answers and proposed revisions below.
> 
> Kevin Gross
> [phone] <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 13, 2013 at 2:45 AM, Magnus Westerlund
> <[e-mail] <mailto:[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.

Yes, I understand the need to discuss when you have a mediaclk the need
for having certain types of reference clocks etc. However, usage of the
reference clock alone is not clear, neither what is allowed to include,
nor how to interpret the answer, and what is allowed in the answer.

This must be clarified.

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

Please do.

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

Ok, then I guess the specification should be clear that you shall
include a value that says, we don't have a common clock, to separate
that from the case of I don't know what this a=ts-refclk is. Although
the actual implications may be the same.

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


Yes, I just meant this as a hint that I think the above text proposal
should be inserted prior to the above paragraph. Sorry for not being clear.

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

Sure, but you need to ensure that all options allowed and relevant
combinations that can be produced and their interpretations are described.

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

Yes, I think you should split the different types of offers into
different paragraphs, then look at the result depending on what the
answerer can and do answer.

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