HDTenEightyP/NetNews huggingface dataset:
From: newman@adapt (Peter Newman)
Subject: Re: Out of order messages
Organization: ADAPTIVE Corporation
Date: Fri, 28 Aug 1992 21:39:56 GMT

In article <BtnuCy.56s@usenet.ucs.indiana.edu> robelr@mythos.ucs.indiana.edu writes:
>
>To the ebest of my knowledge this is not possible.  ATM switches
>will not misorder cells and, in traversing multiple switches, 
>you will follow one and only one route thru them.
>
>--
>Allen Robel                      robelr@mythos.ucs.indiana.edu

The ATM standards state that cells on a virtual channel will be
delivered in the order in which they were sent.
Some designs of ATM switch can misorder cells.
So if you have designed an ATM switch that is subject to misordering
cells within a virtual channel you had better design a piece of
silicon that restores the order and locate one on each output port of
the switch.

-- Pete N.
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: Re: Future of IP routers
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Thu, 27 Aug 1992 14:35:14 GMT

In article <1992Aug27.081252.11349@ccsun.strath.ac.uk>  
craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
> The addressing issues for ATM still haven't been resolved yet 
> but I imagine it will be possible to address an individual service and  
hence 
> enforce policy restrictions.
> 

OK, I can see how this would work.  But, how do you (or others)
see segmenting the address space to reflect various service
offerings (e.g. 900 calls, 800 calls in todays phone system).
If services are not somehow reflected in addresses, and at
a much higher granularity than that in the example I gave above,
we will be faced with having to either build very large
filters to accomodate every possible connection an end-user
might want to make, or build smaller, more restrictive, filters 
which say, in effect, "Allow connections to X, Y, Z but deny 
everything else."  Much more useful would be the ability to
wildcard parts of the address that represented specific service
offerings (i.e. 1???1112222 might mean all interactive video services).
This somehow seems unrealistic though. Someone please straighten me 
out if I'm missing  something...

--
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: bantha.decnet.lockheed.com!young
Subject: Today's Problem
Reply-To: young@bantha.decnet.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Fri, 4 Sep 92 13:14:47 GMT


Far into the future (mid 1993) server nomenclature is fading from
our language, being replaced by server "waves" which migrate about
the virtual path networks (enabled by wave interpreters at each node).

The backup server, for instance, migrates in turn to each desktop, 
activates a local daemon to check for any files which need backup.  
Upon finding one or more, the backup wave then explores the local 
region for desktops with extra disk capacity.  It then moves the files 
to a neighbor node, and moves on to the next desktop.

Question:
1) How can we be sure that the backup wave touches every desktop in
the enterprise?

2) What two things to we need in the wave interpreters to insure that
a break in the network does not leave a wave protocol in an unstable 
state?

Extra Credit:

3) Since the wave has no home, what constitutes its center? How do we
define its current active region?

4) How many vci/vpi pairs does the wave use? Can all server waves use the
same vci/vpi set?
Matt Young
Lockheed
(408) 756-6789
Newsgroups: comp.dcom.cell-relay
From: craig@sics.se (Craig Partridge)
Subject: >>>>Future of IP routers
Organization: Swedish Institute of Computer Science, Kista
Date: Fri, 28 Aug 1992 16:40:08 GMT

I'm seeing a recurrent thread of silly comments about what IP can and
cannot do, often based on dubious benchmarks.
 
