home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 670 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.0 KB  |  40 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!think.com!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!carafe.enet.dec.com!goldstein
  3. From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
  4. Subject: Re:  new AAL (SSCOP?)
  5. Message-ID: <1992Nov8.231642.7509@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Organization: Digital Equipment Corp., Littleton MA USA
  8. Date: Sun, 8 Nov 1992 23:11:42 GMT
  9. Lines: 29
  10.  
  11.  
  12. Well, I'm back from T1S1!
  13.  
  14. Just in case anyone's wondering, SSCOP (service-specific 
  15. connection-oriented protocol) is the service-specific sublayer that sits 
  16. above AAL3/4 OR  AAL 5 to create a connection-oriented data link 
  17. service.  You can run anything above it that wants local retransmission. 
  18. For example, it will almost certainly be used for signaling (although 
  19. some countries still prefer go-back-N procedures, since signaling is
  20. low speed).  Or if you want "end-to-end ATM", it can be used to deliver 
  21. a transport-like service.
  22.  
  23. SSCOP is a multiple-selective-recovery protocol.  It can have moby 
  24. windows (say, a 10 Gbps satellite link!) with lots of gaps being filled 
  25. in as well as new data being sent.  The semantics are basically 
  26. "checkpoint selective recovery", though SSCOP is not quite aligned with  
  27. the CSRDLC protocol that the OSI crowd is working on.  Close, though.
  28. Note that SSCOP is NOT finished yet.  We have a few details left to 
  29. attend to.  But the outline is pretty clear.
  30.  
  31. Personally, I think datagramme services can use it too:  If you have a 
  32. lot of loss in the ATM layer, then TCP recovery (single selective
  33. recovery, at best) will not be  very effective at high speeds over 
  34. multi-hop (or other long delay) links.  For pure local use, it might be 
  35. overkill, but it's not so hard to build so why not?
  36. ---
  37. Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
  38. k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
  39. Standard Disclaimer:  Opinions are mine alone; sharing requires permission.
  40.