From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: SSCOP better than TCP?
Organization: Digital Equipment Corp., Littleton MA USA
Date: Wed, 11 Nov 1992 04:32:47 GMT


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.
Newsgroups: comp.dcom.cell-relay