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

From: [email-masked]
Date: Wed, 08 May 2013 15:49:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : RTP Clock Source Signalling
	Author(s)       : Aidan Williams
                          Kevin Gross
                          Ray van Brandenburg
                          Hans Stokking
	Filename        : draft-ietf-avtcore-clksrc-04.txt
	Pages           : 23
	Date            : 2013-05-08

Abstract:
   NTP format timestamps are used by several RTP protocols for
   synchronisation and statistical measurements.  This memo specifies
   SDP signalling identifying timestamp reference clock sources and SDP
   signalling identifying the media clock sources in a multimedia
   session.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 May 2013 09:09:25 +0200

Due to some strange list issues, I forward this on behalf of Kevin.

---------- Forwarded message ----------
From: Kevin Gross <[email-masked]>
Date: Wed, May 8, 2013 at 4:58 PM
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt
To: "[email-masked]" <[email-masked]>

This version addresses comments brought up in WGLC as well as issues
identified by the authors. The following changes are included.

1. References changed to symbolic due to problems with numbered
   references in new xml2rfc tool
2. Capitalize normative language
3. Clarify meaning of interchangeable reference clocks
4. Allow specification of multiple 1588 clock sources as is allowed for
   NTP servers
5. Use consistent "Timestamp reference clock" terminology
6. Remove some lingering synchronization confidence discussion and
   example
7. Relax definition for mediaclk-ext to allow more complex extensions
8. Rework section 6 (Signalling Considerations) to address comments
   from Magnus and Roni
9. Specify extension policy for new registries defined in this document

Magnus and Roni, please let us know if these changes address your recent
comments.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org

On 2013-05-09 00:49, [email-masked] wrote:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 May 2013 10:45:19 +0200

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.

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.

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?

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

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.

   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.

Cheers

Magnus Westerlund

---

From: Kevin Gross <[email-masked]>
Date: Mon, 13 May 2013 14:38:20 -0600

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

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

> nor what the answerer should send back.

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

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

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

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

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 May 2013 10:15:27 +0200

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
> +1-303-447-0517 <tel:%2B1-303-447-0517>
> Media Network Consultant
> <http://www.X192.org>
> On Mon, May 13, 2013 at 2:45 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
> 
> 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.

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

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

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

>  1. Include the same media and reference signaling - establish
>     connection as offered - expected behavior for an answerer supporting
>     Clksrc
> 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.

> Perhaps splitting this into separate paragraphs or subsections would

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