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

[Kevin Gross <[e-mail]>]

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
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Sun, May 5, 2013 at 3:15 AM, Roni Even <[e-mail]> 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:[e-mail]]
> *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****
>
> [phone]****
>
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org****
>
> ** **
>
> On Wed, Apr 24, 2013 at 8:01 AM, Roni Even <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *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.****
>
>  ****
>
> 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****
>
> [phone]****
>
> 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 <
> [e-mail]> 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  [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****
>
>  ****
> ------------------------------
>
> ** **
>