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

From: Kevin Gross <[email-masked]>
Date: Sat, 4 May 2013 21:29:03 -0600

Magnus,

I believe what we have defined in the draft is the declarative model you
have minimally requested. I believe this gives more functionality than
you're assuming it does. When used on an engineered network, there will
generally be a well-known time source and as such, offers will be
compatible with answers. When used on less constrained networks, devices
may use a "traceable" clock where the specifics of the exact source of the
clock do not need to be exactly matched to make a successful connection.

You appear to be proposing that we invent our own multiple-choice
negotiation scheme. In writing the offer-answer description I assumed that
it would be preferable to use an existing and general scheme for this than
new attribute-specific SDP syntax and semantics. Is there something I am
missing? I appreciate that we can't assume all user agents will implement
RFC 5939 but 5939 is backwards compatible with a declarative fallback mode
for those agents.

RFC 5939 allows you to specify potential configurations as a collected set
of alternate attributes in the pcfg statements (section 3.5.1). The pcfg
syntax is rich enough to express potential interdependency
between reference and media clock attributes.

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

On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund <
[email-masked]> wrote:

> On 2013-04-18 00:41, Kevin Gross wrote:
> > Magnus,
> >
> > Thanks for looking at this and sorry for the delay responding.
> >
> > I agree that mediaclk-ext is too restrictive. Your suggestion is
> > very accommodating  Something a bit more structured such as 'token "="
> > byte-string' might be more appropriate. I will check with my co authors
> > on this.
>
> Sure.
>
> >
> > As there is great precedent for it in SDP, we have implemented a simple
> > offer-answer model. I would propose that systems should use the
> > mechanisms defined in RFC 5939 if negotiation of clock configurations is
> > necessary. Perhaps adding some discussion and a reference to this RFC
> > would help.
>
> Yes, there are precedence for simple models. However, I think yours are
> over simplified and has unclear goals. Can you please comment on which
> of the goals I discuss below that you see needs to be meet? I think a
> purely declarative model would be better than what you have now, that
> would at least allow the answer to say, I use X when X is different from
> what is in the offer.
>
> When it comes to CAPNEG that is clearly a possible road, but likely will
> result that almost no one can actually determine your capability for
> clock sources. Instead they will be stuck with the your current proposal.
>
> I think even going to the model that the answer picks one for both out
> of the offerers capabilities would be better. That would at least enable
> the highest likelihood that both would use the same clocks.
>
> >
> > I don't think that independently negotiating reference and media clocks
> > as you have suggested will be adequate. Under some implementations,
> > while multiple clocks are supported, certain combinations of media and
> > reference clocks may not be allowed.
>
> Okay, that is an additional requirement. Which, might not even work well
> with CAPNEG. You will have two independent attributes that actually have
> dependencies. What you say, you appear to indicate that from each side
> you can have restrictions like this: This media-ref clock can only be
> used given that your wall clock source is either of these.
>
> Cheers
>
> Magnus
>
>

---

From: Kevin Gross <[email-masked]>
Date: Sat, 4 May 2013 22:02:32 -0600

Roni,

Thanks for the review.

See below.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Wed, Apr 24, 2013 at 8:01 AM, Roni Even <[email-masked]> wrote:

> ** **
>
> Hi Kevin,****
>
> I looked at the document and at Magnus comment.****
>
> ** **
>
> I am not sure if the document allows offering and two reference clocks. I
> am not sure what is meant in section 4.2 ****
>
> “Two or more NTP servers may be listed at the same level in the session
> description to indicate that they are interchangeable.  RTP  senders or
> receivers can use any of the listed NTP servers to govern a local clock
> that is equivalent to a local clock slaved to a different server.” ****
>
> When you say interchangeable and how it relates to Magnus proposal to
> allow negotiation.
>
What we're trying to say is that you're allowed to list multiple clock
sources with the understanding that all listed clocks deliver the same
time. Any of the clocks can be used interchangeably and synchronization is
assured. This capability is intended to support fault-tolerant clock
distribution scenarios.

