home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.cell-relay
- 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
- From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
- Subject: Re: SSCOP better than TCP?
- Message-ID: <1992Nov11.045143.18325@nntpd.lkg.dec.com>
- Sender: usenet@nntpd.lkg.dec.com (USENET News System)
- Organization: Digital Equipment Corp., Littleton MA USA
- Date: Wed, 11 Nov 1992 04:32:47 GMT
- Lines: 87
-
-
- In article <1992Nov9.181708.24894@sics.se>, craig@sics.se (Craig Partridge) writes...
- >Sigh... I thought everyone had learned about the end-to-end argument by
- >now. The link layer (ATM) has no business providing a function that higher
- >layers also have to provide. If this synopsis is accurate, SSCOP sounds like
- >a remarkably dumb idea.
-
- Sigh sigh... I thought everyone by now had learned that there's more
- than one way to skin cats or design networks too! The "end-to-end
- argument" is the fundamental paradigm behind TCP/IP. It is valid: If
- you have a good end-to-end protocol, the underlying ones can be cut some
- slack.
-
- But not all applications converge atop TCP! Four examples of
- real-world protocols that don't are Signaling System NO. 7 (The Protocol
- From Hell), Q.931/Q.93B signaling, X.25 and SNA. Now we can get into
- arguments over whether X.25 just dumb or is completely totally insane,
- or whether SNA should be replaced, but market reality says that they're
- quite significant. ANd they expect reliable data links. Ditto for
- signaling. Now Q.93X (DSS1 et al) only has local significance, so a
- data link _is_ end-to-end! That means there's no need for a network
- layer, and datalink provides a transport-like service.
-
- SSCOP is being defined in CCITT as part of the Q.saal (Signaling ATM
- Adaptation Layer) project, where it will be used for user signaling (as
- an alternative to go-back-N LAPD procedures) and network signaling (as
- an alternative to truly bizarre MTP-2 procedures). These are not
- potential TCP applications!
-
- >> Personally, I think datagramme services can use it too: If you have a
- >> lot of loss in the ATM layer, then TCP recovery (single selective
- >> recovery, at best) will not be very effective at high speeds over
- >> multi-hop (or other long delay) links. For pure local use, it might be
- >> overkill, but it's not so hard to build so why not?
- >
- >TCP will run just fine over multihop gigabit links. There's some
- >misunderstanding here.
- >
- >Most TCPs currently rexmit one segment per rtt for two reasons: (1) the
- >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
- >TCP knows needs retransmission is the first segment, so that's the one to send;
- >(2) the usual cause of loss right now is congestion, which makes it all the
- >more important to only launch segments known to be missing (to avoid
- >overloading the network further with useless duplicates).
-
- Most TCPs don't have selective Acks. TCP is run in end systems ranging
- from small PCs to large Crays. ATM paths may be shared by all of them.
- I'm all for improving TCP! Cray's New Improved TCP is a Good Thing.
-
- Absent new TCP, local retransmission over lossy links can pay off.
- Especially long, fat pipes. It's no coincidence that COMSAT is leading
- the SSCOP effort! If you fear as I do that ATM networks will be
- somewhat lossy in practice, more so than existing links, then there's
- simple economic benefits to retransmitting for one hop instead of over
- many.
-
- Congestion's a different question. What works for TCP/IP (and for that
- matter FR) isn't quite right for ATM, for any number of reasons which
- are beyond the scope of this discussion. And I've spent a LOT of time
- fighting congestion battles in the ATM world, and it's not over yet!
- One thing's clear though: The TCP slow-start approach won't be the key
- to ATM ConCon. However, if you don't have selective recovery, and
- retransmit the whole window (go-back-N), you're always causing grief.
- SSCOP is very good about this. It doesn't waste bandwidth.
-
- But let's look at SSCOP's potential second use. This is the New Network
- Paradigm that ATM is ushering in, where switched-topology networks
- replace LANs, WANs and Datagrammes. In this model ("end-to-end ATM" is
- the picture), the upper-physical layer (ATM) links end systems
- directly, sans bridges or routers. ATM doesn't provide reliability.
- Now in Old Paradigm, layer 3 datagrammes break reliability, so layer 2
- reliability (SSCOP as a data link) is wasted, and Layer 4 fixes it all
- up. In New Paradigm, layer 1 does what layer 3 does, delivering
- unreliable blocks end-to-end, so layers 2 and 4 are merged!
-
- SSCOP's a good candidate for that new role. It takes ATM and, with some
- additional functions which are beyond the scope of the _present_ work
- but can be neatly layered above it, delivers most of the transport
- service. SSCOP's potentially most of the TCP for when all of the
- packets are short, fixed in size, and clocked out according to a
- rate-based formula.
- ---
- Fred R. Goldstein goldstein@carafe.tay2.dec.com
- k1io or goldstein@delni.enet.dec.com voice:+1 508 952 3274
- Standard Disclaimer: Opinions are mine alone; sharing requires permission.
-