[AG-TECH] RE: CALL FOR REVIEW OF DOC-AGNode Minimum Requirements

[Markus Buchhorn]

G'day Ivan

At 10:02 AM 11/03/2002 -0600, Ivan R. Judson wrote:
>the latency I'm describing is the end-to-end latency.

Ok, understood.

>  I measure latencey
>from my laptop to australia at an average of 306ms.  That's not bad.  Sure
>it's near the limit, but encode/decode doesn't add much.

Uhm, I'd disagree. Encoding certainly adds anywhere from 20ms and well up 
(rat audio samples alone are 20 or 40ms?), and decoding is much worse - due 
not so much to the actual decoding as to the packet buffering on the 
client, which always seems to be rather generous. I've found that very few 
codecs, dedicated hardware, meeting on just a LAN give round-trip delays 
much below 300-400ms on their own. Then you add in the network travel time.

>  Unless I can find
>a citeable reference for a higher number (we could create one), I'm not
>comfortable wandering from tradition.  Call me conservative :-).

Not at all. I just wouldn't call it tradition in the first place :-) I've 
already picked on somebody else quoting the same tradition (in a H.323 
system) :-). I haven't found a citeable reference yet, but that doesn't 
mean it's not arguable.

Ok, maybe Australia wasn't the best example, since we've just put in a 
dedicated low-latency link between AU and Seattle/I2. Pick other APAN 
countries, say like Thailand, Malaysia, Indonesia, ... which aren't so 
lucky. Or, from AU, a traceroute to Korea currently goes via the U.S. 
(peering with KR's dedicated I2 link in Chicago <sigh>), rtt of well over 
500ms.

What happens when we get an AG on the ISS, or run it between sites over a 
satellite link? (On the ISS the latency would vary over each orbit :-) ).

Anyway - I have zero problem with highlighting latency as a problem. It is 
a huge problem for natural interaction (see current discussion on real-time 
music), and it's an area I'm very interested in (low-latency codecs are few 
and far between, "high-quality" codecs are often worse, don't even get me 
started on MPEG ;-) ).

What I would suggest though is that the latency features that define an AG 
have nothing to do with the (network) latencies, and a little more with 
codec latencies. I'd prefer to see mention of 'at least support the 
standard h.261 video codec' (say) and 'appropriate hardware to do this very 
quickly to minimise latency', or words to that effect. Why is a Pentium 
100MHz laptop with the appropriate software not an AG node? Why is a dual 
P4 2GHz system with the appropriate software perhaps an AG node, or perhaps 
not? When is 1,2 or 3 PCs Ok, and when not?

By using latencies for definitions it means I can build fully functional AG 
nodes at two widely-(network-)separated points on the globe, which meet all 
criteria when they talk to other AG nodes, but not when they talk to each 
other? I just think that's not quite right.

So, I'd just suggest hiving off network latency as "a distinct issue", but 
not as part of the AGN definition. Then have the latencies as you suggest 
be described as pure codec (plus local transport?) latencies - i.e. from 
taking the (start of the) frame, through compression, packetisation, 
forwarding to network layer, receiving from network layer, 
buffering/merging, to playout. You can then keep the traditional values you 
have listed, and I won't argue :-)

<tangent>
Could we perhaps develop a test suite, with things like networked (i.e. 
non-local) loopback tests and stress-tests, that AGN's have to pass to be 
'certified' true, Tier-1, Grade-A AGN?
</tangent>

Sorry for the waffling. My two bits, take 'em as you wish :-)

Cheers,
         Markus


Markus Buchhorn, Information Infrastructure Services,   | Ph: +61 2 61258810
Markus.Buchhorn at anu.edu.au, mail: CompSci,CSIT Bldg #108|Fax: +61 2 61259805
Australian National University, Canberra 0200, Australia|Mobile: 0417 281429