Cell Relay Archive

[sthaug@nethelp.no (Steinar Haug)]

[manfredi@arl.bna.boeing.com]

|   > |   start forgetting tcp.
|   > |
|   > |   think of using sscop in an end-to-end fashion.
|   >
|   > Good luck in getting ATM in all end systems. Personally, I wouldn't
|   > want to bet on what will be forgotten first, TCP or ATM...
|   
|   Actually, the issue is not ATM vs TCP at all. It is instead SSCOP vs TCP.
|   Not that I disagree with your emotional outburst, Steinar, but if ATM is
|   to be used for reliable data transmission, it requires a
|   connection-oriented protocol just as IP does.

My "emotional outburst" what somewhat of a reaction to the above statement
about "start forgetting tcp", but I'm serious too: I'm not convinced that
that ATM will outlive TCP. There are of course people who will disagree
strongly.

|   After all, both ATM and IP
|   are best effort media, and it's only misnomer that calls ATM "connection
|   oriented." It is not. It is circuit switched, but still best effort.
|   
|   So ATM needs something, and its native connection-oriented, error-free
|   protocol is called SSCOP (Service Specific Connection Oriented Protocol,
|   Q.SAAL1). As far as I can tell, SSCOP and TCP are functionally similar. I
|   have no idea whether SSCOP is any more "efficient" than TCP, when running
|   over any of the AALs.

And that's where we need more hard data. We know quite a bit about how to
implement TCP efficiently today, and what kind of performance we can get
from different types of TCP/IP stacks. We need similar info for SSCOP. We
need "ttcp" and NetPerf for SSCOP, and we need people to measure different
protocol stacks, drivers and ATM cards.

I'm tempted to say that until more such data is available, any claims
about the superiority of SSCOP over TCP is just so much handwaving.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no