> **
>
> I also assume that the information in offer/answer and in declarative SDP
> is used to provide sender information and not receiver one so is there a
> reason to have the same media clock in both direction when using
> conversional (offer/answer) application
>
For backwards compatibility, when no clock attribute is specified in a
description, it has a specific meaning (e.g. local time reference or
free-running media clock). For this reason, the answer must echo the
offer's clock attribute. This is acknowledgement to the offerer that
answerer recognises and supports the clksrc attributes.

> ****
>
> ** **
>
> ** **
>
> Other comments****
>
> ** **
>
> **1.       **ptp-domain-name =  "domain-name=" 16ptp-domain-char – did
> you mean exactly 16 charaters?
>
Basically, yes, although I admit it is a bit strange. IEEE 1588-2002
(clause 6.2.5.1) domain names are 16 character fixed-length strings.
Shorter-looking names can be used but they are padded out with null
characters.

> ****
>
> **2.       **In figure 2 a=ts-refclk:ntp=traceable – do you need also to
> specify the server address?
>
Traceable sources imply TAI-based time. Any TAI source of a
particular technology (e.g. GPS, NTP) is assumed to be equivalent to any
other TAI source using the same technology. We appreciate that this is a
crude simplification but trying to go further takes us down a rabbit hole.

> ****
>
> **3.       **In figure 3 a=ts-refclk:ntp=203.0.113.10 2011-02-19
> 21:03:20.345+01:00 – what is the last part with the date and time, I
> thought the syntax only have server address.
>
This is a timestamp left over from a previous "clock quality" proposal that
has since been removed from the draft. I had already made note to remove
this if no one caught in WGLC :)

> ****
>
> **4.       **In section 6.1 the first sentence in the first and second
> paragraph it look to me like the “must” is really a “SHOULD”
>
Another issue I had already noted for correction.

