home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 275 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.8 KB  |  65 lines

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