home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 710 < prev    next >
Encoding:
Text File  |  1992-11-12  |  4.8 KB  |  99 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!sgiblab!sgigate!sgi!rigden.wpd.sgi.com!rpw3
  3. From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
  4. Subject: Re: clarifying the role of SSCOP?
  5. Message-ID: <s92deoo@sgi.sgi.com>
  6. Sender: rpw3@rigden.wpd.sgi.com
  7. Organization: Silicon Graphics, Inc.  Mountain View, CA
  8. Date: Thu, 12 Nov 1992 12:23:56 GMT
  9. Lines: 88
  10.  
  11. goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
  12. +---------------
  13. | Will ATM be that bad?  I hope not.  I know how to keep it from being
  14. | very lossy.  But I'm not sure the CCITT does.  And if it's cheaper in 
  15. | the long run to run the circuits at 95% utilization with say 1% loss 
  16. | (and selective retransmission) than to run them at 90% with 0.001% loss,
  17. | then why not?  And if you run it even lossier (hey, it may not be
  18. | _planned_), then local retransmission begins to look good.
  19. +---------------
  20.  
  21. Fred, I think you're exaggerating the possibilities for raw cell loss due
  22. to transmission effects [not congestion, but see below]. Remember, this same
  23. ATM network has got to carry voice traffic with no AAL at all (well, AAL1
  24. is practically no AAL). Every cell dropped will be a 6ms gap in the conver-
  25. sation (12ms, if 32 Kb/s ADPCM is used). And depending on such a good error
  26. rate should not be surprising; today we have *no* retransmission on *any*
  27. long-haul voice channels. (We do have FEC on satellite circuits, but that's
  28. not retransmission.)
  29.  
  30. I am quite confident that -- in the absence of congestion -- the global ATM
  31. network will have a cell error rate low enough to allow traditional end-to-
  32. end retransmission of AAL5 packets to be reasonable. And I am also confident
  33. that the call setup procedures will not allow significant congestion-induced
  34. cell loss on constant-bit-rate circuits [well, in the absence of TASI...].
  35. It's just too easy to avoid it by simply not completing the call if the
  36. requested bandwidth isn't there.
  37.  
  38. HOWEVER... I do not believe the same to be true if LAN-like bursty traffic
  39. is allowed to create congestion in small-buffered ATM switches ["small" is
  40. by comparison with the buffer sizes one would configure for a traditional
  41. IP router with a similar load on it.]
  42.  
  43. I fear that because of the small buffers, the congestion (and thus, cell loss)
  44. will be *far* worse than anything we have ever seen in the Intenet to date,
  45. and that we *have* to have some form of hop-by-hop flow control on bursty
  46. traffic so that the net simply does not *allow* congestion-induced cell loss.
  47. When even *one* full-sized AAL5 PDU (64 KB) sent at the full link rate may
  48. overflow some switches' output queues (after all, that's 1366 cells!),
  49. end-to-end congestion avoidance is impossible. [It's always too late.]
  50.  
  51. We either have to either (1) do "leaky-bucket" rate control to never exceed
  52. the call's guaranteed bandwidth, which reopens *all* the "dynamic bandwidth"
  53. issues we have already with IP over X.25 or IP over multiple BRIs, and which
  54. *never* lets a single connection get the full bandwidth of the ATM access
  55. link (*boo* *hiss*), or (2) we have to have hop-by-hop flow control (call
  56. it "back-pressure" if you prefer) on bursty traffic, at a pretty fine-grained
  57. level (a few cells or a few 10's of cells).
  58.  
  59. +---------------
  60. | I'm not saying everyone will need SSCOP.  Just that it may be a nice tool
  61. | when things go wrong, and not a very expensive one to keep around anyway.
  62. +---------------
  63.  
  64. But it's the *wrong* tool to try and solve burstiness-induced congestion.
  65. Hop-by-hop flow control (or reasonable-sized buffers for bursty traffic,
  66. which I don't hold much hope for) is a much better tool for this particular
  67. problem.
  68.  
  69. [See a previous article for a proposed hop-by-hop flow control which would
  70. be a lot simpler than per-VC credits but just as effective (I think).]
  71.  
  72.  
  73. -Rob
  74.  
  75. p.s. Back at Dig. Comm. Assoc. circa 1972, we used hop-by-hop per-VC credits
  76. (we called them "pre-ACKs") in our statistical multiplexers. Worked like a
  77. charm! We *never* dropped data due to internal network "congestion" -- we
  78. simply didn't permit it! But it took a lot of computes *and* large buffers,
  79. which is why I don't recommend it for ATM.
  80.  
  81. If the sending host or terminal at the edge of the network wouldn't or
  82. couldn't respond to the provided flow-control indications (XOFF/XON or CTS),
  83. we of course were forced to drop data, but we also then "notified" the host
  84. by dropping the virtual circuit! (*Boom*) "Carrier fail disconnect..."
  85. [A reasonable policy for the stat-mux market at that time.]
  86.  
  87. [We also did hop-by-hop retransmission, but that's another issue. Link speeds
  88. were slow then, and multi-hop latency was a big problem when echoing keyboards
  89. through the network. Hop-by-hop retransmission, with NACKs, not timeouts,
  90. helped keep the "stutter" due to error recovery short.]
  91.  
  92.  
  93. -----
  94. Rob Warnock, MS-9U/510        rpw3@sgi.com
  95. Silicon Graphics, Inc.        (415)390-1673
  96. 2011 N. Shoreline Blvd.
  97. Mountain View, CA  94043
  98.  
  99.