From: dean@pico.qpsx.oz.au (Dean Economou)
Newsgroups: aus.aarnet
Subject: Re: FASTPAC and AARNET
Date: 30 Sep 92 05:40:29 GMT
Organization: QPSX Communications LTD, Perth, Western Australia.
X-Newsreader: Tin 1.1 PL4

miw@cc.uq.oz.au (Mark I. Williams) writes:
: Chris.Rusbridge@levels.unisa.edu.au writes:
: 

       [deleted lots of good words on video over networks...]

: some kind of asynchronous channel like cell relay, you then have to
: provide buffering at the receiver to smooth out the delay jitter, adding
: buffer delay to the delay of the channel. In order to support these
: traffic streams, the communications channel has to provide low delay and
: low delay jitter. Unfortunately, the Ethernet interface on FASTPAC-10
: seems to have a combination of delay jitter and assembly/disassembly
: delay that is too large to support interactive video if you apply the 150ms 
: criterion. 

The intrinsic segmentation and reassembly delays are actually a few
milliseconds.  If the QPSX gear was liberated from the restraints of
FASTPAC, then you could just connect your video into a G.703 interface
on one of our clusters.

The Deutsches Bundepost trial with Daimler Benz and Porsche used our
equipment in just such a way.  Benz and Porsche were making heavy use of
the LAN interfaces, but Benz also used the gear's intergated synchronous
services to interconnect PABX's and run video conferences.  The full
story is in the May 1992 issue of "Data Communications", p63.  

: 
: Of course, Ethernet interfaces suck big time when it comes to delay
: jitter anyway, because they have exponential backoff built into them.

This depends how you use them.  If you use the Ethernet in
point-to-point configuration as many people do, there is very little
opportunity for collision or binary exponential backoff.  Even when it
occurs it would be very unlikely to reach anything like a significant
fraction of 150msec.  The source of the delay would most likely be the
queueing delay that is caused by the total traffic on the Ethernet, I do
not think it is an artifact of the Ethernet itself.

: Perhaps a token-ring interface would be better. You could also relax the
: delay criterion and provide more buffering, but you might find that
: users will reject the result.

The Token ring would only help in the sense that it has higher bandwidth
available (assume 16M), and so will support more traffic before queueing
delays become noticeable.

: 
: This is really not meant as a criticism of FASTPAC-10. After all, AOTC
: certainly aren't touting it as a service for carrying video traffic.
: However, what I *am* saying is that FASTPAC-10 won't allow AARNet to
: carry much in the way of sexy new services. It is, after all, really

This is one of the reasons I wanted to talk about what QPSX technology
could do, as distinct from the way it is used to provide FASTPAC-10.
The gear provides an integrated services with broadband access speeds.
If were deployed as private equiopment, then AARnet could support many
new services, and integrate them into one infrastructure.


: only equivalent to a couple of megalinks, as it is a half-duplex medium.
: This means that any move by AARNet to FASTPAC can only be justified on
: the basis of how it stacks up price-wise. That is *all* I was saying
: when it comes to FASTPAC.
: 
: I happen to think that the price advantage is there, if a bit marginal.
: Geoff thinks it is *too* marginal to be taken seriously at the moment.
: So we disagree. That's life.

If the equipment was used to provide a private network with integrated
synchronous and asynchronous servces, then perhaps its true virtues will
be apparent.

: 
: >More recently, I was involved in a video conferencing 
: >trial using 112 Kbps (2*ISDN-US B channels). At first it was unnerving 
: >to see the presenter's face freeze as she sent a high resolution 
: >document over the line, but it was surprising how quickly we got used 
: >to it. More unnerving was the delay introduced by the compression 
: >techniques into the audio channel. This was at least twice the 
: >satellite delay. Nevertheless I was convinced that such a system was 
: >workable.

I don't know about you, but I refuse to accept these kinds of
compromises.  I could probably accept the video compromise, but there is
no excuse for the problems with audio.

Having said that, I till hink video conferencing will eventually be a basic
tool in all workplaces.

: 
: It sure is. I attended a meeting last Friday where the WA delegates
: attended via videoconference. (They couldn't get a ticket east due to
: the AFL final). I am convinced that the WA delegates had a much better
: deal of it, since I spent 2 days mucking about with planes and crappy

Added to that, they stayed in nice exciting Perth instead of dull
Canberra :-)

: accommodation, while they could have muffins and coffee during the
: meeting without disturbing anyone. In addition, they got do do a bit of
: workshopping when the cranks got hold of the microphone at the Canberra
: end. They also got more than their fair share of the floor becaues of 
: their 'disadvantaged' status. :-)
: 
: Incidentally, this technology is almost old hat. *Very* nice
: videoconferencing hardware is available off-the-shelf today, and you
: just plug it into your ISDN microlink or macrolink, and get resolution
: and motion according to how many channels you dial. No muss, no fuss, no
: sweat. You can have control voice-switched and get the camera to find
: the speakers nearly automatically. It just costs around $100 grand per 
: station.

Now if we could convince you to use a QPSX network, you could just plug it
into the nearest G.703 interface on one of our boxes.

: 
: >The point here is that I suspect for that sort of application (video 
: >conferencing, remote video tutorials, etc)  that the delay introduced 
: >by Fastpac will not be significant. It is very likely to be much less 
: >than the incremental satellite delay. Yes, there are high quality, 
: >rela time video applications for which it would not be suitable. Just 
: >don't believe that _all_ video is ruled out.
: 
: I don't disagree with you that *some* video can be sent over FASTPAC. In
: fact, the folks at Woolongong and AOTC have been running trials sending colour
: video at reduced scan rates over FASTPAC. Given a clear Ethernet, one
: session only, and the wind behind them they got a result that was almost
: 'there', but they are the first to admit that it isn't yet a real-world
: service. They also got results that were almost as good using a couple

That's very interesting to hear.  I've also seen some rather good
results run as multimedia applications using 16M token rings. 

: of Wellfleets joined by a Megalink service. I might add that they were
: at pains to point out that their results did not constitute a criticism
: of FASTPAC. The results are published in the proceedings of the 2nd
: Australian Multi-Media Communications, Applications, and Technology
: Workshop (July, 1992).
: 
: "Desktop Teleconferencing for Broadband Networks"
: by H.W. Peter Beadle, John Judge, Greg McFarlane, and Leith Hayes.
: 
: If you are talking about real multimedia applications using 2-way
: full-motion video it is a different story. What is acceptable to
: conditioned operators who want the system to work for them will not be
: acceptable to the general public. For that you need a real broadband
: service.

I've seen some definition of broadband (USA) as anything over
1.5Mbit/sec.  Is that what you mean?   

: 
: I'll get out of your way now,

It was most interesting to read your post.  No apologies needed!

: 
: cheers,
: --
: Mark Williams         The University of Queensland       miw@cc.uq.edu.au
: +61 7 36 54012   (w)  Prentice Centre
: +61 7 36 54477  (fax) Qld 4072  Australia
: Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca


Cheerio,
Dean.

A sign of genius is: seeing what others have seen, but reacting
differently.  It is, of course, also a sign of madness.  --Economou.

Newsgroups: aus.aarnet