Subject: [AVT] Re: Layer 2 synchronization and clock (was: AVT draft agenda)

From: Michael Johas Teener <[email-masked]>
Date: Wed, 25 Oct 2006 20:45:23 -0700

Randell Jesup <[email-masked]> wrote:
> "Tom-PT Taylor" <[email-masked]> writes:
>>  Precise time synchronization so that every network element will
>>  have access to a very high quality clock (done via a layer 2
>>  profile of the new revision of IEEE 1588). This is being done as
>>  project 802.1AS, and it¹s well on its way.
> 
> Just wondering: why is precise synchronization important?  Especially since
> sync will drift.  And why do the network elements need to know?  Perhaps
> you're trying to instill knowledge into the network of how long a packet
> has been "in-transit"?
> 
> RTP provides for a higher-level end-to-end synchronization on a per-stream
> level (RTCP and NTP), though for reasons having to do with its origin in
> multicast scenarios synchronization can take a short while.  (There are
> ways around that like AVPF).  Is there a reason this part of the problem
> couldn't be addressed by protocol modifications at that level?

Synchronization is useful for two primary reasons, and the "precise" part of
it is relative to the particular application.

1) Clearly there are streams that need to be rendered at different devices
in synchronization. A simple (though not really precise) example is
lip-synch, where the video going to the display must be synchronized with
the sound rendered by a speaker (20ms is usually considered "good enough"
for that). The next level of synchronization is that needed for correct
sound "imaging" for a multiple speaker system. Depending on the nature of
system, synchronization down to 100s or even 10s of microseconds is needed
for proper phasing. There are industrial, telecom, and instrumentation
requirements that are even more extreme ... IEEE 1588 systems are aimed down
to the sub-nanosecond level.

2) The network needs to avoid introducing any jitter or wander to the
distributed clock that cannot be easily filtered. The clock provided by the
802.1AS service is intended to be used by applications for sampling, and so
must meet the MTIE mask for that application. The baseline requirement is to
support uncompressed video, which means a application-level jitter of around
10ps at high frequencies.

Of course, many of these requirements can be met by pure RTCP/NTP systems,
but at the cost of latency for the buffers and the fairly long control
loops. The 802.1AS part of our work is intended to allow much of the simple
work to be done at lower layers in the network element hardware. With any
luck, the work we are doing will hook to higher layers to allow shallower
buffers and faster real time responsiveness.
-- 
---------------------------------------------------------------
         Michael D. Johas Teener ‹ [email-masked]
office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845
  http://xri.net/=Michael.Johas.Teener - PGP ID 0x3179D202
---------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Thu, 26 Oct 2006 13:43:00 -0400

Michael Johas Teener <[email-masked]> writes:
>for that).

NTP sync exchanged via RTCP is sufficient for this level.

> The next level of synchronization is that needed for correct

Again, inter-device NTP sync (or equivalent, i.e. at the device level not
the network-element level) should be sufficient I believe for this.  With
sufficiently frequent RTCP or with other non-RTP/RTCP protocols (since
while RTP/RTCP can do this it wasn't specifically designed for it), this
shouldn't be a problem.

>10ps at high frequencies.

Why do you need to use this network-generated clock for sampling directly,
and not a local clock synchronized between devices?  Do you really need
10ps sampling synchronization between devices?  How often?  And if so, is
this really the way to get it?

>buffers and faster real time responsiveness.

What I don't see is how this will do that, and what it will do that either
existing mechanisms (or new mechanisms at the same level) can't do.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Michael Johas Teener <[email-masked]>
Date: Thu, 26 Oct 2006 17:52:33 -0700

> existing mechanisms (or new mechanisms at the same level) can't do.

I understand all your comments and, in general, agree with them. Nothing
being done by 802.1 is really new, it's just adaptations of technology that
has been around since I worked on early packet-based
telephone/audio/telemetry systems in the early 80's ...

All that is being done is to move some timing and QoS services closer to the
network layer so that they can be easily built into the hardware for
Ethernet/WiFi NICs and switches. The result is lower latency and (probably)
lower cost.

It has the side benefit of running non-IP protocols that are currently
dependent on specialized non-802 networks (such as IEEE 1394 for consumer
electronics and pro audio, and SONET/TDM networks in telecom).

Since things *should* be moving more and more towards IP nets, it's nice to
provide the kind of performance (latency, synchronization, guaranteed BW)
that some old nets provide, even with IP.

---

From: Randell Jesup <[email-masked]>
Date: Sat, 28 Oct 2006 03:52:57 -0400

>Ethernet/WiFi NICs and switches. The result is lower latency and (probably)

Ok, if this is a replacement for NTP that's fine, though requiring anything
of network elements needs a really good reason, and it'd better be cheap,
easy to do and not get wrong, and give some sort of benefit outside the
very limited space mentioned here if you want hardware vendors to implement
it in enough equipment for this to be really useful to you.  Targeting
a "better NTP" might be a good start.  I would suggest trying very hard to
make your idea work without special support in hubs/switches/routers if at
all possible.  If it must be there, KISS.  :-) 

What bothers me the most is the "insert time in the network stack" part.
a) latency from sample to stack is rarely fixed except in the most
special-purpose hardware.  b) the more I hear the more I think you want to
get the true sampling time for a set of samples.  This is really a hardware
and system issue; it's not a network or protocol issue.  IMHO

---

From: Chuck Harrison <[email-masked]>
Date: Tue, 31 Oct 2006 10:50:05 -0800

Mike, all,

After chewing on this awhile I would caution 802.1 not to grasp at
the IEEE1588 hammer -- this is not a nail.

