home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 695 < prev    next >
Encoding:
Text File  |  1992-11-10  |  5.2 KB  |  98 lines

  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!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: SSCOP better than TCP?
  5. Message-ID: <1992Nov11.045143.18325@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 04:32:47 GMT
  9. Lines: 87
  10.  
  11.  
  12. In article <1992Nov9.181708.24894@sics.se>, craig@sics.se (Craig Partridge) writes...
  13. >Sigh... I thought everyone had learned about the end-to-end argument by
  14. >now.  The link layer (ATM) has no business providing a function that higher
  15. >layers also have to provide.  If this synopsis is accurate, SSCOP sounds like
  16. >a remarkably dumb idea.
  17.  
  18. Sigh sigh... I thought everyone by now had learned that there's more 
  19. than one way to skin cats or design networks too!  The "end-to-end 
  20. argument" is the fundamental paradigm behind TCP/IP.  It is valid:  If 
  21. you have a good end-to-end protocol, the underlying ones can be cut some 
  22. slack.
  23.  
  24. But not all applications converge atop TCP!  Four examples of 
  25. real-world protocols that don't are Signaling System NO. 7 (The Protocol 
  26. From Hell), Q.931/Q.93B signaling, X.25 and SNA.  Now we can get into 
  27. arguments over whether X.25 just dumb or is completely totally insane, 
  28. or whether SNA should be replaced, but market reality says that they're 
  29. quite significant.  ANd they expect reliable data links.  Ditto for 
  30. signaling.  Now Q.93X (DSS1 et al) only has local significance, so a 
  31. data link _is_ end-to-end!  That means there's no need for a network 
  32. layer, and datalink provides a transport-like service.  
  33.  
  34. SSCOP is being defined in CCITT as part of the Q.saal (Signaling ATM
  35. Adaptation Layer) project, where it will be used for user signaling (as 
  36. an alternative to go-back-N LAPD procedures) and network signaling (as 
  37. an alternative to truly bizarre MTP-2 procedures).  These are not 
  38. potential TCP applications!
  39.  
  40. >> Personally, I think datagramme services can use it too:  If you have a
  41. >> lot of loss in the ATM layer, then TCP recovery (single selective
  42. >> recovery, at best) will not be  very effective at high speeds over
  43. >> multi-hop (or other long delay) links.  For pure local use, it might be
  44. >> overkill, but it's not so hard to build so why not?
  45. >TCP will run just fine over multihop gigabit links.  There's some
  46. >misunderstanding here.
  47. >Most TCPs currently rexmit one segment per rtt for two reasons: (1) the
  48. >receiving TCP doesn't use selective acks, so all that is known 
  49. >is that a segmentat the edge of the window was lost.  So the only 
  50. >segment that the sending
  51. >TCP knows needs retransmission is the first segment, so that's the one to send;
  52. >(2) the usual cause of loss right now is congestion, which makes it all the
  53. >more important to only launch segments known to be missing (to avoid
  54. >overloading the network further with useless duplicates).
  55.  
  56. Most TCPs don't have selective Acks.  TCP is run in end systems ranging 
  57. from small PCs to large Crays.  ATM paths may be shared by all of them.
  58. I'm all for improving TCP!  Cray's New Improved TCP is a Good Thing.
  59.  
  60. Absent new TCP, local retransmission over lossy links can pay off.
  61. Especially long, fat pipes.  It's no coincidence that COMSAT is leading 
  62. the SSCOP effort!  If you fear as I do that ATM networks will be 
  63. somewhat lossy in practice, more so than existing links, then there's
  64. simple economic benefits to retransmitting for one hop instead of over 
  65. many.
  66.  
  67. Congestion's a different question.  What works for TCP/IP (and for that 
  68. matter FR) isn't quite right for ATM, for any number of reasons which 
  69. are beyond the scope of this discussion.  And I've spent a LOT of time 
  70. fighting congestion battles in the ATM world, and it's not over yet!
  71. One thing's clear though:  The TCP slow-start approach won't be the key 
  72. to ATM ConCon.  However, if you don't have selective recovery, and 
  73. retransmit the whole window (go-back-N), you're always causing grief. 
  74. SSCOP is very good about this.  It doesn't waste bandwidth.
  75.  
  76. But let's look at SSCOP's potential second use.  This is the New Network 
  77. Paradigm that ATM is ushering in, where switched-topology networks
  78. replace LANs, WANs and Datagrammes.  In this model ("end-to-end ATM" is 
  79. the picture), the upper-physical layer (ATM) links end systems
  80. directly, sans bridges or routers.  ATM doesn't provide reliability.
  81. Now in Old Paradigm, layer 3 datagrammes break reliability, so layer 2 
  82. reliability (SSCOP as a data link) is wasted, and Layer 4 fixes it all 
  83. up.  In New Paradigm, layer 1 does what layer 3 does, delivering 
  84. unreliable blocks end-to-end, so layers 2 and 4 are merged!
  85.  
  86. SSCOP's a good candidate for that new role.  It takes ATM and, with some 
  87. additional functions which are beyond the scope of the _present_ work 
  88. but can be neatly layered above it, delivers most of the transport 
  89. service.  SSCOP's potentially most of the TCP for when all of the
  90. packets are short, fixed in size, and clocked out according to a
  91. rate-based formula. 
  92. ---
  93. Fred R. Goldstein   goldstein@carafe.tay2.dec.com 
  94. k1io             or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
  95. Standard Disclaimer:  Opinions are mine alone; sharing requires permission.
  96.