HDTenEightyP/NetNews huggingface dataset:
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Reverse Multiplexing
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 13 Nov 92 15:36:48 GMT

Reverse Multiplexing:

OK, I will attempt to define a reverse multiplexing procedure for
cell relay.


Reverse multiplexing over cell relay should be able to distribute a cell
stream over disjoint parallel paths toward a common destination, where
the cell stream is re-ordered and delivered to the desktop.  The 
algorithm for finding the total common flow over parallel paths to
a common point has two phases; 1) Find the parallel paths going in
the forward direction, and 2) Augmenting these paths with local flows 
which go operate in the backward direction but contribute to the overall
flow. (See any text on graph theory).  To simplify the discussion let
us consider only the parallel, forward flows.

Place some embedded reverse multiplexing processors at common regions
of the wide area network, and connect these with some set of virtual
paths used for out of band communication.  Any of the distributed
processes can find a set of parallel flows to any other using a wave
which operates similar to the wave based source routing, but splits
in parallel at each node during the search process, and collects all
parallel routes, returning them in the wave syntax for further operation.

The reverse multiplexors then present these parallel paths as a single
path to some higher order process.  Any desktop, (or another protocol 
specific router) can find virtual paths using the reverse multiplexors. 

Upon usage, the reverse multiplexors using their pre computed paths would 
reserve bandwidth on each of the parallel routes, using the same bandwidth 
reservation process mentioned in a previous post.  Simultaneously, the 
virtual path tables would be updated, (unless the paths are permanently 
connected).

Over the out of band control net, the multiplexors would exchange an 
ordering table which lets the receiver re-order the cells incoming over
multiple paths, then forward the cell stream to the final destination.
This re-ordering table would be exchanged after the bandwidth reservation
process since some off the pre-computed paths may not have available
bandwidth and would be left out of the current message exchange.

The entire process operates at the cell level, never assembling the
message to look at the network layer as an embedded router would do.

Key components:

  * Use of an embedded processor.
  * Out of band control system.
  * Use of wave to implement distributed protocol and gain access to
    path tables.
  * Re-use of the serial path and bandwidth control schemes in a parallel
    algorithm.
  * Helps the cell relay to expand into sub-T1 market.
Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re:  new AAL (SSCOP?)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 11 Nov 1992 03:46:15 GMT

goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
+---------------
| SSCOP is a multiple-selective-recovery protocol... with lots of gaps
| being filled in as well as new data being sent.
+---------------

Could you say a little bit more about how it compares with other
selective-ACK protocols such as XTP, VMTP, NETBLT, or RFC 1072 TCP?

+---------------
| 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.
+---------------

XTP & VMTP allow multiple "spans" (XTP's term) of ACKs/retranmissions...


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re:  new AAL (SSCOP?)
Organization: Naval Research Laboratory, DC
Date: Mon, 9 Nov 1992 00:34:03 GMT

In article <1992Nov8.231642.7509@nntpd.lkg.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:

[ other stuff deleted ]
%   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.  

  This is a strong statement.  It is not at all clear to me that a Van
Jacobson TCP will not be sufficiently effective.  I'd be much obliged
if you'd explain why you believe there is a problem with handling
things with TCP/IP/AAL5 without the other mechanism you mention.

Ran
atkinson@itd.nrl.navy.mil
Newsgroups: comp.dcom.cell-relay
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: Re: theoretical support for hop-by-hop, not!
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Thu, 12 Nov 1992 12:29:27 GMT

In article <s8thcrg@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock)  
writes:

> craig@sics.se (Craig Partridge) writes:
> +---------------
> | <cell@mythos.ucs.indiana.edu> writes:
> | > that, in a network with a high bandwidth-delay product, TCP exhibits
> | > very large oscillations in end-to-end delay, and takes about 100
> | > round trip times (losing about 190 packets) before a link becomes
> | > fully utilized...
> |  
> |     I'd just like to note that the jury is still out on these results.
> | In general, the literature (both theory, simulation and practice)  
shows 
> | end-to-end flow control outperforming hop-by-hop.  And I've heard  
folks
> | question whether the representation of TCP-IP in the model was  
accurate.
> +---------------
> 
> The oscillation is real, and quite large; I have seen it during FTPs  
with
> "hash" turned on. But also note that Jon Crowcroft (et al?) published a  
paper
> some time ago which proposed a simple change to TCP slow-start that  
smooths
> out most of the oscillation. I wouldn't count TCP (or end-to-end  
congestion
> control) out yet...
> 
> 
> -Rob
> 
> -----
> Rob Warnock, MS-9U/510		rpw3@sgi.com
> Silicon Graphics, Inc.		(415)390-1673
> 2011 N. Shoreline Blvd.
> Mountain View, CA  94043

