[e2e] Protocols for tightly synchronised multicast?

[Stephen Casner]

Simon,

> Does anyone have any suggestions for a multicast transport capable of
> delivering packets to applications on multiple clients synchronised to
> within a few milliseconds?
>
> The idea is to try and build a distributed virtual sound-system; a single
> source would send a single stream of audio data; this data would be
> recieved by multiple clients, with the data sent to each clients speakers
> with a fixed delay relative to some global clock (the delay would be based
> on the client's physical distance from the center of the virtual system,

For the transport of the media itself, RTP would work fine.  The
timing of the playout is not strictly a function of the transport,
though.  Instead, what's needed is a control protocol to coummunicate
the observed delays (jitter and propagation) at each of the nodes
back to a central point or distributed to all points to then calculate
what the target playout time should be.

Julio Escobar, Craig Partridge and others at BBN did some nice work on
a "Flow Synchronization Protocol" which could be used for a wide range
of synchronization goals, including the one you describe.  It is
described in a paper in IEEE/ACM Transactions on Networking, Vol. 2,
No. 2, April 1994.  I don't know if any code is available.

This protocol was used for a demonstration at ACM Multimedia '94 (in
October) of a geographically distributed live performance of a
three-part musical piece.  One part was a recorded track played from
one location to serve as a lead for the two live performers in two
other locations (Boston and San Francisco).  All three pieces were
then played out in sync at the conference.

> I can see how one could roll ones own using timestamps and NTP, but it'd
> be nice if I could use an existing transport

The sync protocol is built upon synchronized clocks at all the nodes,
which may be accomplished with NTP.

If you don't care about latency, then you could choose a large enough
fixed target delay between the source and the destinations to be
confident that it is larger than all the real delays.  The RTCP
component of RTP would provide the source timing relative to NTP time,
and you could configure each of the receivers to play out according to
the source timing plus the fixed delay plus the adjustment
corresponding to the receiver's location.
							-- Steve