Re: [RE] Compatibility with 802 and why the study group is not yet a tas

Arthur,

Any network synchronization must happen above the MAC. It might be possible to make a new protocol at the link layer although it would seem more sensible to use or modify one of the existing protocols available at the session layer (e.g. NTP). There is a working group in IETF looking at current and next generation NTP. Unfortunately, my knowledge of networking diminishes exponentially as I look further up the ISO stack :-(

I don't think that measuring link delay would serve any useful purpose (especially in RE, where links will be short). The delay for packets through the network will have three components: fixed delays due to infrastructure (including switch fabrics and physical layers); jitter introduced due to packets in progress ("Ethernet jitter"); jitter introduced by network congestion. The latest of these is not relevant if the heartbeat is sent from a single clock master and uses the highest priority available in the network. The Ethernet jitter is always additive and will be zero for most packets in a network that is not oversubscribed. The hysteresis of the mechanism ensures that synchronization is not disrupted by temporary periods of 100% utilization - during which the Ethernet jitter averages 1/2 the length of the average frame size.

Hugh.

Arthur Marris wrote:

Hugh,

Would the implementation of the heartbeat mechanism with hysteresis be above the MAC layer?

I am curious to know what in RE would be within 802.3 scope and whether adding a MAC control frame for measuring link delay would be useful.

Arthur.
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On Behalf Of Hugh Barrass
Sent: 12 April 2005 15:09
To: STDS-802-3-RE@LISTSERV.IEEE.ORG
Subject: Re: [RE] Compatibility with 802 and why the study group is not yet a task force

John,

I think that you are mixing the latency/jitter requirements with the synchronization requirements.

In case a) the 15mS latency requirement presented in the tutorial seems reasonable - although the use of headphones in this case makes the task an order of magnitude easier than the tutorial case.

In case b) there is no definitive latency requirement - certainly 1/2 second would be reasonable. Therefore a >100mS jitter buffer could be expected at the receivers making the network latency/jitter constraint very easy indeed. However, there is a synchronization requirement (as there is in case a). The synchronization of multi-channel audio requires that all receivers have a frequency lock mechanism with a precision of <10uS (video is much less stringent). The use of Ethernet (as opposed to ATM) makes this job more difficult but a proper implementation of a heartbeat mechanism with hysteresis and a settling time of several seconds should be able to achieve <1uS precision.

Hugh.

John Grant wrote:
At 08:50 12/04/2005 +0100, Arthur Marris wrote:

[snip]

  
iii) You need to come up with a quantitative requirement for jitter and
relative latency and justify it. I saw the figure of 10us mentioned on
the Yahoo mailing list. This is ridiculously tight. An 802.3 voter who
is experienced in VOIP pointed out to me that even 1ms is too tight when
you consider that sound only travels one foot in a millisecond. Once you
have this requirement nailed a lot else will fall into place.
    
However, the requirements for

(a) performers listening over headphones to a mix that includes their own voice and

(b) forming a stereo or surround image from speakers that are individually (and independently) connected to the network

are more stringent than those for voice telephony.


John Grant
  