HDTenEightyP/NetNews huggingface dataset:
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Congram
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 6 Nov 92 20:50:49 GMT


I picked up the article describing Congrams as mentioned by Rajiv
in his posting.            [Globecom 91].

Congrams is an application interface and internal management structure 
for providing access to virtual circuit capability, including the 
multiplexing of datagrams over a single path and the set up of
dedicated paths.

The structure includes the use of embedded router facilities, and management
of endpoint addresses.

It is these kinds of distributed protocols which need to be enabled, or
at least not locked out, as we approach a cell relay standard.  The 
Congram system could be built on top of a standard signaling system, but
heck, why not give the Congram protocol direct access to the path
tables themselves?  That is; rather than a signaling standard, just
standard a kind of bios access to the switch structures, and let 
various signaling standard be implemented, possibly at the same time.
Newsgroups: comp.dcom.cell-relay
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: new AAL (SSCOP?)
Organization: Digital Equipment Corp., Littleton MA USA
Date: Wed, 11 Nov 1992 04:56:31 GMT


In article <JH.92Nov10202227@etana.funet.fi>, jh@etana.funet.fi (Juha Heinanen) writes...
>Fine with me if the signalling folks decide that SSCOP is ok for them,
>but at least SSCOP should then be renamed as Signalling Specific
>Connection Oriented Protocol.  I haven't found much support in using
>it below any other connection oriented protocol.  For example, if
>someone wants to implement X.25 over ATM, a better choise is to map
>LAP B (or whatever the link layer standard for X.25 is) right over
>ALL5 rather than trying to do X.25 over a new thing, ie. SSCOP.

Juha,

At risk of seeming even more impetuous than usual (it's midnight),
what are they drinking over there in Yurop?  LAP-B over AAL5?

That's fine if the data rate is at traditional modem rates (say,
up to 64 kbps).  But LAP-B uses go-back-N recover and a maximum
window size of 7 frames.  If you want to deliver an X.25 VC with
a 9600 bps throughput, that's fine.  But if you want to deliver
a reliable stream of frames at high speed, you need something
designed for high speeds.  X.25 was designed for 1974's high speeds: 
V.29 was state of the art and 2400 bps was commonly shared by polling 
nodes!

Just as the TCP/IP fanatics are religious about TCP doing it all, 
I sometimes suspect many PTT types of believing that X.25 was dictated 
at the Sermon On the Mount. 
---
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
From: craig@sics.se (Craig Partridge)
Subject: SSCOP on-line?
Organization: Swedish Institute of Computer Science, Kista
Date: Mon, 9 Nov 1992 20:33:46 GMT

Has anyone got the SSCOP spec on line?
    
Thanks!

Craig
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.novell
From: news@iscnvx.ogi.edu
Newsgroups: comp.dcom.cell-relay
Subject: Re: new AAL (SSCOP?)
Date: 9 Nov 92 22:52:34 GMT
Article-I.D.: iscnvx.1992Nov9.225234.2523
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California

In article <JH.92Nov9215100@etana.funet.fi>, jh@etana.funet.fi (Juha Heinanen) writes:
>after reading all messages related to SSCOP, i noticed that also
>others suspected if there is sense in the current SSCOP proposal.
>
>we have two options:
>
>1. fix SSCOP to become a real transport protocol (hopefully the same
>as being worked in ISO)
>
>2. make whatever changes are needed to an existing transport protocol
>(eg. TCP) to satisfy the requirements of ATM (signalling)

Wave protocols like a very high speed transport with receiver initiated
selective recovery, rate based flow control, two way connection set up, 
and operates right over the path layer.  Explicit connection teardown, 
multicast optional (wave can do its own), software implementable checksum 
in trailer.  Wave doesn't need a network layer.
Matt Young
Lockheed
(408) 756-6789
Newsgroups: comp.dcom.cell-relay
From: dgr@RODIN (Daniel Robinson)
Subject: Re: Virtual Token Ring
Organization: Vitalink Communications, Fremont, California
Date: Tue, 10 Nov 1992 04:48:47 GMT

In article <1992Nov9.203140.10270@iscnvx.lmsc.lockheed.com> myoung@force.ssd.lmsc.lockheed.com writes:
+Token Based Flow Control
+	.
+	.
+	.
+Solution:
+
+Token passing systems have an inherent, though dumb flow control
+since no stations can transmit until it control of the token.

Hmmm, from one who works with token ring, I would like to expand the
scope of the adjective 'dumb' to include the entire process of token
passing.  No reflection on Mr. Young, it a nice turn of phrase.
Token rings are dumb because they require the terminal nodes to
understand the whole of the network mesh.

+Just like a token ring, the whole procedure takes place at the data link
+level.