Based on the best benchmarks I know, here's the state of the world.

    * Cray has documented (with careful testing) a TCP that runs
    at between 710 and 790 Mbits/s over an 800 Mbit/s HiPPI channel.
    (The difference is a matter of how you do the HiPPI signalling).
    My understanding is that this is the TCP/IP software that Cray
    sells (not some monkeyed version with the wind at its back).
 
    * The high-end routers passing IP without options can drive
    multiple FDDI interfaces full tilt (I believe the interface was
    looped such that TTRT doesn't matter).  See the Harvard Router
    tests.
 
Based on the trends (of which these results are simply the leading edge),
there's every reason to believe that TCP can operate happily at gigabit
speeds and that IP routers will happily forward IP datagrams at gigabit
speeds sometime in the future.  That's probably true of CLNP and TP4
too.
 
Kindly note that most benchmarks are extremely poor, and fail to distinguish
between the performance of TCP/IP and the performance of interface boards
(remember what Jacobson learned about Ethernet chips -- one ran at 10 Mbit/s
while the other maxed out at 6 Mbit/s -- test on the wrong chip and you'd
get the wrong value for TCP performance), local configuration issues
(any FDDI throughput test over a real ring that doesn't mention the TTRT
that the testers set for the network is worthless), and features of the subnet
technology (for example, the Cray folks believe that one should release
the HiPPI channel after each packet to allow sharing -- that takes about
10% off their performance).  Instead, someone just runs TCP over the media
and says "here's what it can do."  If I ran an ATM performance test in which
the receiver was intererupted for every cell and did the SAR layer
in software, would anyone accept that as the definitive answer as to the
maximum performance of ATM (over, say, OC-3)?

Now whether you want to use IP for gigabit networks, and whether IP can
support mixed-media traffic as well as other technologies like ATM is
still an open question.  (I happen to think that IP could work just fine
thank-you but that's my opinion).  But there's no need to make poorly
documented comments about the performance of IP to justify ATM.

Craig
Newsgroups: comp.dcom.cell-relay
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: Re: Future of IP routers
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Wed, 26 Aug 1992 15:33:53 GMT

In article <1992Aug26.095756.5247@ccsun.strath.ac.uk>  
craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
> type. This will remove the requirement to send video/audio traffic via a  
router,
> because the video/audio AAL entities will connect directly with the  
video/audio
> AAL entities at the other end.

Which means that the filtering functionality currently available
in routers gets pushed out to end nodes and is carried out
at call setup?  I'm not sure that I'm comfortable with this
sort of arrangement.  Take a hypothetical situation where,
as a part of organizational policy--possibly for budgetary
reasons--users should be denied access to interactive video
communication outside of a given administrative domain but
that other services, some of which might include non-interactive
video/audio retrieval from a subset of information providers, 
should be allowed.  With TCP, we have "well known" port numbers 
that services are offered over and can be used to filter traffic
related to these services.  Thus, "domain level" administration
and security is made possible. If ATM forces the management
of this type of security to individual hosts, I'm not sure
that administrators will adopt seamless LAN/WAN integration.
I see this as something that needs work before a truely
integrated LAN/WAN ATM solution will be acceptable for
many organizations.

--
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: Out of order messages
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Thu, 27 Aug 1992 21:00:33 GMT

In article <21169@optima.cs.arizona.edu> pagels@cs.arizona.edu (Michael A.  
Pagels) writes:
> This is a simple question, but I can't seem to track down
> a definitive answer:  Is it possible for ATM cells when
> providing a connection based service to become out of order
> after traversing multiple switches?  Some specifications

To the ebest of my knowledge this is not possible.  ATM switches
will not misorder cells and, in traversing multiple switches, 
you will follow one and only one route thru them.

--
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: johng@informix.com (John Galloway)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Another Problem
Date: 1 Sep 92 21:23:44 GMT
Organization: Galloway Research

In article <1992Aug31.160529.8597@iscnvx.lmsc.lockheed.com> young@bantha.decnet.lockheed.com writes:
>In article <p8bpe4o@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>In article <1992Aug30.164226.2031@iscnvx.lmsc.lockheed.com>, bantha.decnet.lockheed.com!young writes:
>>> This newsgroup continues to debate the interface between TCP/IP routers
>>> and ATM. Must be an important application.
>>> 
>>> Now here is another problem which ATM might solve.
>>> 
>>> Imagine that an account executive wants to read into his spread sheet the
>>> entire daily summary of mail orders spread over a number of distributed
>>> offices.  Thus, he wants to extract a particular file located in each of
>>> a large set of desktop machines.  
>>> 
>>
>>Are you sure that ATM is an obvious part of a solution to this kind of
>>problem?
>>
>>Doesn't this sound more like an application for a multicast based
>>"distributed" application?  Perhaps some kind of multicast remote
>>procedure call?  Using UDP/IP multicast?
>>
>>Vernon Schryver,  vjs@sgi.com
>Yes, Yes the solution needs some kind of exploratory, application specific,
>protocol which can search out and find, then bind those desktops in
>a spanning tree, and then have the capacity to extract file data from
>each node, all in a parallel fashion.

"extracting a particular file located in each of a large set of desktop
machines" is a very naive view of a distributed database, which is what
you are describing in this example.  In such a case ensuring the consistency
and accuracy of the database (i.e. dealing with net link going down, or
a system going down, or a disk failing, or a local users screwing up, and
with concurnet updates and multiple copies of the data, and ....)
will far outweigh (by an order of magnitude at least, if not several) the
network overhead even in current ether-LAN's, let alone in various
"networks of the future".

So in this example, the system looking for this distribued file or data
is very likely not just beginning to do so when the request is made, but
has already been set up as part of the distributed db system.  Indeed
if some stations are reached via ATM and are not in contact at this poiont,
then calls will have to be placed.  But again, I would suspect that the
time spent on each system findings its piece of the data, and the time spent
on the requesting node assembling it all, will dwarf the network overhead
on any of the nets being discussed here.  or so it seems to me.
	-jrg
-- 
internet    jrg@galloway.sj.ca.us  John R. Galloway, Jr  795 Beaver Creek Way
applelink   D3413                  CEO...receptionist    San Jose, CA   95133
                                   Galloway Research     (408) 259-2490
Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Bare Bones Adaptation
Organization: Basket Weavers, Inc.
Date: Thu, 3 Sep 1992 00:46:03 GMT

In article <1992Sep2.222815.9025@infodev.cam.ac.uk> dm@cl.cam.ac.uk (Derek McAuley) writes:
	[..]
>Seriously, is AAL5 *the* bare bones adapt(at)ion layer, or did it
>simply force the CCITT to realise they hadn't solved all the worlds
>future networking problems with AAL1/2/3/4, .... ? (Rhetorical.)

It's imprecise to refer to _any_ of the AALs as *the* AAL,
since each one is considered to be the answer to a different service.
AAL5 is the packet-peoples response when AAL3/4 was considered to be
an inefficient answer to packet-peoples requirements.
AAL1 and 2 are the proposed answers to the question at the start of 
this thread (digitised audio). AAL5 is not aimed at providing a better 
answer to this style of service.

gja
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Future of IP routers
Organization: CERN European Lab for Particle Physics
Date: Thu, 3 Sep 1992 09:18:00 GMT

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

>In article <1992Aug31.133020.10227@dxcern.cern.ch> brian@dxcern.cern.ch (Brian Carpenter   CERN-CN) writes:
>	[...]
>>Then the procedure to establish an IP
>>based session to foo@bar.sna.fu would be
>> - issue DNS request for that address
>> - if reply indicates a specific VCI/VPI pair, use it immediately
>> - if reply indicates an E.164 address/subaddress, invoke Q.93B
>>   to establish VC/VP (unless already open)
>> - else go to non-ATM processing

>I've some concerns with the way you use VCI/VPIs here. They are not
>world-wide unique addresses, and they are not even world-wide unique
>connection identifiers. A given virtual circuit/connection (I'm a
>little uncertain of my terms here :) traversing multiple ATM switches
>and physical fibres from point A to B will probably change VCI at each
>switch, and possibly VPI too (depending on actual implementations
>and how VPIs are mapped to service qualities, if at all, on each
>switch-fibre-switch segment).

Yes, I agree with all you say. The point is that right now
and for the next 12 months all we will have is small networks with
pre-configured VPI/VCI. For private (campus) networks this
approach may survive for a long time. And I'd rather this be supported
by DNS than by kludges in /etc/hosts. In the long term or for large
networks, everything you say below will apply.

    Brian

>For a user connected to an arbitrary local ATM switch it is unlikely
>the DNS will be able to return a VCI/VPI pair having any meaningful
>value. The VCI/VPI which finally carries IP packets into foo@bar.sna.fu
>will be different to the the VCI (and/or VPI) that any given user
>needs to send packets to their local ATM switch on.

>Yes, it may be possible to request fixed VCI/VPI pairs be mapped to
>known endpoints - and by association be mapped to known IP addresses.
>But with only 2^16 VCIs and 2^8 or 2^12 VPIs (depending on your
>perspective) available, fixed mappings are not likely to be supported
>on a large scale when we are competing with all the other telco services
>on B-ISDN.

>Just my observations.

>gja
Newsgroups: comp.dcom.cell-relay
From: bharath@iti.gov.sg (Bharath Narayanan)
Subject: Re: ATM Ref.
Organization: Indiana University
Date: Fri, 4 Sep 1992 10:09:28 GMT
X-Mailer: ELM [version 2.3 PL11]

HI:
Since I heard that you guys at Adaptive are quite an authority in the ATM 
area could you please post me some references to read to start with!
Or is there any ftp site from where I can ger some material ?

ALso do you make any chips?... any other recomendations?

Thanks in advance.
Sincerely
Bharath

bharath@iti.gov.sg

Bharath
Information Technology Institute
71, Science Park Drive
Singapore 0511.
Tel: 65-7720582
Fax: 65-7785966


Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Future of IP routers
Organization: Basket Weavers, Inc.
Date: Wed, 2 Sep 1992 00:33:48 GMT

In article <1992Sep1.141555.8025@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
	[..]
>As you've indicated, a VCI/VPI pair is only meaningful between host and
>first switch. At the switch it's translated into a different VCI/VPI. 
>
>Assuming the 
>first switch is a local area switch i.e. under control of the local network
>manager, any permanent virtual circuits can have VCI/VPI pairs stored in 
>the DNS.

A subsequent post by yourself seems to be heading in the right direction,
but I thought I'd put my response in anyway..

A major problem is having the DNS collect, collate, and disseminate
such fundamental low-level information about underlying ATM links and
active virtual circuits. Any given DNS would have an impossible task to
keep track of all the possible VCI/VPI values any given host in the world
might need to use to get to any given other host.

	[..]
>This means a
>particular VCI/VPI pair only has local significance between two ATM entities
>and so I don't see where the problem with only a limited number of 
>VCI/VPI identifiers occurs.

Either the DNS knows the correct VCI/VPI to recommend to any enquiring
host wishing to inject cells at any switch in the ATM world (which means 
an impressive DNS database), or the nailed-up virtual circuit uses the
same VCI/VPI across all switches and links (so as to reduce the number
of possible values stored in the DNS). The first case is unthinkable, and
the second means most, if not all, switches will have to wastefully
preallocate a VCI/VPI to an IP destination "just in case" someone wants
to send to that IP address from that switch. This may be an option on
small ATM LAN-ish setups, but not for telco switches serving other
users (phones, video, etc) as well.

Basically I think the IP over ATM DNS should stick to returning E.164
(or some equivalent host ATM interface identifier) and leave it to the
underlying ATM signalling system to establish (or reuse) a virtual
circuit between the querying IP host and its desired IP destination.

gja - waving arms vaguely in the air to add authority :-)
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Bare Bones Adaptation
Date: 4 Sep 92 00:29:59 GMT
Organization: Basket Weavers, Inc.

In article <1992Sep3.145126.29419@iscnvx.lmsc.lockheed.com> young@bantha.decnet.lockheed.com writes:
>In article <9224710.1007@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:
	[..some stuff..]

>I can understand that the CCITT standards groups will define some AAL
>layers to help get the market moving, but technically, what is it inside
>of the ATM network which requires knowledge of the users particular 
>AAL usage?
	[..]
>Otherwise the network need not define, impose, control, or 
>otherwise interfere with the process of defining adaption layer message 
>formats. What am I missing?

Errr...since you replied to my article I'll take a bite and say
"I don't know". But your question is similar to asking "what is it
about Ethernet that needs to know about the next protocol layer up?",
and the answer is "nothing, really". True, AALs all operate over the
same sorts of cell based virtual connections - "the network".

However in many peoples eyes "the network" starts at the top of their
AALs, providing the services required. So since CCITT B-ISDN is all
about providing a variety of services, Study Group XVIII have been
defining AALs as well as the underlying ATM structure.

I'm still not sure you're actually missing anything :-)