> ****
>
> **5.       **In section 8 when defining a new registry you need to say
> what is the policy for adding values to the registry (I think here it will
> be specification required” see RFC 5226
>
We will review RFC 5226 again and correct this.

> ****
>
> **6.       **The IANA section is not fully compliant with the
> requirements from RFC4566 you can look at examples in
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13IANA section or other MMUSIC RFCs
>
We will review RFC 4566 and correct this. Thanks for a pointer to examples.

> ****
>
> ** **
>
> Roni Even****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Kevin
> Gross
> *Sent:* 18 April, 2013 1:41 AM
> *To:* Magnus Westerlund
> *Cc:* IETF AVTCore WG
>
> *Subject:* Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03****
>
> ** **
>
> Magnus,****
>
> ** **
>
> Thanks for looking at this and sorry for the delay responding.****
>
> ** **
>
> byte-string' might be more appropriate. I will check with my co authors on
> this.****
>
> ** **
>
> offer-answer model. I would propose that systems should use the mechanisms
> defined in RFC 5939 if negotiation of clock configurations is necessary.
> Perhaps adding some discussion and a reference to this RFC would help.****
>
> ** **
>
> I don't think that independently negotiating reference and media clocks as
> you have suggested will be adequate. Under some implementations, while
> multiple clocks are supported, certain combinations of media and reference
> clocks may not be allowed.****
>
>
> ****
>
> Kevin Gross****
>
> +1-303-447-0517****
>
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org****
>
> ** **
>
> On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund <
> [email-masked]> wrote:****
>
> Hi,
>
> I promised doing an review of the O/A section. I also found some other
> issues to consider.
>
> 1. Section 5.4:
>
> Figure 5 shows the ABNF [5] grammar for the SDP media clock source
>    information.
>
>           mediaclk-master = "a=ssrc:" integer SP clk-master-id
>
>           clk-master-id = "mediaclk:master-id=" master-id
>
>           timestamp-mediaclk = "a=mediaclk:" mediaclock
>
>           mediaclock = sender / refclk / streamid / mediaclock-ext
>
>           sender = "sender" sender-ext
>
>           sender-ext = token
>
>           refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]
>
>           rate = [ SP "rate=" integer "/" integer ]
>
>           direct-ext = token
>
>           streamid = "master-id=" master-id
>           streamid =/ "IEEE1722=" avb-stream-id
>           streamid =/ streamid-ext
>
>           master-id = EUI48
>           avb-stream-id = EUI64
>
>           EUI48 = 5(2HEXDIG ":") 2HEXDIG
>           EUI64 = 7(2HEXDIG ":") 2HEXDIG
>
>           streamid-ext = token
>
>           mediaclock-ext = token
>
> I wonder if not the mediaclock-ext construction is to restrictive. As
> the refclk produces a sting with white-spaces in it, why isn't other
> mediaclock-ext allowed the same freedom? I think the mediaclock-ext can
> be basically byte-string, i.e. any character allowed on an SDP line
> should be possible to use. Likely the only resteriction should be that
> it starts with a token. Thus using:
>
> mediaclock-ext = token [SP byte-string]
>
> This would require a token for identifying the method followed by a
> space and then full freedom for anything that is allowed on an SDP
> attribute value.
>
>
> 2. Section 6:
>
> Purpose of signalling?
>
> I think this type of signalling can select two levels of goals with
> signalling:
>
> 1) Declaring what each SDP O/A uses on its side
>
> 2) Negotiating to arrive at the best but available mechanism on both sides.
>
> The currently proposed solution does neither of these. It enables the
> offerer to express to declare I intended to use X and for the answer to
> say I know that, or simply say I can't tell you because we are not
> having the same clocks.
>
> I think we need to be clear what our goals are here. And I will propose
> some goals with the signalling based on my understanding of how these
> defined timestamp reference clocks and media stream clocks can be used.
> And we do need to be aware that different application may have different
> needs.
>
> Goal with signalling:
>
> 1. Enable each media sender to declare its actually used ts-refclk, i.e.
> what clock is base for the RTCP SR NTP timestamps
> 2. Enable each media sender to identify what clock reference is used to
> check/drive the media sampling, i.e. RTP timestamp advancement.
> 3. Enable two media sender using SDP O/A to determine what common clocks
> they actually have so they can be used in either of ts-refclk or mediaclk.
>
> The purpose of doing three (3) is really so that one can do the following.
> A. has three ts-refclk  it can use. B has two ts-refclk available. They
> are going to watch social TV. To make it at all possible for the social
> TV service to play out content at A and B in sync they need to have
> either of these two things be available.
>
> a) Each has a common clock with the TV service
> b) A and B has a common clock
>
> In either of the scenario the TV service will be able to ensure that the
> media is played out is sync.
>
>
> As a technical solution to these issues there are two main solution tracks:
>
> 1) Change the respective SDP attributes to provide info on all possible
> clocks for that it could be using and let the answer select the most
> preferred that both are supporting
>
> 2) Leave the current SDP attributes as they are and only use them for
> declaration that: I use this! Then add new SDP attributes to negotiate
> the list of commonly supported clocks.
>
> At this stage I think 2) is what is simplest and require the least
> changes to what already exist.
>
> I will note that this is likely to require a second round of O/A
> messages to update used clocks if the arrived common clock(s) are not
> the default used ones. But, I don't see a way around these. In SIP one
> could use OPTIONS to provide a SDP which includes the negotiation
> attribute to enable the other side to select using a clock that is
> supported by both. But when that isn't done, it will take two rounds or
> other a'priori knowledge.
>
> So my proposal is simply that one create two new SDP attributes one for
> each type of clock usage (ts-refclk and mediaclk) and include a list of
> clock type and any ID of the clock in a priority order. The O/A is basic
> negotiated and the answer removes all clocks it doesn't support and adds
> all it supports. Hopefully there is someone in the list that is common.
> The highest priority between the two parties should be used when common
> clock is required. IF that is not, then these attributes should not be
> included. This for example allows one to use a common ts-refclk, but not
> require common mediaclk. We should also discuss if the answerer may
> change the priority of commonly supported, and if it should or should
> not add additional clocks it supports that are not common.
>
> I really appreciate feedback on these comments and ideas.
>
> 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: [email-masked]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt****
>
> ** **
> **
> ------------------------------
> **
>

