home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 706 < prev    next >
Encoding:
Text File  |  1992-11-11  |  4.2 KB  |  81 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!haven.umd.edu!decuac!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!carafe.enet.dec.com!goldstein
  3. From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
  4. Subject: Re: clarifying the role of SSCOP?
  5. Message-ID: <1992Nov11.232255.24793@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Organization: Digital Equipment Corp., Littleton MA USA
  8. Date: Wed, 11 Nov 1992 23:13:00 GMT
  9. Lines: 70
  10.  
  11.  
  12. In article <1992Nov11.185930.2664@sics.se>, craig@sics.se (Craig Partridge) writes...
  13. >Can we back up a little bit?  There appears to be some contradictions in the
  14. >notes about SSCOP.  Let me see if I can characterize my puzzlement:
  15.  
  16. >    Is SSCOP always to be run over AAL5, or is it really just for
  17. >    applications that specially request it (like SS7, or telephone
  18. >    calls over satellite links)?
  19.  
  20. It's a protocol  that the network won't look at except for signaling.
  21. You can use it if you want.  You can ignore it if you want.  It's free.
  22. You just pay for the implementation :-) .
  23.  
  24. >It seems to me that different notes seem to suggest different answers.
  25.  
  26. >From my point of view, as long as I can always ignore SSCOP (i.e. not
  27. >have it mucking up my cells for data communications), I'm happy.  All these
  28. >arguments about what SSCOP will do for general data comm are, in my view,
  29. >specious.  (End-to-end error recovery is better, regardless of speed and
  30. >error rates.  One can tune the end-to-end protocols to dynamically adapt
  31. >to the environment presented).
  32.  
  33. Well, you're free to ignore it.  I personally inveighed for a while
  34. against ALL AALs, because I don't think frame recovery makes as much
  35. sense as cell recovery.  Of course that was before AAL5.  I could do
  36. cell recover in BLINKBLT in as little overhead as AAL3/4.  AAL5 has 
  37. lower overhead so it may be a better deal.
  38.  
  39. The end-to-end argument is not _always_ valid.  It reminds me of the 
  40. original arguments against cell recovery.  AT&T "proved" that it doesn't 
  41. do much good across a WIDE range of loss rates, from around 10^-3 to 
  42. 10^-8.  Trouble is, the curve was crossing over at 10^-3 and cell 
  43. recovery was much better at, say, 10^-2 loss.  So how lossy is your 
  44. network?  How busy is it?  Who's paying for the bandwidth?  How good are 
  45. your cell emission pacers?  How big are the buffers?  etc. etc.  In 
  46. other words, they proved that you don't need cell recovery with a 
  47. moderately low loss rate.
  48.  
  49. But I've used networks (TCP/IP) with a very, very high packet loss rate.
  50. Like 50% on a given hop.  Now if you have three hops like that, then you 
  51. will get about 12.5% of your packets across each time.  End-to-end
  52. recovery is pretty bogus!  But hop-by-hop recovery would have worked a 
  53. lot better; each recovery would have occurred locally and with a 50% 
  54. chance of getting through each time.  Do the math yourself.
  55.  
  56. Okay, you may ask, where does this idiotic network exist?  Stop by 
  57. rec.radio.amateur.packet and ask about some of the 1200 bps 2 meter 
  58. half-duplex IP-over-AX.25 "LANs".  They're basically Aloha, with some 
  59. really bad periods of congestion caused by "hidden transmitter 
  60. syndrome".  I use this mess regularly. And of course I don't go more 
  61. than two hops, because TCP just takes too long to recover.  Note that we 
  62. usually hold our TCP timers back to "linear" rather than "exponential", 
  63. lest we wait weeks to retransmit.
  64.  
  65. Will ATM be that bad?  I hope not.  I know how to keep it from being
  66. very lossy.  But I'm not sure the CCITT does.  And if it's cheaper in 
  67. the long run to run the circuits at 95% utilization with say 1% loss 
  68. (and selective retransmission) than to run them at 90% with 0.001% loss,
  69. then why not?  And if you run it even lossier (hey, it may not be
  70. _planned_), then local retransmission begins to look good.  Just like 
  71. it does, to me at least, on 145.51.  Where I end up sending my SMTP
  72. to an adjacent node to let _it_ pass it along, since end-to-end fails.
  73.  
  74. I'm not saying everyone will need SSCOP.  Just that it may be a nice 
  75. tool when things go wrong, and not a very expensive one to keep around 
  76. anyway.
  77. ---
  78. Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
  79. k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
  80. Standard Disclaimer:  Opinions are mine alone; sharing requires permission.
  81.