home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 704 < prev    next >
Encoding:
Text File  |  1992-11-11  |  1.9 KB  |  42 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!mcsun!sunic!sics.se!craig
  3. From: craig@sics.se (Craig Partridge)
  4. Subject: clarifying the role of SSCOP?
  5. Message-ID: <1992Nov11.185930.2664@sics.se>
  6. Organization: Swedish Institute of Computer Science, Kista
  7. Date: Wed, 11 Nov 1992 18:59:30 GMT
  8. Lines: 32
  9.  
  10. Can we back up a little bit?  There appears to be some contradictions in the
  11. notes about SSCOP.  Let me see if I can characterize my puzzlement:
  12.  
  13.     Is SSCOP always to be run over AAL5, or is it really just for
  14.     applications that specially request it (like SS7, or telephone
  15.     calls over satellite links)?
  16.      
  17. It seems to me that different notes seem to suggest different answers.
  18.  
  19. From my point of view, as long as I can always ignore SSCOP (i.e. not
  20. have it mucking up my cells for data communications), I'm happy.  All these
  21. arguments about what SSCOP will do for general data comm are, in my view,
  22. specious.  (End-to-end error recovery is better, regardless of speed and
  23. error rates.  One can tune the end-to-end protocols to dynamically adapt
  24. to the environment presented).
  25.  
  26.     But I understand that there are folks outside data comm who like
  27. to think of the network as providing a reliable service, and hey, if they
  28. want the pain, that's their business.
  29.  
  30. Craig
  31. craig@bbn.com
  32.  
  33. PS: If it helps understand where I'm coming from.  A few years ago a number
  34. of "expert reports" were published saying that high-speed networks and new
  35. technologies would force us to completely rethink data networking.  I thought
  36. those statements were silly -- the likelihood that the tried and true
  37. principles of data networking would all get thrown out the window seemed
  38. small.  So I've stuck to philosophy that what we have learned from experience
  39. is right, until someone proves it wrong.  So I stick to using the end-to-end
  40. argument (which is not TCP/IP specific and was formulated after TCP/IP was
  41. developed), the principle that end-to-end error recovery is best, etc.
  42.