home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / cellrel / 262 < prev    next >
Encoding:
Text File  |  1992-07-27  |  2.4 KB  |  55 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)
  4. Subject: Re: Congestion Avoidance
  5. Message-ID: <1992Jul27.210256.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: <1992Jul18.230550.3046@sics.se> <1992Jul19.130005.1@research.ptt.nl> <1992Jul25.092823.12189@e2big.mko.dec.com> <k3jm90-.nagle@netcom.com> <miw.712192253@cc.uq.oz.au>
  10. Date: Mon, 27 Jul 1992 20:02:56 GMT
  11. Lines: 42
  12.  
  13. In article <miw.712192253@cc.uq.oz.au>, miw@cc.uq.oz.au (Mark I. Williams)
  14. writes: 
  15.  
  16. > You're right. Congestion avoidance is still the big bugbear for ATM.
  17. > There is still (or wasn't 8 months ago) a generally accepted algorithm
  18. > for bandwidth allocation that performed better than peak-rate
  19. > multiplexing, although everybody is sure that some degree of statistical
  20. > multiplexing will be possible.
  21. > 
  22. > Of course, that situation is where we are now. With the current
  23. > circuit-switched network we are using peak-rate multiplexing by
  24. > definition.
  25.  
  26. But it multiplexes! I don't think the term "statistical multiplexing" 
  27. (or even -sm- gain) is saying very much. Present day telephone networks are 
  28. also multiplexed; unscheduled so "statistically". 
  29.  
  30. If operator X would run an ATM network with plain (and safe) peak rate
  31. allocation and if we could make very fast signalling procedures to renegotiate
  32. the capacity on an already established connection, what would then be the
  33. difference with network Y that would allow "statistical multiplexing" in
  34. the ATM-sense? 
  35.  
  36. It's like trading in congestion probability (in Y only) against the probability 
  37. that the request for an increase in capacity is turned down (in X). I guess 
  38. that X is to be judged better than Y as during congestion a large number of 
  39. connections are going to suffer, as opposed to maybe a few in case X.
  40.  
  41. Regards, <kees>
  42.  
  43.  
  44.  
  45. Kees  van der Wal               e-mail: J.C.vanderWal@research.ptt.nl
  46. ----------------------------------------------------------------------------
  47. PTT Research Neher Laboratories                      Room: E130
  48. Sint Paulusstraat 4                     Fax: +31 70 3326477
  49. 2264 XZ  Leidschendam  The Netherlands               Phone: +31 70 3326295
  50. ----------------------------------------------------------------------------
  51.  
  52. Nullum magnum ingenium sine mixtura dementiae fuit.  -- Seneca
  53.  
  54. Just guessing: "No bright ideas without a few drops of insanity"?  -- <k>
  55.