I remember sitting in standards meetings for FDDI and listening
to people try to develop algorithms for figuring out if the ring
was up and what configuration the ring was in if it was up.  If
for some reason a station thought the ring was down, it was
obligated to bring the ring down itself by beaconing.  There was
a movement afoot to maintain a complete ring map in the lowest
layer of the stack so that the media controller would know
something about the topology and could make intelligent decisions
about when to beacon.  I proposed that it would be possible,
probable even that under certain circumstances that a form of
hysteresis would occur and that the network would oscillate between
being completely up and completely down, and asked if it were
possile to calculate under which circumstances this would happen.
I stopped going to meetings before an answer was found.  Oh well.

Token rings are seductively nice because they promise so much
in theory, but deliver so little.   Bring on Plan 9, or something
like it.

Daniel
Newsgroups: comp.dcom.cell-relay
From: earlf@trappist.net.com (Earl Ferguson Adv Dev)
Subject: Re: ATM "style"
Summary: Standards Inhibiting
Organization: Network Equipment Technologies
Date: Wed, 11 Nov 1992 08:13:35 GMT

In article <ru9l3ps@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>
>In our brave new world of almost religious adherence to standards, no
>non-standard thing can be ever be "better". And if better, will surely
>be stoned as heretical...
>
There are current examples of this in the ATM Forum. Larry Roberts
and NetExpress have proposed a very efficient method for establishing
momentary VCI/VPI paths for short communications which will take only 
a fraction of the time to completely transmit as the current proposed
call establishment based on Q.93B. But because it is not "standard" or
"standars based" it will not survive the ATM Forum implementation
agreements.

Yes, standards are an inhibitor to creative thought and development. 

---
Earl Ferguson
earlf@net.com
My personal opinions and NOT those of my employer.
Newsgroups: comp.dcom.cell-relay
From: jh@etana.funet.fi (Juha Heinanen)
Subject: Re: new AAL (SSCOP?)
Organization: Finnish University and Research Network
	<1992Nov9.135828.5489@iscnvx.lmsc.lockheed.com>
Date: Mon, 9 Nov 1992 19:51:00 GMT

after reading all messages related to SSCOP, i noticed that also
others suspected if there is sense in the current SSCOP proposal.

we have two options:

1. fix SSCOP to become a real transport protocol (hopefully the same
as being worked in ISO)

2. make whatever changes are needed to an existing transport protocol
(eg. TCP) to satisfy the requirements of ATM (signalling)

the worst option would be to define yet another transport protocol
which could only be used at the link layer.

my understanding, however, is that SSCOP has been advanced quite far
in ANSI, so people must react soon.  in the last ETSI meeting, SSCOP
didn't get much support and i hope the same will happen in the next
CCITT meeting.

-- juha
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958
-- 
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: SNMP and DIagnostics
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 9 Nov 92 14:10:13 GMT

SNMP

The SNMP community must have considered mechanisms for supporting SNMP 
objects over cell relay.  Path tables, node parameters, and physical 
device parameters must be read as SNMP objects.

Currently SNMP is designed for TCP/IP support, but I think some work
is being done to make SNMP protocol independent at that layer.  Have
the SNMP vendors signed onto the SSCOP signaling layer as a carrier
protocol?  

And Diagnostics:

At a deeper level, what about sniffer protocols? Don't we need some
capability to snoop through the virtual path tables, following some
path down its multi-hop links, reading out the path tables in route,
possibly splitting the snooper packet as the virtual path splits in a
one to many circuit.  Or how about finding a route around a particular 
physical link, then passing data through the link, bringing back the 
results for verification.  Or how about building a branch from an existing 
path, and bring the cell stream to some embedded protocol analyzer.

It seems that the sniffer protocols would need some more elementary 
access to the path tables, not wanting to rely on SCCOP which it
might be testing.

Why Not:

SCCOP must have some exploratory "pinging" protocol which it uses to
discover new links, check for new nodes and build nearest neighbor maps.
Why isn't this pinging protocol enhanced and made generally available
as a programmable layer?

There is a lot of software and a lot of protocols available already,
as well as companies with proprietary requirements.  Why not allow this
existing base of technology and distribution be ported directly to
the switches, operating their own signaling systems?  Why duplicate
existing software?
Newsgroups: comp.dcom.cell-relay
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 05:01:11 GMT


