home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 677 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.3 KB  |  52 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: SSCOP better than TCP?
  5. Message-ID: <1992Nov9.181708.24894@sics.se>
  6. Organization: Swedish Institute of Computer Science, Kista
  7. Date: Mon, 9 Nov 1992 18:17:08 GMT
  8. Lines: 42
  9.  
  10. goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
  11.  
  12. > Just in case anyone's wondering, SSCOP (service-specific
  13. > connection-oriented protocol) is the service-specific sublayer that sits
  14. > above AAL3/4 OR  AAL 5 to create a connection-oriented data link
  15. > service.
  16. > ...
  17. > Or if you want "end-to-end ATM", it can be used to deliver
  18. > a transport-like service.
  19.  
  20. Sigh... I thought everyone had learned about the end-to-end argument by
  21. now.  The link layer (ATM) has no business providing a function that higher
  22. layers also have to provide.  If this synopsis is accurate, SSCOP sounds like
  23. a remarkably dumb idea.
  24.  
  25. > Personally, I think datagramme services can use it too:  If you have a
  26. > lot of loss in the ATM layer, then TCP recovery (single selective
  27. > recovery, at best) will not be  very effective at high speeds over
  28. > multi-hop (or other long delay) links.  For pure local use, it might be
  29. > overkill, but it's not so hard to build so why not?
  30.  
  31. TCP will run just fine over multihop gigabit links.  There's some
  32. misunderstanding here.
  33.  
  34. Most TCPs currently rexmit one segment per rtt for two reasons: (1) the
  35. receiving TCP doesn't use selective acks, so all that is known is that a segmentat the edge of the window was lost.  So the only segment that the sending
  36. TCP knows needs retransmission is the first segment, so that's the one to send;
  37. (2) the usual cause of loss right now is congestion, which makes it all the
  38. more important to only launch segments known to be missing (to avoid
  39. overloading the network further with useless duplicates).
  40.  
  41. Another problem for TCP with high-bandwidth paths is that the window size
  42. is too small.
  43.  
  44. However, there are standard TCP extensions for high-bandwidth paths that
  45. extend the window size and provide for selective acks and better RTT timing.
  46. (See RFC 1323 -- which is a proposed standard and note these extensions are
  47. deployed in some implementations, like Cray's).  Testing to date shows that
  48. this TCP (which interoperates with older versions) runs at gigabit speeds
  49. just fine.
  50.  
  51. Craig
  52.