I just want to clarify that my intent was not to dismiss
end-to-end congestion control.  Rather, it was to point
out one weakness with CURRENT implementations of TCP (and 
by that I mean mainstream commercially available implementations,
not experimental ones).  If TCP can be modified so that this
and other weaknesses are fixed, great.

--
Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Research & Planning      voice: (812)855-7171
Indiana University               FAX:   (812)855-8299
From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
Newsgroups: comp.dcom.cell-relay
Subject: Where can I find documentation on the AALs?
Date: 5 Nov 92 23:09:12 GMT
Organization: Lawrence Livermore National Laboratory

Can anyone give me pointers to where I can find the AAL specifications?  I
did look at the FAQ and checked a couple of ftp sites.  That turned up
the SEAL (AAL 5) proposal, although it is dated sometime last year.  Has it
changed since then?  

While sitting in on Craig Partridge's tutorial at Interop last week, it was
mentioned (by Craig I think) that AALs 2 and 3 have been merged.  Is the
new spec available electronically?  Are the original specs available?

Any help is, as always, greatly appreciated.

regards,
mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Source Routing
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 11 Nov 92 22:40:29 GMT

A Virtual Path Source Routing Procedure:

Expanding on the idea of path building for applications which
want to open a path within microseconds, send a burst of data,
then close the path, a protocol could be developed which requires
some pre-discovery of routes (like source routing) then re-use
this route map each time a circuit is opened.

Using wave, (of course), a desktop can perform route discovery by 
launching an exploratory wave which uses a user selectable costing
mechanism to find one main and possible alternate routes to commonly 
used destinations.  The discovered routes would be collected in wave
syntax, allowing the encoded routes to be released in their exact
form for fast circuit building (again using wave syntax).

Just prior to transmission, a circuit blazer wave would precede the
data, opening up the path tables to the destination, then closing the
tables when data transmission is complete.  The encoded route would
be used repeatedly for more of the same.

In this application, the address resolution protocol (ARP) does not 
result in a completed path, just in an encoded route.
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: My VOte
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 11 Nov 92 15:36:58 GMT


  Having looked at all the postings on SSCOP my opinion says
that SSCOP would be useful to adapt those protocols which 
previously needed a reliable data link layer.  On this basis
I say lets include it in our bag of ptotocols.

In other business:

  However, there is one contradiction in our aims related to 
signalling.

  The cell relay industry intends to win the battle of the hub,
yet, we propose that the major computer and network vendors allow 
us to insert a call control protocol between their lifeblood 
protocols and the hub.  

  How many computer vendors have signed up to allow this?
Newsgroups: comp.dcom.cell-relay
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: Re: flow control, TCP, and ATM
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Thu, 12 Nov 1992 20:52:45 GMT

In article <BxM10o.2Fn@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall  
Atkinson) writes:
> In article <BxLs14.Gu@usenet.ucs.indiana.edu>  
robelr@mythos.ucs.indiana.edu writes:

> are other commercial vendors with this.  The Van Jacobson TCP is not
> nearly as experimental these days as your note implies.  In fact it is
> out as a standards track RFC already and is mostly past experimentation.
> 

Yes, I've read 1323 and believe that its a "real" RFC at this
point but 1323 doesn't deal with selective ACKs, right?
How important do you or others feel this issue will be in
multihop high bandwidth*delay networks?  If its important, 
is there ongoing standards work dealing with this and when 
might we see this resolved?

thanks,

allen
Newsgroups: comp.dcom.cell-relay
From: robelr@bronze.ucs.indiana.edu (Allen Robel)
Subject: Re: EIA/TIA-568
Organization: Indiana University
Date: Sun, 8 Nov 1992 02:53:29 GMT

In <Bx9Jnn.4L3@usenet.ucs.indiana.edu> I write:

>Does anyone know how much consideration the ATM Forum
>has given to the EIA/TIA-598 premises wiring standard?  Or

Opps, that should have been EIA/TIA-568...

-allen
-- 
Allen Robel                         robelr@mythos.ucs.indiana.edu 
University Computing Services       ROBELR@IUJADE.BITNET 
Network Research & Planning         voice: (812)855-7171
Indiana University                  FAX:   (812)855-8299
Newsgroups: comp.dcom.cell-relay
From: myoung@force.ssd.lmsc.lockheed.com
Subject: Re:  new AAL (SSCOP?)
Reply-To: myoung@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Mon, 9 Nov 92 13:58:28 GMT