In article <peterd.721416994@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes...
>Actually, some of Fred's earlier postings lead me to believe that he
>thinks SSCOP is a good idea *because* of the end-to-end argument. (sorry
>if I'm mis-representing you, Fred...)

You're not!

>The end-to-end argument doesn't say "never re-transmit at the link layer"; 
>it says "retransmit at the link layer for efficiency, not reliability".

>The argument for SSCOP would then be that (1) ATM service will lose
>many cells under congestion, and (2) SSCOP would be more efficient
>than e.g. TCP at retransmission. 

>I'm curious about the second point - I don't see why any protocol above
>the AAL layer (with the same window strategy) would be any better than
>another at dealing with cell loss. 

If you have one hop (end-to-end ATM), then there's no difference.
Both layers (2 and 4) are effectively the same because they have the
same span.

If you have routers, though, then AAL (as a datalink) recovery takes 
place over one  hop, while TCP recovery takes place over multiple hops, 
some of which may be 9600 bps modems, etc.  Efficiency is simply a 
matter of locality -- don't tell the whole path that one hop is lossy.
This helps IF one hop is particularly lossy.  Will ATM be lossy?
That depends!
---
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
From: smq@circinus.bellcore.com (Scott M. Quinn)
Subject: Re: new AAL (SSCOP?)
Organization: Indiana University
Date: Mon, 9 Nov 1992 21:38:59 GMT


> in ANSI, so people must react soon.  in the last ETSI meeting, SSCOP
> didn't get much support and i hope the same will happen in the next
> CCITT meeting.

Juha,

Does this observation apply to just user-user traffic, or does it 
also apply to signalling traffic? 

Thanks
Scott Quinn
-----------------------------------------------------------------------------
Scott Quinn     			MTS - ATM Technology and Applications
Bellcore MRE 2J-278			Tel: +01 201 829 4147	
445 South Street Box 1910		Fax: +01 201 829 5976
Morristown, NJ 07960-1910  USA		smq@aries.bellcore.com
-----------------------------------------------------------------------------
Newsgroups: comp.dcom.cell-relay
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re:  new AAL (SSCOP?)
Organization: Digital Equipment Corp., Littleton MA USA
Date: Sun, 8 Nov 1992 23:11:42 GMT


Well, I'm back from T1S1!

Just in case anyone's wondering, SSCOP (service-specific 
connection-oriented protocol) is the service-specific sublayer that sits 
above AAL3/4 OR  AAL 5 to create a connection-oriented data link 
service.  You can run anything above it that wants local retransmission. 
For example, it will almost certainly be used for signaling (although 
some countries still prefer go-back-N procedures, since signaling is
low speed).  Or if you want "end-to-end ATM", it can be used to deliver 
a transport-like service.

SSCOP is a multiple-selective-recovery protocol.  It can have moby 
windows (say, a 10 Gbps satellite link!) with lots of gaps being filled 
in as well as new data being sent.  The semantics are basically 
"checkpoint selective recovery", though SSCOP is not quite aligned with  
the CSRDLC protocol that the OSI crowd is working on.  Close, though.
Note that SSCOP is NOT finished yet.  We have a few details left to 
attend to.  But the outline is pretty clear.

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?
---
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
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: More Flow Control
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 13 Nov 1992 07:07:56 GMT

myoung@force.ssd.lmsc.lockheed.com writes:
+---------------
| Competition Based Flow Control:
|   If a data source were required to compete for and reserve available 
| bandwidth prior release of a bursty source then flow control would be
| well managed in the local environment...
+---------------

Kills your latency. By the time you do all that "reservation" mishmash,
you might as well have just used Leaky-Bucket into a constant-rate pipe...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: myoung@force.ssd.lmsc.lockheed.com
Newsgroups: comp.dcom.cell-relay
Subject: More Flow Control
Date: 12 Nov 92 22:22:20 GMT
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California

Competition Based Flow Control:

  If a data source were required to compete for and reserve available 
bandwidth prior release of a bursty source then flow control would be
well managed in the local environment.  When the local net includes
only short links with network diameter of only a few nodes, then a
competition based bandwidth reservation process can be quite rapid and 
efficient, operating like the distributed database update.  

  For simplicity assume that all connections are previously established.
A source wishing to burst some batch of data into a path would precede the 
burst with a burst request, moving up the intended circuit.  At each link, 
the total amount of burst bandwidth reserved would be checked, and if enough 
is available the requirement would be allocated and the burst request would 
travel to the next link in the chain.  If not enough burst is available the 
request would back off. If the request arrived at the destination, having 
reserved sufficient bandwidth, then a release data message would be sent 
directly to the source host, the data released, then a release bandwidth 
message passed back up to remove the reservations.

  In order to eliminate oscillations in reservation and usage, reserved
bandwidth would be automatically released after a very short time period
(though still usable by the reserver).  This way, a forward moving burst 
request will pass through while a previously allocated burst is just moving 
into the system.  

  The buffers and switches do nothing as the entire reservation system
is an out of band process.

  Combine this with the wave based source routing, the entire path building 
and burst request functions could be combined into a single wave formula.
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: More Flow Control
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 13 Nov 92 15:34:59 GMT

