home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.cell-relay
- Path: sparky!uunet!mcsun!sun4nl!research.ptt.nl!walvdrk
- From: walvdrk@research.ptt.nl (Kees van der Wal +31 70 332 6295)
- Subject: Re: Curious attitude ...
- Message-ID: <1992Jul29.164110.1@research.ptt.nl>
- Sender: usenet@spider.research.ptt.nl (USEnet News)
- Nntp-Posting-Host: dnlts0
- Organization: PTT Research, The Netherlands
- References: <12387@pinard> <22041@venera.isi.edu> <1992Jul28.104754.1@research.ptt.nl> <22062@venera.isi.edu>
- Date: Wed, 29 Jul 1992 15:41:10 GMT
- Lines: 52
-
- In article <22062@venera.isi.edu>, finn@isi.edu (Greg Finn) writes:
-
- >>> The live audio multicast of the IETF meeting last week was
- >>> carried to at least 100 if not 200 sites and a few continents.
-
- >>Broadcasting <whatever> seems an order of magnitude simpler to me than
- >>interactive video or voice. Whatever the variance in delay is, you just need a
- >>sufficiently large buffer at the receiving end to restore timing requirements.
- >>And if the network load is sufficiently low, the loss of data can be kept to
- >>an acceptable level.
-
- > No. Multicast is NOT broadcasting. A routing tree is
- > constructed so that the traffic flows according to what is ideally a
- > minimum-cost spanning tree. Hardly broadcast I think.
-
- I agree. The essence is that there's hardly any real time contraints when
- doing none-interactive multicast.
-
-
- > Interactive multi-media conferencing experiments have gone on
- > over the Internet for quite a few years. Multi-site teleconferencing
- > goes on between sites that have the hardware every couple of days.
-
- I'm curious about the delays (and the amount of destination buffering) that
- were experienced in those experiments. The present-day target for interactive
- use is 100ms one-way delay and actually coding experts here are complaining.
- They'd like to see that down to 50ms.
-
-
- > Leading edge work on this goes on at a number of DARPA
- > affiliated labs and has been for years. Whether it will achieve
- > widespread commercial introduction awaits high-speed long-haul network
- > costs dropping a lot, which has very little to do with ATM or any
- > protocols for that matter.
-
- Well, compression helps ... but also takes some time. If there's delay in the
- transmitting coding, propagation delay and decoding delay, there's not much to
- spend on queueing delay in the network if the "target" of 50-100ms is to be
- reached.
-
- To keep the queueing delay low, (actually the 1E-x quantile of the delay
- destribution) there's (as far as I can see) only two solutions:
-
- 1) a low network load. More precisely: keep the amount of interference low.
-
- 2) switch _small_ chunks of data so the result of interfering data streams
- is proportionally smaller.
-
- ATM is just targeting on the latter to enable several connections to be
- multiplexed on those costly links.
-
- Regards, <kees>
-