Subject: [avtext] draft-williams-avtext-avbsync

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 10 Jun 2011 13:09:58 +0200

(As WG cochair)

The following author draft defines an RTP header extension

https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/

Apart from a request for agenda time at the last meeting, there has not been any discussion on the document.

Q1: To the authors. Are you intending proceeding with this document. Is the document still the direction you wish to go or do you have other ideas.

Q2: To the WG. Is this document reasonable or heading in entirely the wrong direction.

Regards

Keith

---

From: David R Oran <[email-masked]>
Date: Sat, 11 Jun 2011 10:33:27 -0400

> Q2: To the WG. Is this document reasonable or heading in entirely the wrong direction.
Three thoughts:

a) I don't get it. Just because the RTP wall clock is in NTP time format doesn't mean that time could not have been synchronized to the accuracy of an IEEE 1588 clock using those protocols to compute/adjust it as opposed to or as augmentation of IEEE 1588.

b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol?

c) We should ask the TICTOC working group for their opinions before considering adoption.

Thanks, DaveO.

> Regards
> 
> Keith
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Glen Zorn <[email-masked]>
Date: Sun, 12 Jun 2011 06:46:38 +0700

> a) I don't get it. Just because the RTP wall clock is in NTP time format doesn't mean that time could not have been synchronized to the accuracy of an IEEE 1588 clock using those protocols to compu…

True.

> b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol?

Why does it matter?

> c) We should ask the TICTOC working group for their opinions before considering adoption.

Probably a good idea.

...

---

From: David Oran <[email-masked]>
Date: Sun, 12 Jun 2011 06:00:44 -0700

Answering your question below.

>> b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol?
If you are using the wall clocks for some purpose that actually depends on the Avb time properties, then you also probably also depend on the two or more RTP endpoints actually residing within the same scope that the protocol is running in. Since the Avb protocol runs at L2 and RTP at L4+, you would need some outside knowledge to figure this out that is not in RTP, or SDP.

For example, if you don't run NTP at all, it's perfectly possible for two instances of the AVB synch protocol running on LANs opposite sides of the planet having time bases that are skewed by an arbitrary amount. That wouldn't matter to applications confined to a single extended LAN, but clearly matters over a wider scope like that of RTP applications.

Make sense?

> <gwz.vcf>

---

From: "Kevin Gross" <[email-masked]>
Date: Sun, 12 Jun 2011 21:43:03 -0600

The draft text is perhaps missing some crucial justification. Point (a)
below does need to be addressed. 

The answer on point (b) is that there is a globally unique 80-bit gmIdentity
field in the RTCP packet used by the AVB transport (see section 4 of this
draft). Observing this will tell you whether you're dealing with the same or
different clock domain.

Kevin Gross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Oran
Sent: Sunday, June 12, 2011 7:01 AM
To: Glen Zorn
Cc: [email-masked]
Subject: Re: [avtext] draft-williams-avtext-avbsync

On Jun 11, 2011, at 4:46 PM, Glen Zorn <[email-masked]> wrote:

>>> Q1: To the authors. Are you intending proceeding with this document. Is
the document still the direction you wish to go or do you have other ideas.
>> a) I don't get it. Just because the RTP wall clock is in NTP time format
doesn't mean that time could not have been synchronized to the accuracy of
an IEEE 1588 clock using those protocols to compute/adjust it as opposed to
or as augmentation of IEEE 1588.
> 
> True.
> 
>> 
>> b) how can you tell whether or not the RTP session has both endpoints
within the scope/domain of a single instance of the AVB synchronization
protocol?
> Why does it matter?
If you are using the wall clocks for some purpose that actually depends on
the Avb time properties, then you also probably also depend on the two or
more RTP endpoints actually residing within the same scope that the protocol
is running in. Since the Avb protocol runs at L2 and RTP at L4+, you would
need some outside knowledge to figure this out that is not in RTP, or SDP.

For example, if you don't run NTP at all, it's perfectly possible for two
instances of the AVB synch protocol running on LANs opposite sides of the
planet having time bases that are skewed by an arbitrary amount. That
wouldn't matter to applications confined to a single extended LAN, but
clearly matters over a wider scope like that of RTP applications.

Make sense?

---

From: Aidan Williams <[email-masked]>
Date: Wed, 29 Jun 2011 16:22:59 +1000

Hi Keith,

It is my intention to proceed with this document and to update it with additional material.

The draft relates to work elsewhere around using the IEEE AVB protocols [1] with RTP transport.  "Elsewhere" in this case means the IEEE, AVnu and the Audio Engineering Society (AES).

The RTCP message described in the draft is what has been specified by the IEEE 1733 WG.  I'm not aware that this has been brought to the attention of this WG, however I would certainly be interested in any feedback people may have.

The header extension is a logical addition.  At the time that IEEE 1733 had to make a choice, the header extension mechanism wasn't available.  For high performance implementations (such as those I work on), media packets are processed at wire speed in hardware (e.g. by FPGA).  It is very convenient to have the synchronization metadata available with the media payload since the control and data processing planes are distinct.  It is a similar approach as the RFC6051 NTP timestamp header extension.

I see there are a couple of other emails relating to the motivation for doing any of this this at all - I'll reply to them next.

regards
             aidan
____
:wq!

[1] The IEEE AVB task group: http://www.ieee802.org/1/pages/avbridges.html

---

From: Aidan Williams <[email-masked]>
Date: Wed, 29 Jun 2011 17:56:43 +1000

> a) I don't get it. Just because the RTP wall clock is in NTP time format doesn't mean that time could not have been synchronized to the accuracy of an IEEE 1588 clock using those protocols to compu…

You're right - it isn't the format of the NTP timestamp that is the issue, rather it is about having identifiable clocking domains, and performance.

RTP does not assume synchronised clocks and does not assume that NTP timestamps refer to a synchronised clock (either rate or offset synchronised).  There is no standard way of knowing that NTP timestamps coming from two or more senders are taken w.r.t. to a synchronised clock.  In contrast, the RTCP message described in the draft can indicate that timestamps are coming from a single clock source via the gmIdentity field.  The gmIdentity is based on the EUI64 of the master clock.  A device receiving flows from senders with the same gmIdentity can be sure that the timestamps are being taken with a common clock.

AVB systems are intended to time align signal playout and capture signal phase relationships accurately on all boxes connected to the network.  Playout/capture on one device is intended to be accurately time aligned with playout/capture on a different device.  Accurate time alignment is required between signal flows and between boxes, and to achieve that, accurate synchronised time is needed.  To give you an idea of the requirement: for ProAV applications, +/-1us time alignment is required; for consumer applications, 80us time alignment is required between a left and right loudspeakers (say).

Readily available hardware support in end-point chipsets and switches, absolute time alignment performance, fast lock time and identifiable clocking domains make IEEE 1588/802.1AS a good choice over NTP as a synchronisation protocol.

If you're going to send an RTCP message binding an RTP timestamp, a 1588 timestamp and a gmIdentity together, the 1588 timestamp may as well be in a 1588 format.

> b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol?
See the above comment about gmIdentity.

> c) We should ask the TICTOC working group for their opinions before considering adoption.
I haven't been following tictoc recently - I'll take a look.

regards
             aidan
____
:wq!