In article <1992Nov8.231642.7509@nntpd.lkg.dec.com>, goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
>
>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.

  There are lots of connection oriented protocols.  What makes this one
so special.  If its value added is a rate oriented flow control, then
why not fix TCP, or use VTMP or XTP or any of a number of other
proposals.  What makes SSCOP the preferred protocol?
Newsgroups: comp.dcom.cell-relay
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: SSCOP better than TCP?
Organization: Motorola Codex, Canton, Massachusetts
Date: Tue, 10 Nov 1992 17:36:34 GMT

craig@sics.se (Craig Partridge) writes:

>goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:

>> 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.
>> ...
>> Or if you want "end-to-end ATM", it can be used to deliver
>> a transport-like service.
> 
>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.

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...)

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. 

				Peter Desnoyers
-- 
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: clarifying the role of SSCOP?
Organization: Swedish Institute of Computer Science, Kista
Date: Wed, 11 Nov 1992 18:59:30 GMT

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 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).
 
    But I understand that there are folks outside data comm who like
to think of the network as providing a reliable service, and hey, if they
want the pain, that's their business.

Craig
craig@bbn.com

PS: If it helps understand where I'm coming from.  A few years ago a number
of "expert reports" were published saying that high-speed networks and new
technologies would force us to completely rethink data networking.  I thought
those statements were silly -- the likelihood that the tried and true
principles of data networking would all get thrown out the window seemed
small.  So I've stuck to philosophy that what we have learned from experience
is right, until someone proves it wrong.  So I stick to using the end-to-end
argument (which is not TCP/IP specific and was formulated after TCP/IP was
developed), the principle that end-to-end error recovery is best, etc.
Newsgroups: comp.dcom.cell-relay
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: EIA/TIA-568
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Thu, 5 Nov 1992 21:57:23 GMT

Hi,

Does anyone know how much consideration the ATM Forum
has given to the EIA/TIA-598 premises wiring standard?  Or
if ATM Forum members are also contributing to this
standard?  The concerns that I have are 1) the termination
connector for category 5 wire and how that relates to the 
connector that the ATM Forum (or CCITT?) might be considering
for ATM over TP, and 2) the distance that the EIA/TIA-598 spec
gives as the maximum distance between the wire center and 
a given end node (90 meters from closet to outlet and 3
meters from outlet to endnode).  Is this a realistic distance
(it sounds so to me but I just want someone more in tune with
this stuff to verify.)

Many thanks!

--
Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Research & Planning      voice: (812)855-7171
Indiana University               FAX:   (812)855-8299
Newsgroups: comp.dcom.cell-relay
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: Re: Low speed ATM
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Mon, 9 Nov 1992 14:12:32 GMT

In article <1992Nov8.232339.7852@nntpd.lkg.dec.com>  
goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
> 
> Isn't T3 (44.736 Mbps) in your range?   That's now an ANSI draft
> standard, awaiting only final T1 ratification if that.  It currently 
> uses 802.6's rather baroque STS-like framing, but at least there are 
> chips for it.
> 

My understanding is that the 45Mb/s interface option that the
ATM Forum has selected is intended as an interface with 
service providers and not as a LAN interface.  Is this
not the case?

thanks,

--
Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Research & Planning      voice: (812)855-7171
Indiana University               FAX:   (812)855-8299
Newsgroups: comp.dcom.cell-relay,comp.protocols.tcp-ip
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: flow control, TCP, and ATM
Followup-To: comp.dcom.cell-relay
Organization: Naval Research Laboratory, DC
Date: Thu, 12 Nov 1992 15:43:36 GMT

In article <BxLs14.Gu@usenet.ucs.indiana.edu> robelr@mythos.ucs.indiana.edu writes:

>I just want to clarify that my intent was not to dismiss
>end-to-end congestion control.  Rather, it was to point
>out one weakness with CURRENT implementations of TCP (and 
>by that I mean mainstream commercially available implementations,
>not experimental ones).  If TCP can be modified so that this
>and other weaknesses are fixed, great.

Allen,

  The good vendors already ship a Van Jacobson TCP with their standard
product.  I believe that SGI is one example of such a vendor.  There
are other commercial vendors with this.  The Van Jacobson TCP is not
nearly as experimental these days as your note implies.  In fact it is
out as a standards track RFC already and is mostly past experimentation.

  As Rob Warnock pointed out, Jon Crowcroft had an article last
