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

[Ivan R. Judson]

Hey Markus,

It's going to get confusing to reply to your note, since it's been back and
forth.  I'm wondering how to do this more efficiently.  Until I figure that
out, I'm going to continue with the method of putting my comments inline
:-).  Try to decode this one:

> -----Original Message-----
> From: Markus Buchhorn [mailto:Markus.Buchhorn at anu.edu.au]
> Sent: Monday, March 11, 2002 8:05 PM
> To: judson at mcs.anl.gov
> Cc: Ag-Tech at Mcs. Anl. Gov
> Subject: Re: [AG-TECH] RE: CALL FOR REVIEW OF DOC-AGNode Minimum
> Requirements
>
>
> 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.

Yep, you are correct here.  I *think* encode latency is pretty constant
latency (not looking at code, just trying to imagine the easiest way to do
it), but the decode depending on the playout issues does vary.  One caveat
to my own statement is that FEC'ing adds significant latency (I hear).
Anyhow, the latency number is the sticky trick I think.  Understanding what
works and what doesn't would be a good thing.

At the retreat there was discussion that the numbers we're quoting are from
literature that's fairly old and focused on telephone systems.  The fact
that we'er distinguishing ourselves fairly clearly from a single two person
audio channel might have a significant impact on the audio latency
requirements (audio queues, even if skewed might make slightly more latency
tolerable?).

There might be a good experiment in trying to construct a measurement of
audio/video latency is a multistream system and discovering what the
tolerable amounts are.  Then it could be compared to the literature and
perhaps we'd discover something!

> >  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 :-) ).

I'm hoping to bring my family on vacation to the ISS soon after...

> 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 :-)

Your point is a good one, will you help me craft it into the document so
it's correct?  feel free to edit the word document and send it back with
your changes.  I'd be happy to incorporate this idea since it makes alot of
sense from many different angles.

> <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>

HEAR HEAR.  This is a great goal.  I'd love for someone to take this up and
work on it.  Bob Olson has been developing some tools for this on the audio
side, the video is a bit harder, but could be done as well.  Then the
network tools would make sense to determine network issues.  The last part
is the software verification suite, which just inventories and reports
software version mismatches.

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

Waffling, you just got yourself nominated for "Most Feedback of the Year"
award, if I didn't already know a Joe Feedback, I'd dub you Joe.  Seriously,
this is awesome feedback, I'd love *more* of it.  Only, let's not make
Markus have to write it all :-)

--Ivan