gja
From: cliff@garnet.berkeley.edu (Cliff Frost)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 1 Sep 1992 16:07:04 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: garnet.berkeley.edu

In article <1992Sep1.141555.8025@ccsun.strath.ac.uk>, craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
|> In article <9224510.20448@mulga.cs.mu.OZ.AU>, gja@mullian.ee.mu.oz.au (Grenville Armitage) writes:
|> 
|> |> 
|> |> For a user connected to an arbitrary local ATM switch it is unlikely
|> |> the DNS will be able to return a VCI/VPI pair having any meaningful
|> |> value. The VCI/VPI which finally carries IP packets into foo@bar.sna.fu
|> |> will be different to the the VCI (and/or VPI) that any given user
|> |> needs to send packets to their local ATM switch on.
|> |> 
|> As you've indicated, a VCI/VPI pair is only meaningful between host and
|> first switch. At the switch it's translated into a different VCI/VPI. 
|> 
|> Assuming the 
|> first switch is a local area switch i.e. under control of the local network
|> manager, any permanent virtual circuits can have VCI/VPI pairs stored in 
|> the DNS.

I'm new to this stuff and trying to learn, so that may explain why this seems
backwards to me.  

Here's my naive reasoning:  Say I want to do a DNS query to find a
VCI/VPI pair for a remote station.  You seem to be saying that the remote
station's DNS server will tell me about the remote station's VCI/VPI pair,
but that is meaningless to me--I need to know the VCI/VPI local to me, no?

