From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: clarifying the role of SSCOP?
Organization: Digital Equipment Corp., Littleton MA USA
Date: Wed, 11 Nov 1992 23:13:00 GMT


In article <1992Nov11.185930.2664@sics.se>, craig@sics.se (Craig Partridge) writes...
>Can we back up a little bit?  There appears to be some contradictions in the
>notes about SSCOP.  Let me see if I can characterize my puzzlement:

>    Is SSCOP always to be run over AAL5, or is it really just for
>    applications that specially request it (like SS7, or telephone
>    calls over satellite links)?

It's a protocol  that the network won't look at except for signaling.
You can use it if you want.  You can ignore it if you want.  It's free.
You just pay for the implementation :-) .

>It seems to me that different notes seem to suggest different answers.

>From my point of view, as long as I can always ignore SSCOP (i.e. not
>have it mucking up my cells for data communications), I'm happy.  All these
>arguments about what SSCOP will do for general data comm are, in my view,
>specious.  (End-to-end error recovery is better, regardless of speed and
>error rates.  One can tune the end-to-end protocols to dynamically adapt
>to the environment presented).

Well, you're free to ignore it.  I personally inveighed for a while
against ALL AALs, because I don't think frame recovery makes as much
sense as cell recovery.  Of course that was before AAL5.  I could do
cell recover in BLINKBLT in as little overhead as AAL3/4.  AAL5 has 
lower overhead so it may be a better deal.

The end-to-end argument is not _always_ valid.  It reminds me of the 
original arguments against cell recovery.  AT&T "proved" that it doesn't 
do much good across a WIDE range of loss rates, from around 10^-3 to 
10^-8.  Trouble is, the curve was crossing over at 10^-3 and cell 
recovery was much better at, say, 10^-2 loss.  So how lossy is your 
network?  How busy is it?  Who's paying for the bandwidth?  How good are 
your cell emission pacers?  How big are the buffers?  etc. etc.  In 
other words, they proved that you don't need cell recovery with a 
moderately low loss rate.

But I've used networks (TCP/IP) with a very, very high packet loss rate.
Like 50% on a given hop.  Now if you have three hops like that, then you 
will get about 12.5% of your packets across each time.  End-to-end
recovery is pretty bogus!  But hop-by-hop recovery would have worked a 
lot better; each recovery would have occurred locally and with a 50% 
chance of getting through each time.  Do the math yourself.

Okay, you may ask, where does this idiotic network exist?  Stop by 
rec.radio.amateur.packet and ask about some of the 1200 bps 2 meter 
half-duplex IP-over-AX.25 "LANs".  They're basically Aloha, with some 
really bad periods of congestion caused by "hidden transmitter 
syndrome".  I use this mess regularly. And of course I don't go more 
than two hops, because TCP just takes too long to recover.  Note that we 
usually hold our TCP timers back to "linear" rather than "exponential", 
lest we wait weeks to retransmit.

Will ATM be that bad?  I hope not.  I know how to keep it from being
very lossy.  But I'm not sure the CCITT does.  And if it's cheaper in 
the long run to run the circuits at 95% utilization with say 1% loss 
(and selective retransmission) than to run them at 90% with 0.001% loss,
then why not?  And if you run it even lossier (hey, it may not be
_planned_), then local retransmission begins to look good.  Just like 
it does, to me at least, on 145.51.  Where I end up sending my SMTP
to an adjacent node to let _it_ pass it along, since end-to-end fails.

I'm not saying everyone will need SSCOP.  Just that it may be a nice 
tool when things go wrong, and not a very expensive one to keep around 
anyway.
---
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