home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dcom / cellrel / 1018 < prev    next >
Encoding:
Text File  |  1993-01-25  |  2.2 KB  |  56 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!att!allegra!hgs
  3. From: hgs@allegra.att.com (Henning G. Schulzrinne)
  4. Subject: Re: Bandwidth Control
  5. Message-ID: <1993Jan25.125059.20389@allegra.att.com>
  6. Organization: AT&T Bell Laboratories, Murray Hill, NJ
  7. References: <3402@ucl-cs.uucp>
  8. Date: Mon, 25 Jan 1993 12:50:59 GMT
  9. Lines: 45
  10.  
  11. In article <3402@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
  12. >
  13. >
  14. >  kyma@shell.portal.com (Matt J Young) writes:
  15. > >+---------------
  16. > >| Experts analysis has shown that statistical multiplexing
  17. > >| over the WAN is simply not possible.
  18. > >+---------------
  19. >
  20. >  Rob Warnock, MS-9U/510        rpw3@sgi.com replies:
  21. > >Then they need some new experts. At DCA, we were doing "statistical
  22. > >multiplexing over the WAN" with a cell-relay-like system in 1971, and
  23. > >people have been doing it ever since. It is *easier* to do in a WAN
  24. > >environment, since you are averaging more traffic sources.
  25. >
  26. >absolutely they need new experts - sounds like someone is quoting
  27. >professional litigation rytpe "experts":-)
  28. >
  29. >papers from bellcore and cabruidge computer labs report on as much as
  30. >6-10 fold increase in network utilisation for video traffic if you use stat
  31. >muxing rather than fixed peak bandwidth allocation
  32. >
  33. >i havnt seen any quality papers contradict this (based on garret's
  34. >video stats from domestic entertainment video and cambridges real
  35. >video conferecing stats wit hthe pandor system over CFRs (i.e. real
  36. >ATM style nets)....
  37. >
  38. >jon
  39.  
  40. The paper by Reibman and Berger, Globecom '92, p. 314ff does a fairly
  41. in-depth comparison of CBR and VBR video (subject to leaky-bucket
  42. constraints). It shows that significant multiplexing gains are possible,
  43. but with leaky-bucket constraints and without knowing the source
  44. behavior in advance, it will be extremely difficult to get more than
  45. a factor of 2 if you want loss guarantees and if network buffers are
  46. small. Depending on your viewpoint, this means that either
  47. 1) leaky buckets and guarantees are a 'bad thing' if you want cheap
  48. video service
  49.  
  50. 2) anything but peak rate allocation is going to be difficult, unless
  51. you can describe your source very accurately (e.g., for video-on-demand)
  52.  
  53.  
  54. Henning Schulzrinne
  55. hgs@research.att.com
  56.