In article <sa3b6g8@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>myoung@force.ssd.lmsc.lockheed.com writes:
>+---------------
>| Competition Based Flow Control:
>|   If a data source were required to compete for and reserve available 
>| bandwidth prior release of a bursty source then flow control would be
>| well managed in the local environment...
>+---------------
>
>Kills your latency. By the time you do all that "reservation" mishmash,

  Probably can be done in 10 milliseconds or so, using either a central
bidding platform over network diameter of five nodes in local environment.

>you might as well have just used Leaky-Bucket into a constant-rate pipe...

Yes, but the leaky bucket also kills latency, since the source cannot really 
burst at the rate it wants to support.  So now the workstation must provide
buffering outside the control of the local context to smooth its data rate 
or else occupy the desktop operating system doing it in software.

With a bandwidth reservation process, the workstation issues a bandwidth 
reservation request, goes to sleep, then wakes up when the bandwidth is 
reserved, subsequently bursting at the reserved rate, up to the maximum 
link speed.  The cost to implement bandwidth reservation in the network 
is software.

Look at the applications like massive file transfer, disk back up, where
latency is not an issue, and the cost of supporting leaky bucket buffering
at the desktop is prohibitive.  This method is not proposed to support
existing LAN applications.
From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
Newsgroups: comp.dcom.cell-relay
Subject: Covert Signalling in ATM Networks
Date: 5 Nov 92 12:42:24 GMT


a classic form ovf covert signalling is emptiomised by the urban
folklore concerning the football (soccer) fan who emigrated
to australia, and had her relatives telephone the results daily, by a
sequence of phone calls at a pre-arranged time, which she would
not pick up, rather they would ring off after the count reached the
score...

the possibilities for this ina variabl;e bandwidth pre-arranged
signalling VCI are endless, but the following scenario seemed more
likely:

say two parties wish to communicate through an atm net - they both
open an account, and take it in turn to withdraw and deposit
amounts of money, while the other party gets a statment - the balnace
i nbthe acccount ould be a the goedelized number representing the
morse value for the ascii text they wish to communicate (mime users
would have to use uuencode first)...

the defense the ATM swift-one consortium might employ would be to
randomise the interest chareged and awarded daily, to make the number
vary (albeit close to the original product of powers of primes, and
therefore guessable, but tricky, needing at least all the computing
resources of the cia).

of course , some messages would have goedel number representations
that would exhaust the imagination or gambling capabilities even of
the chancellor of the rmajesty's government

just a thought
jon
-------------
p.s. i know its the wrong kind of atm:-)
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re: Big Cell App
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Thu, 5 Nov 92 16:20:41 GMT

In article <9231017.24378@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:

>As an aside - I've seen many invented scenarios and questions posed
>by you ( Matt) in this newsgroup over the last few months. Could you 
>summaries your own answers to your questions, or the answers others 
>have given?
>
>gja

  Boy you got me there! Most all of the responses have been posted and I 
have not extracted them and organized them, sorry.

  The ones who responded via personal mail had the following comments:

1) Possibly some other high speed network standard might emerge which 
involves high speed switching of variable length frames in some fashion.
(Two Responses)

2) That we might see an adaption of XTP (Express Transfer Protocol)
for cell relay networks.  A version of XTP is being used for Startlight
video networks.
(One Response, InterOp Intelligence)

3) Lot of folks wanted more info about wave potocols, but no firm
desire to formalize a wave standard.  Groups interested should indicate
a desire to move forward, possible via more pubic chat group.
(About ten responses including earlier efforts)

4) Lot of requests for information about the deflection switching
research done here at Lockheed, mainly from other research groups.
The research group will send me a paper on a re-sequencing idea
to make it compatible with ATM.
(About six responses)

5) Some great ideas for low cost adaptation architectures,  nothing
in detail.
(One response)
Newsgroups: comp.dcom.cell-relay
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: new AAL (SSCOP?)
Organization: Naval Research Laboratory, DC
Distribution: usa
Date: Tue, 10 Nov 1992 21:59:15 GMT

In article <JH.92Nov10202227@etana.funet.fi> jh@etana.funet.fi (Juha Heinanen) writes:

%   For example, if someone wants to implement X.25 over ATM, a better
% choise is to map LAP B (or whatever the link layer standard for X.25
% is) right over ALL5 rather than trying to do X.25 over a new thing
% (i.e. SSCOP).

Hear ! Hear !  I just can't see the value in SSCOP for anything other
than signalling.  Whether it is needed for all signalling is not clear
to me.  If one is using ISO TP0/CONS or X.25 or TCP/IP, the thing to
do is to run the appropriate transport over the appropriate network
services directly over AAL5.  Paying the costs of error recovery more
than once per protocol stack is not wise and not necessary.  For
example, there is every reason to believe that the Van Jacobson TCP
will be just fine over IP over AAL5 over ATM.

Ran
atkinson@itd.nrl.navy.mil

Newsgroups: comp.dcom.cell-relay