---

From: "Roni Even" <[email-masked]>
Date: Sun, 5 May 2013 12:15:37 +0300

Hi Kevin,

On comment 2.

The syntax is

timestamp-refclk = "a=ts-refclk:" clksrc CRLF

    clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext

    ntp             =  "ntp=" ntp-server-addr

    ntp-server-addr =  host [ ":" port ]

    ntp-server-addr =/ "traceable"

this is why I expected a host address

Roni

From: Kevin Gross [mailto:[email-masked]] 
Sent: 05 May, 2013 7:03 AM
To: Roni Even
Cc: Magnus Westerlund; IETF AVTCore WG
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03

Roni,

Thanks for the review.

See below.

Kevin Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com <http://www.avanw.com/> , www.X192.org

Hi Kevin,

I looked at the document and at Magnus comment.

I am not sure if the document allows offering and two reference clocks. I am
not sure what is meant in section 4.2 

“Two or more NTP servers may be listed at the same level in the session
description to indicate that they are interchangeable.  RTP  senders or
receivers can use any of the listed NTP servers to govern a local clock that
is equivalent to a local clock slaved to a different server.” 

When you say interchangeable and how it relates to Magnus proposal to allow
negotiation. 

What we're trying to say is that you're allowed to list multiple clock
sources with the understanding that all listed clocks deliver the same time.
Any of the clocks can be used interchangeably and synchronization is
assured. This capability is intended to support fault-tolerant clock
distribution scenarios.

I also assume that the information in offer/answer and in declarative SDP is
used to provide sender information and not receiver one so is there a reason
to have the same media clock in both direction when using conversional
(offer/answer) application

For backwards compatibility, when no clock attribute is specified in a
description, it has a specific meaning (e.g. local time reference or
free-running media clock). For this reason, the answer must echo the offer's
clock attribute. This is acknowledgement to the offerer that answerer
recognises and supports the clksrc attributes.

Other comments

1.       ptp-domain-name =  "domain-name=" 16ptp-domain-char – did you mean
exactly 16 charaters?

Basically, yes, although I admit it is a bit strange. IEEE 1588-2002 (clause
6.2.5.1) domain names are 16 character fixed-length strings. Shorter-looking
names can be used but they are padded out with null characters.

2.       In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify
the server address?

Traceable sources imply TAI-based time. Any TAI source of a particular
technology (e.g. GPS, NTP) is assumed to be equivalent to any other TAI
source using the same technology. We appreciate that this is a crude
simplification but trying to go further takes us down a rabbit hole.

3.       In figure 3 a=ts-refclk:ntp=203.0.113.10 2011-02-19
21:03:20.345+01:00 – what is the last part with the date and time, I thought
the syntax only have server address.

4.       In section 6.1 the first sentence in the first and second paragraph
it look to me like the “must” is really a “SHOULD”