1588 puts a lot of effort into measuring the link delays. Stop and
think about it: in the home AV environment is the wireline or
airwave propagation delay the issue? No!

Let's look at some historical models from professional AV studio
production. In analog sound production, wireline delay is just
not a concern. At a concert, the microphone signal may go a few
hundred feet from the stage to the mixing console, then a few
hundred feet back to the performer's monitor. No sweat. In a
digital sound studio there is likely to be a master word clock
generator distributing a 48 or 96kHz clock. Nobody is counting
out the number of feet of clock cable.

In analog video production you see a different story. In the past,
technicians would cut cable lengths to within a foot. Why? They
wanted to maintain phase match of a 3.58MHz color subcarrier
within 1 degree - about a nanosecond. Incidentally, that style of
signal engineering has become obsolescent; certainly 802.1 should
not be trying to emulate it in a home environment.

It would also be worthwhile for 802.1 to get a technical
presentation on the currently-deployed layer-2-based audio
distribution systems, specifically Cobranet and Gibson Magic.
They work, and we can learn from them.

I suggest that a small-network AV environment can work under
the model that layer-1 link delays are zero. Say a packet
leaves link endpoint A at time T(A) on device A's timebase,
and arrives at the other endpoint, B, at time T(B) on device
B's timebase. We can just assume that T(A) is simultaneous with
T(B). The only penalty is a *fixed* offset between device clocks
on the order of a microsecond. This offset only changes when
the physical network cables are rerouted, and will be
imperceptible.

As we look for a "better NTP" for LAN environments, the limits on
performance will mostly come from (a) drift rate (and change of
rate) of the local clocks, and (b) uncertainty in local
timestamping relative to the "on-the-wire" signal. We should
evaluate whether layer-2 timestamping is an adequate proxy
for layer-1 timing. The subtle point is that, if the average
delay between PHY and MAC (e.g. in FIFOs) depends on traffic,
you can get systematic clock-phase pulling based on network load.
If this dynamic phase wander gets up into the multi-microsecond
range it's a concern. Suppressing audible phase wander by
putting a slow time constant on the clock corrections is
dangerous; it can severely impact start-up time.

I gather that "the train has left the station" in the sense
that 802.1as's officially-approved task is to incorporate 
IEEE1588 mechanisms into home-network AV. There are worthwhile
things to take from 1588, but the link-delay-measurement scheme
is not one of them. Considerable equipment simplification would
arise from eliminating it.

And to point out the obvious: if you want to characterize the
multi-hop transport latency, it's a piece of cake to layer that
on top of a precise distributed time service. You could say that
1588 is doing it upside down: building the time service on top
of a delay-characterized network. Looks more complicated to me!

Peace,
  Chuck

---

From: "Joe Kelsey" <[email-masked]>
Date: Tue, 31 Oct 2006 11:26:24 -0800

Chuck,

Nice general discussion of home networking versus professional networking.

However, you seem to have missed the central point entirely.  The NTP discussion is not about home versus professional, AV or not.  The discussion is about the fact that it takes almost a day to make NTP synchronize.  If you have long-running networks, then they certainly can take a day to synchronize themselves.  However, there are times where you need synchronization very much faster than is achievable with NTP.  That is exactly what IEEE-1588 does.  Using IEEE-1588, you can synchronize a network of clocks very rapidly.

It is all about how long does it take before you can say that your network of disparate computers is synchronized to under a microsecond.  With NTP it takes a day.  With IEEE-1588 it takes a minute.  What are the requirements for your particular consumer device in terms of clock synchronization and how long the user is willing to wait for things to settle.

It is a completely separate discussion whether or not any of the mentioned applications really need the precise synchronization or speed of synch.  I personally have that need.  Whether or not your particular application has that need is an open question.

/Joe

>>> Chuck Harrison <[email-masked]> 10/31/2006 10:50 AM >>>
Mike, all,

Peace,
  Chuck

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 15:08:54 -0500

"Joe Kelsey" <[email-masked]> writes:
>However, you seem to have missed the central point entirely.  The NTP
>discussion is not about home versus professional, AV or not.  The
>discussion is about the fact that it takes almost a day to make NTP
>synchronize.  If you have long-running networks, then they certainly can
>take a day to synchronize themselves.  However, there are times where
>you need synchronization very much faster than is achievable with NTP. 
>That is exactly what IEEE-1588 does.  Using IEEE-1588, you can
>synchronize a network of clocks very rapidly.
>
>It is all about how long does it take before you can say that your
>network of disparate computers is synchronized to under a microsecond. 
>With NTP it takes a day.  With IEEE-1588 it takes a minute.  What are
>the requirements for your particular consumer device in terms of clock
>synchronization and how long the user is willing to wait for things to
>settle.

Like I (and I think Chuck) was saying is that you don't need IEEE-1588's
link-time measurement, and therefore you can use a much simpler solution.
We weren't saying that NTP synchronized fast enough, but that you could
build an NTP-like or NTP-derivative protocol that synchronizes faster,
without requiring the sorts of issues that IEEE-1588 brings along/requires.

>It is a completely separate discussion whether or not any of the
>mentioned applications really need the precise synchronization or speed
>of synch.  I personally have that need.  Whether or not your particular
>application has that need is an open question.

Right - but the wider the application and the less
modification/cost/complexity for network elements, the more likely it is
to become available (outside of specialty items).

I think faster sync (especially if it's not hard and doesn't require any
support (or minimal) from network elements is an easy sell.  A better,
local NTP.  Precision of sync might be harder sell, but let's see what a
better NTP can buy us, since speed and precision are of course related.