Or are you implying that the DNS will have to have a lot of topological
information stored in it so that it can give different answers depending
on who is doing the query?  That isn't simply a redesign of the DNS, that
would be a completely new service (think about the fact that I can point
my resolver at any DNS in the world and have it work...).

	Cliff Frost
	UC Berkeley
Newsgroups: comp.dcom.cell-relay
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET@mitvma.mit.edu>
Subject: Re: >>>>Future of IP routers
Organization: Indiana University
Date: Mon, 31 Aug 1992 11:32:00 GMT
X-Vms-To: IN%"comp.dcom.cell-relay@ucs.indiana.edu"

On Sun, 30 Aug, V. Schryver (vjs@sgi.com) said, about FDDI, that:

"While the token is rotating, no data is being transmitted."


While I am not ready to enter the debate about the efficiency of IP over
FDDI, the statement above is not totally correct.  A station is allowed to
launch a token immediately after sending a data packet, or so-called "Early
Token Release."  Thus, while the latency of large rings affects you in
other ways, it does not require the large wait for your data to return
before sending off a new token.  It is theoretically possible for several
packets to be on the line even while the token is rotating.

/gary kessler
MAN Technology Corp.
802-879-3375
kumquat@smcvax.bitnet
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
From: john@iastate.edu (John Hascall)
Subject: FDDI ring size, TTRT, hosts, performance
Organization: Iowa State University, Ames, IA
Date: Thu, 3 Sep 1992 02:12:05 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
 ...
}Some of us do not think much of an 8 ms.  For example, an 8 ms TTRT on
}a ring with 1 ms latency limits the maximum possible bandwidth between
}any pair of stations to about 77Mbit/sec.  I think maximum bandwidth
}goes something like (TTRT-latency)/(TTRT+latency) with a correction for
}the frame being transmitted when TRT expires.  A maximum sized ring
}with a 1.67 ms latency and 8 ms TTRT permits only 65 Mbit/sec between
}any pair of stations even when the rest of the ring is completely
}idle.  That is just plain silly!

It seems to me that the important questions to ask are (and, I have
no clue what the answers are):

    * What is the `typical' ring size?
      + Is 1.67ms or even 1ms at all typical?

    * What is the typical number of hosts?
      + Is it typical (or even likely) that only 1 host wants to transmit?

I have only one data point:
    * 4 node ring (4 routers with 1-FDDI + ~10-ethernet ifaces each)
      each ~500meters from its neighbors [~0.01ms???? swag]

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]