5.       In section 8 when defining a new registry you need to say what is
the policy for adding values to the registry (I think here it will be
specification required” see RFC 5226

6.       The IANA section is not fully compliant with the requirements from
RFC4566 you can look at examples in
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13
IANA section or other MMUSIC RFCs

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin
Gross
Sent: 18 April, 2013 1:41 AM
To: Magnus Westerlund
Cc: IETF AVTCore WG

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

Magnus,

I agree that mediaclk-ext is too restrictive. Your suggestion is very
accommodating  Something a bit more structured such as 'token "="
byte-string' might be more appropriate. I will check with my co authors on
this.

As there is great precedent for it in SDP, we have implemented a simple
offer-answer model. I would propose that systems should use the mechanisms
defined in RFC 5939 if negotiation of clock configurations is necessary.
Perhaps adding some discussion and a reference to this RFC would help.

I don't think that independently negotiating reference and media clocks as
you have suggested will be adequate. Under some implementations, while
multiple clocks are supported, certain combinations of media and reference
clocks may not be allowed.

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

On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund
<[email-masked]> wrote:

Hi,

1. Section 5.4:

          sender-ext = token

          direct-ext = token

          master-id = EUI48
          avb-stream-id = EUI64

          streamid-ext = token

          mediaclock-ext = token

2. Section 6:

Purpose of signalling?

Goal with signalling:

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
<tel:%2B46%2010%207148287> 
Färögatan 6                | Mobile +46 73 0949079
<tel:%2B46%2073%200949079> 
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

  _____

---

From: "Roni Even" <[email-masked]>
Date: Sun, 5 May 2013 12:18:22 +0300

Kevin,

Also a=ts-refclk:ntp=traceable probably a=ts-refclk:ntp= host /traceable

Roni

Roni,

Thanks for the review.

See below.

Kevin Gross

+1-303-447-0517

Media Network Consultant

Hi Kevin,

 

Other comments

Roni Even

Magnus,

Kevin Gross

Media Network Consultant

Hi,

1. Section 5.4:

          sender-ext = token

          direct-ext = token

          master-id = EUI48
          avb-stream-id = EUI64

          streamid-ext = token

          mediaclock-ext = token

2. Section 6:

Purpose of signalling?

Goal with signalling:

Cheers

Magnus Westerlund

  _____

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 May 2013 16:45:24 +0200

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
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" is in the answer.

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.

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.

Third paragraph:
The interpretation of not signalling explictly any media clock. And that
it can be dropped in the answer even if explicitly given the default in
the offer.

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.

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

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.

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.

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?

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?

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.

Cheers

On 2013-05-05 05:29, Kevin Gross wrote:
> may use a "traceable" clock where the specifics of the exact source of
> the clock do not need to be exactly matched to make a successful connection.
> 
> negotiation scheme. In writing the offer-answer description I assumed
> that it would be preferable to use an existing and general scheme for
> this than new attribute-specific SDP syntax and semantics. Is there
> something I am missing? I appreciate that we can't assume all user
> agents will implement RFC 5939 but 5939 is backwards compatible with a
> declarative fallback mode for those agents.
> 
> RFC 5939 allows you to specify potential configurations as a collected
> set of alternate attributes in the pcfg statements (section 3.5.1). The
> pcfg syntax is rich enough to express potential interdependency
> <http://www.X192.org>
> On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 

-- 

Magnus Westerlund

---

From: Kevin Gross <[email-masked]>
Date: Mon, 6 May 2013 17:32:03 -0600

The intention is that after "ntp=", there is EITHER a server address (with
optional port number) OR "traceable". I believe that's what the code
(specifically =/) specifies. If not, please set me straight.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Sun, May 5, 2013 at 3:15 AM, Roni Even <[email-masked]> wrote:

> Hi Kevin,****
>
> On comment 2.****
>
> The syntax is****
>
> ** **
>
> timestamp-refclk = "a=ts-refclk:" clksrc CRLF****
>
>     clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext****
>
> ** **
>
>     ntp             =  "ntp=" ntp-server-addr****
>
>     ntp-server-addr =  host [ ":" port ]****
>
>     ntp-server-addr =/ "traceable"****
>
> ** **
>
> this is why I expected a host address****
>
> Roni****
>
> ** **
>
> *From:* Kevin Gross [mailto:[email-masked]]
> *Sent:* 05 May, 2013 7:03 AM
> *To:* Roni Even
> *Cc:* Magnus Westerlund; IETF AVTCore WG
>
> Roni,****
> Thanks for the review.****
>
> ** **
>
> See below.****
>
>
> ****
>
> Kevin Gross****
>
> +1-303-447-0517****
>
> allow negotiation. ****
> distribution scenarios.****
>
> conversional (offer/answer) application****
>
> answerer recognises and supports the clksrc attributes.****
>
>  ****
>
>  ****
>
> Other comments****
>
>  ****
>
> 1.       ptp-domain-name =  "domain-name=" 16ptp-domain-char – did you
> mean exactly 16 charaters?****
>
> characters.****
> 2.       In figure 2 a=ts-refclk:ntp=traceable – do you need also to
> specify the server address?****
>
> thought the syntax only have server address.****
>
> This is a timestamp left over from a previous "clock quality" proposal
> that has since been removed from the draft. I had already made note to
> remove this if no one caught in WGLC :)****
>
> 4.       In section 6.1 the first sentence in the first and second
> paragraph it look to me like the “must” is really a “SHOULD”****
>
> Another issue I had already noted for correction. ****
>
> 5.       In section 8 when defining a new registry you need to say what
> is the policy for adding values to the registry (I think here it will be
> specification required” see RFC 5226****
>
> We will review RFC 5226 again and correct this. ****
>
> 6.       The IANA section is not fully compliant with the requirements
> from RFC4566 you can look at examples in
> We will review RFC 4566 and correct this. Thanks for a pointer to
> examples. ****
>
>  ****
>
> Roni Even****
>
>  ****
>
>  ****
>
>  ****
>
> *Cc:* IETF AVTCore WG****
>
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 7 May 2013 02:41:59 +0300

Kevin,

My mistake.

Roni

From: Kevin Gross [mailto:[email-masked]] 
Sent: 07 May, 2013 2:32 AM
To: Roni Even
Cc: Magnus Westerlund; IETF AVTCore WG
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03

Kevin Gross

+1-303-447-0517

Media Network Consultant

Hi Kevin,

On comment 2.

The syntax is

Roni

Roni,

Thanks for the review.

See below.

Kevin Gross

Media Network Consultant

Hi Kevin,

 

Other comments

Roni Even

Magnus,

Kevin Gross

Media Network Consultant

Hi,

1. Section 5.4:

          sender-ext = token

          direct-ext = token

          master-id = EUI48
          avb-stream-id = EUI64

          streamid-ext = token

          mediaclock-ext = token

2. Section 6:

Purpose of signalling?

Goal with signalling:

Cheers

Magnus Westerlund

  _____

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 7 May 2013 13:47:48 +0200

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
> On Mon, May 6, 2013 at 8:45 AM, Magnus Westerlund
> <[email-masked]
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=[email-masked]>>
> wrote:
> 
>     Hi,
> 
>     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
>     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?

> First paragraph does not apply because the offer does not specify a
> direct-referenced media clock (see section 5.2).

Agreed.

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

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

> Yes. 

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

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

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

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

> 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

---

From: Kevin Gross <[email-masked]>
Date: Wed, 8 May 2013 17:01:00 -0600

Roni,

With regards to items 5 & 6.

5. Please review my changes to section 8 in the newly published version 04
of the draft. If these changes do not satisfy your request, please cite an
example of a policy specification I can work from to improve this further.

6. While the formatting is slightly different, I believe our draft contains
all the information in the example you cite and we have the requirements in
RFC 5226 section 5.1 covered. I can reformat the section to look more the
example you cite but I don't think that would be a material improvement. If
we're going to make improvements here I need more specifics on what exactly
is not in compliance.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Wed, Apr 24, 2013 at 8:01 AM, Roni Even <[email-masked]> wrote:

> allow negotiation.****
> you mean exactly 16 charaters?****
>
> be specification required” see RFC 5226 ****
>