January or so (probably in CCR, maybe in IEEE Networks) proposing a
way to smooth the TCP oscillation.  That proposal is still
experimental though the article sounded very well thought out and
solidly worked to me.  Oscillation of TCP is not a big factor over ATM
as near as I can tell at the moment.

Ran
atkinson@itd.nrl.navy.mil
From: siemsen@barnard.usc.edu (Pete Siemsen)
Newsgroups: comp.dcom.cell-relay
Subject: Reference on ATM?
Date: 10 Nov 1992 09:44:20 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: barnard.usc.edu

Can someone recommend a good reference on ATM?  I'm looking for an
introductory text.
-- 
Pete Siemsen                         Pete Siemsen            siemsen@usc.edu
University of Southern California    645 Ohio Ave. #302      (213) 740-7391 (w)
1020 West Jefferson Blvd.            Long Beach, CA 90814    (213) 433-3059 (h)
Los Angeles, CA 90089-0251
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: theoretical support for hop-by-hop, not!
Organization: Swedish Institute of Computer Science, Kista
Date: Tue, 10 Nov 1992 18:49:46 GMT

"Allen Robel" <cell@mythos.ucs.indiana.edu> writes:

> they compared
> their hop by hop (HBH) scheme of flow control to TCP as implemented in
> 4.3-Tahoe BSD (they also compare HBH with the modified window adjustment
> in the 4.3 BSD Reno version of TCP).  Their results seem to indicate
> that, in a network with a high bandwidth-delay product, TCP exhibits
> very large oscillations in end-to-end delay, and takes about 100
> round trip times (losing about 190 packets) before a link becomes
> fully utilized.  In contrast, HBH loses NO packets and  maintains
> a very even end-to-end delay variance.  Note that I'm not condoning
> their scheme.  I'm just saying that there are schemes out there that
> do better in the area of flow control than current implementations of
> TCP in high speed networks.
 
    I'd just like to note that the jury is still out on these results.
In general, the literature (both theory, simulation and practice) shows 
end-to-end flow control outperforming hop-by-hop.  And I've heard folks
question whether the representation of TCP-IP in the model was accurate.
Certainly, given the weight of results one way, it is not clear that one
dissenting paper should be sufficient to lead us.
 
Craig

Newsgroups: comp.dcom.cell-relay
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: The Low Cost Backbone
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 13 Nov 1992 05:05:44 GMT

nagle@netcom.com (John Nagle) writes:
+---------------
| myoung@force.ssd.lmsc.lockheed.com writes:
| >More on the Lockheed switch, making it ATM comaptible:
| 
| >The probability of buffer overflow is replaced by the probability that
| >an out of sequence cell is still circulating in the backbone when
| >its neighbors are forwarded to the access node.
| 
|        Cute.  The transmission medium (fibre, etc.) IS the buffer.
| It's like a railroad with no yards, just switches, and the trains
| never stop until they reach their final destination.
| 
|        If nodes are too close together, does this create problems?
+---------------

No, because I think (based on a conversation with the Lockheed developer)
you have a small but critical misunderstanding.

The transmission medium is *not* the buffer, the host interfaces are! If no
other outgoing trunk ports are free, the switch will route a cell back *into*
any free host interface, where such misrouted cells then take priority over
new traffic for transmission back out into the network fabric. Some thought
will show that this is sufficient to keep from dropping any cells due to
congestion.

(There *is* a one cell buffer at the input to each switch port, but only to
allow for non-synchrony of inputs due to links not all being the same length.)


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.cell-relay
From: goldstein@carafe.enet.dec.com (Fred R. Goldstein)
Subject: Re: Low speed ATM
Organization: Digital Equipment Corp., Littleton MA USA
Date: Sun, 8 Nov 1992 23:20:39 GMT


In article <BwwDq1.60I@usenet.ucs.indiana.edu>, robelr@ucs.indiana.edu (Allen Robel) writes...
>Why isn't the ATM
>Forum defining a low-speed (20-45Mb/s raw ATM with no STS
>framing) interface for local ATM?  

Isn't T3 (44.736 Mbps) in your range?   That's now an ANSI draft
standard, awaiting only final T1 ratification if that.  It currently 
uses 802.6's rather baroque STS-like framing, but at least there are 
chips for it.

The CCITT is defining a set of convergences for ATM over pretty much 
everything they know.  These are based on the simpler hunt-for-header CRC 
method of framing.  This may become an alternative standard for T3, E3
(34 Mbps), and even T2 and T1.  Of course, ATM over T1 is rather 
controversial.

The nice thing about standards is that there are so many to choose 
from.
---
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