|
|
ARCHIVE: TCP-IP Distribution List - Archives (1988)
DOCUMENT: TCP-IP Distribution List for May 1988 (403 messages, 186148 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1988/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 May 88 02:06:56 GMT From: fair@UCBARPA.BERKELEY.EDU (Erik E. Fair) To: comp.protocols.tcp-ip Subject: ARPANET charging schemes and which protocols are affected?
Does anyone have any hard numbers that document which application protocols are used most over ARPANET (i.e. what TCP & UDP port numbers are seen most often)? It'd be nice if these numbers included both numbers of packets, and number of bytes (since FTP packets are likely to be larger than TELNET packets). The last time I saw any numbers for any part of the Internet, numbers of packets were split: SMTP 30%, FTP 30%, TELNET 30%, and OTHER 10% (this is from memory, so don't take the percentages too literally - it was the relationship between them that I was concerned about at the time). Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Sun, 1 May 88 23:38 CDT From: LIVINGSTONE <@vms3.macc.wisc.edu:LIVINGSTONE@BERT.DecNet> To: TCP-IP@SRI-NIC.arpa Subject: Re: New BSD TCP/IP & Mt. Xinu
UNSUBSCRIBE TCPIP
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 May 88 19:24:28 GMT From: bernhold@qtp.ufl.edu (David E. Bernholdt) To: comp.protocols.tcp-ip Subject: Re: Simple Cost Accounting Policy
In article <8804291239.AA21630@jvnca.csc.org> heker@JVNCA.CSC.ORG (Sergio Heker) writes: >Thus I suggest >the fix cost depending on line bandwidth (as I recall Craig Partridge >suggested this before). It seems to me that in the long run this is going to be a problem. If sites are charged based on the bandwidth of their connection to the net, most bean-counters aren't likely to be overly generous with the capacity they are willing to fund. Then nobody is going to have the bandwidth for any more than their own usage & nobody will be willing to sacrifice their much-needed bandwidth to pass somebody else's packets on to another destination. And very quickly the net looses its usefulness. Is my view overly simplistic or too pessimistic (sp?)?? Dave -- David Bernholdt Internet: bernhold@orange.qtp.ufl.edu Quantum Theory Project BITnet: bernhold@ufpine.bitnet University of Florida HEPnet: 43129::59410::bernholdt Gainesville, FL 32611 Phone: 904/392 9306
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 2 May 1988 08:03:38 CDT From: Link@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: LINK@GUNTER-ADAM.ARPA Subject: Networking Classes
I've got a new employee who's never done any networking before. I'm looking for some good classes for her. I'd like the following topics to be covered: the OSI model, the Internet Community, the DOD model, the MIL-STDs, Ethernet (802.3...), Gateway mechanisms, and an emphasis on local networks. Please reply directly; I no longer monitor TCP-IP. Thanks. |====================================================================| | Link Verstegen Network Solutions, Inc. (NSI) | | Lead Hardware Engineer 4350 Will Rogers Parkway, Suite 100 | | Oklahoma City, OK 73064 | | Link@Gunter-Adam.ARPA (405)942-8884 | |====================================================================| -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Mon, 02 May 88 10:57:16 EDT From: Ross Patterson <A024012%RUTVM1.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Re: Another problem with usage charges
>Well -- if you read the spec, FTP itself implements checkpoint/restart.
>Better protocols may be desirable, but for now we should make the most
>of the ones we already have.
>
>Has anyone implemented checkpoint/restart in FTP?
Yup. The UCLA TCP/IP for IBM's MVS system, known as the "ARPANET
Control Program", or ACP, supports FTP checkpoint/restart. The Unixes
we've got around here dont, since they won't accept a "MODE B" command
(Sun's responds "Sorry, only stream mode supported" (or something
close to that)). ACP is the basis for most, if not all, IBM MVS
implementations. It supports restarting of both transmission and
reception, as well as allowing the user control over the interval
between checkpoints (defaulting to 100K bytes).
Are there any other checkpointers out there?
Ross Patterson
Rutgers University
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 2 May 1988 14:30:52 CDT From: AFDDN.BEACH@GUNTER-ADAM.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: AFDDN.BEACH@GUNTER-ADAM.ARPA Subject: EDI (ANSI X12) use in the internet
To any who may know: Can anyone tell me if they're exchanging EDI formatted data across the DoD internet using any of the TCP/Ip protocols? I'm not the least familiar with EDI so if anyone feels like clueing me in, have at it. i do seem to remember something about EDI and TOP being related. Maybe I'm just confused. I'd appreciate any enlightenment anyone can throw my way. Thanks, Darrel Beach -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Mon, 2 May 88 16:31 PDT From: Dale Smith <DSMITH@oregon.uoregon.edu> To: tcp-ip@sri-nic.arpa Subject: potential problems with TTL = 0
What is the current "correct" value to place for the TTL field? Can someone with a Sequent Balance 21000 verify what the initial TTL value is for TCP, UDP, and ICMP packets? The reason for this query is that I am having problems delivering mail to uunet.uu.net which is a Sequent Balance 21000. I have observed TCP packets from uunet.uu.net being dropped by my gateway because the TTL was 0. This seems to only happen for TCP traffic. I can ping uunet and get response of 1-2 seconds. I can use nslookup to query uunet.uu.net using datagram (UPD) mode. However, use of any TCP based service to uunet causes lots of TCP packets from uunet to be dropped at my gateway with TTL = 0. I have captured and looked at the UDP and ICMP packets from uunet and they have different, but adequately large TTL values. The folks at uunet say they are running some beta version of TCP/IP. So, is there anyone out there from Sequent who can verify that this is or is not a known problem? Can someone with a Balance 21000 who is running beta-version TCP software look at what the initial TTL value is? Thanks, Dale Smith, Assistant Director of Network Services Internet: dsmith@oregon.uoregon.edu BITNET: dsmith@oregon.bitnet Voice: (503) 686-4394 USmail: University of Oregon Computing Center Eugene, OR 97403-1212
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 13:03:38 GMT From: Link@GUNTER-ADAM.ARPA To: comp.protocols.tcp-ip Subject: Networking Classes
I've got a new employee who's never done any networking before. I'm looking for some good classes for her. I'd like the following topics to be covered: the OSI model, the Internet Community, the DOD model, the MIL-STDs, Ethernet (802.3...), Gateway mechanisms, and an emphasis on local networks. Please reply directly; I no longer monitor TCP-IP. Thanks. |====================================================================| | Link Verstegen Network Solutions, Inc. (NSI) | | Lead Hardware Engineer 4350 Will Rogers Parkway, Suite 100 | | Oklahoma City, OK 73064 | | Link@Gunter-Adam.ARPA (405)942-8884 | |====================================================================| -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 14:57:16 GMT From: A024012@RUTVM1.BITNET (Ross Patterson) To: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges
>Well -- if you read the spec, FTP itself implements checkpoint/restart.
>Better protocols may be desirable, but for now we should make the most
>of the ones we already have.
>
>Has anyone implemented checkpoint/restart in FTP?
Yup. The UCLA TCP/IP for IBM's MVS system, known as the "ARPANET
Control Program", or ACP, supports FTP checkpoint/restart. The Unixes
we've got around here dont, since they won't accept a "MODE B" command
(Sun's responds "Sorry, only stream mode supported" (or something
close to that)). ACP is the basis for most, if not all, IBM MVS
implementations. It supports restarting of both transmission and
reception, as well as allowing the user control over the interval
between checkpoints (defaulting to 100K bytes).
Are there any other checkpointers out there?
Ross Patterson
Rutgers University
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 17:01:50 GMT From: Robin@turbo.RAY.COM (Robin Alston) To: comp.dcom.lans,comp.unix.wizards,comp.protocols.tcp-ip Subject: can someone recommend a book covering tcp-ip and nfs?
Can some kind soul or souls recommend book, books or papers that talk about tcp-ip on the one hand and nfs on the other. It looks like I am going to be implementing a port of nfs to some of our hardware and we have a source based on the SGI 3000 series workstations (which our whole system is kind of based on). I will be involved initially with the low level talking bits and packets on the ethernet board first but migrating up to nfs soon after that. We also intend to implement a multi-processor unix using nfs but communicating tcp-ip on the normal system bus, any recommended reading here might be useful too. ta v mucho. -- ------------------------------------------------- # Whats worse than two MA drivers on a freeway? # Dr. Robin the REAL # Answer: One Toronto driver # SuperUser Atilla! ------------------------------------------------- (617)-460-8225 Robin@turbo.ray.com .....!rayssd!turbo!Robin
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 May 1988 21:16-EDT From: CERF@A.ISI.EDU To: Link@GUNTER-ADAM.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: Networking Classes
Send her to one of Dan Lynch's tutorial sequences - he just did a good one in Washington, DC. Dan runs Advanced Computing Environments out of Palo Alto, CA (on San Antonion Roa). He can be reached as Lynch@ISI.EDU. Vint Cerf
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 17:57:36 GMT From: map@GAAK.LCS.MIT.EDU (Michael A. Patton) To: comp.protocols.tcp-ip Subject: Many things on ethernet together???
Date: 29 Apr 88 19:38:16 GMT From: rayssd!turbo!Robin@gatech.edu (Robin Alston) Organization: Raytheon Company, Marlborough MA My question is can this really work? Can XNS and TCP-IP share the same coax cable with no possible problems? Can we have our own domain (we really have no interest at this time in talking to our vaxes), while decnet has its own on the same cable? There is no problem at all with this, Ethernet was designed with exactly this type of thing in mind (of course ISO is different, but can be made to coexist with a simple kludge). We have one Ethernet here that carries TCP/IP, XNS and ChaosNet (that I know of, I'm sure there are others that nobody bothers to tell me about) at the same time. In fact the MicroVAX that I use as a workstation runs both TCP/IP and ChaosNet on the same interface without any problem. The designers of Ethernet assumed there would be multiple higher level protocols and provided a field in the Ethernet packet to say which one it carried. Any reasonable Ethernet driver should just calmly ignore (maybe count) any packets with a type field it doesn't recognize. Michael A. Patton Network Manager Lab. for Comp. Sci. Mass. Inst. of Tech. P.S. For those who don't know the kludge for coexistance mentioned in the body, ISO replaces the Ethernet type field with a length field which occupies the same bits. Coincidentally Ethernet types are illegal ISO lengths and vice-versa, this allows the software to tell them apart, you could look at it as assigning ISO a large number of Ethernet type codes, which they then select between to encode the length of the packet.
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 19:02:26 GMT From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together???
You can put a LOT of still on one cable. The limiting factor is the
traffic, not the number of devices (until you reach the addressing
limit). I would not expect to see any trouble, and you can get software
for the VMS machines to enable sending SMTP mail to them.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 19:14:00 GMT From: vjs@rhyolite.SGI.COM (Vernon Schryver) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
In article <218@turbo.RAY.COM>, Robin@turbo.RAY.COM (Robin Alston) writes:
>
> We have a bunch of SGI workstations currently running XNS over ethernet.
> We have just been informed that when we move into a new building at the
> end of May we will have to use a single ethernet cable for the whole
> building which includes many vaxen running VMS many many pc's with some kind
> of future-net link and many pc's with simple vax links.
>
> My question is can this really work?
> Can XNS and TCP-IP share the same coax cable with no possible problems?
> Can we have our own domain (we really have no interest at this time in
> talking to our vaxes), while decnet has its own on the same cable?
We have converted our ever growing network from our XNS to TCP. Two years
ago, we had ~100 workstations, some VAXes, and other stuff, all on one
cable. We used XNS almost exclusively, even on the VAXes. We now have
lots more workstations, more VAXes (VMS, 4.2+XNS+TCP, 4.3+NFS), PC-clones
running TCP, many cables, routers (our own, of course), bridges,
microwaves, an APRANET connection (also, of course, our own box--please
forgive the commercial), using almost exclusively TCP/IP/UDP. The
conversion was continuous; for most percentages n between 1 and 100, we
have had n% TCP and (100-n)% XNS, without trouble.
We also mix DECnet with TCP & XNS on the same cable, using IRIS's & VAXes
to gateway between TCP & DECnet.
We have been blessed with other, educational troubles. For example,
consider what groups of IRIS 4D's running the UDP-broadcast version of
'dog' at >30 frames/sec do to 750's, which think anything more than 20
broadcast packets/sec is a catastrophic storm.
Vernon Schryver
Silicon Graphics
vjs@sgi.com {decwrl,sun,pyramid,research,allegra,ucbvax}!sgi!vjs
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 19:30:52 GMT From: AFDDN.BEACH@GUNTER-ADAM.ARPA To: comp.protocols.tcp-ip Subject: EDI (ANSI X12) use in the internet
To any who may know: Can anyone tell me if they're exchanging EDI formatted data across the DoD internet using any of the TCP/Ip protocols? I'm not the least familiar with EDI so if anyone feels like clueing me in, have at it. i do seem to remember something about EDI and TOP being related. Maybe I'm just confused. I'd appreciate any enlightenment anyone can throw my way. Thanks, Darrel Beach -------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 May 88 23:31:00 GMT From: DSMITH@OREGON.UOREGON.EDU (Dale Smith) To: comp.protocols.tcp-ip Subject: potential problems with TTL = 0
What is the current "correct" value to place for the TTL field? Can someone with a Sequent Balance 21000 verify what the initial TTL value is for TCP, UDP, and ICMP packets? The reason for this query is that I am having problems delivering mail to uunet.uu.net which is a Sequent Balance 21000. I have observed TCP packets from uunet.uu.net being dropped by my gateway because the TTL was 0. This seems to only happen for TCP traffic. I can ping uunet and get response of 1-2 seconds. I can use nslookup to query uunet.uu.net using datagram (UPD) mode. However, use of any TCP based service to uunet causes lots of TCP packets from uunet to be dropped at my gateway with TTL = 0. I have captured and looked at the UDP and ICMP packets from uunet and they have different, but adequately large TTL values. The folks at uunet say they are running some beta version of TCP/IP. So, is there anyone out there from Sequent who can verify that this is or is not a known problem? Can someone with a Balance 21000 who is running beta-version TCP software look at what the initial TTL value is? Thanks, Dale Smith, Assistant Director of Network Services Internet: dsmith@oregon.uoregon.edu BITNET: dsmith@oregon.bitnet Voice: (503) 686-4394 USmail: University of Oregon Computing Center Eugene, OR 97403-1212
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 01:16:00 GMT From: CERF@A.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Networking Classes
Send her to one of Dan Lynch's tutorial sequences - he just did a good one in Washington, DC. Dan runs Advanced Computing Environments out of Palo Alto, CA (on San Antonion Roa). He can be reached as Lynch@ISI.EDU. Vint Cerf
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 13:02 EDT From: Corrigan @ DDN3.ARPA To: tcp-ip @ sri-nic.arpa Subject: FTP Checkpoint
The FTP implementation on the Honeywell mainframe done for the World-Wide Military Command and Control System (WWMCCS) implements and uses checkpoint/ restart. It also lets you begin a transfer, leave, and check back later on status. They used to move huge files in the mid/late 70's and restart was essential for operational, not cost, reasons, because the system didn't stay up long enough to complete very many transfers. The checkpoints were based o time, not number of records transfered, because the variability in throughput was high, and minimizing the amount of lost time was the important issue. I think 5 minutes between checkpoints was the default. All this continues to work as we speak -- of course the protocol it is running over is NCP...... Mike
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 14:05:57 GMT From: rdt@teddy.UUCP (Ron D. Thornton) To: comp.protocols.tcp-ip Subject: Re: TCP for Dec RT11 or DG RDOS
Process Software Corp has a version of TCP/IP for RT-11 SJ, FB, or XM. While I did have a different opinion about what constituted bugs (broadcast storms and static host names in the arp table) they have improved the product and it does fit on an RT-11 system. Process Software - Amherst, MA - (413) 549-6994 -Ron-
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 14:35:52 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: can someone recommend a book covering tcp-ip and nfs?
Robin, You should read Doug Comer's new book on TCP/IP. "Internetworking with TCP/IP, Prentice Hall, ISBN 0-13-470154-2. And, you should come to Monterey next Monday to attend a two day seminar on TCP Performance taught by Van Jacobsen and Mike Karels of Berkeley. My company, Advanced Computing Envrionments is sponsoringn it, so I have some prejudice. next week is probably too son for any bureaucracy to move, but it is really your best bet for getting tons of good info in a hurry. Dan 415-941-3399 PS. Send me your US Snail addres so we can keep you informed of future events. -------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 16:07:28 GMT From: sundc!hadron!rlgvax!dennis@seismo.css.gov (Dennis.Bednar) To: tcp-ip@sri-nic.arpa Subject: Novell and TCP-IP interoperability
[The message below is posted for another CCI employee.
Please send replies to me, and I will forward to him.
Thanks. dennis]
MICOM
TCP Gateway for Novell Netware
I am looking for a site that has installed the MICOM TCP Gateway
for Novell Netware connected specifically to a UNIX system. They
use their NP600G board in the file server. The board allows PC's
connected to the Novell file server to log on a UNIX system. For
my purposes it doesn't matter what topology they are using ( token
ring, starlan etc. ) but it does need to be connected to ethernet.
I understand the gateway works great but I need to reference a
site. If anyone knows of a site that is using this board please
let me know.
Thanks in advance for any help.
BILL BURCH
--
FullName: Dennis Bednar
UUCP: {uunet|sundc}!rlgvax!dennis
USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091
Telephone: +1 703 648 3300
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 17:02:00 GMT From: Corrigan@DDN3.ARPA To: comp.protocols.tcp-ip Subject: FTP Checkpoint
The FTP implementation on the Honeywell mainframe done for the World-Wide Military Command and Control System (WWMCCS) implements and uses checkpoint/ restart. It also lets you begin a transfer, leave, and check back later on status. They used to move huge files in the mid/late 70's and restart was essential for operational, not cost, reasons, because the system didn't stay up long enough to complete very many transfers. The checkpoints were based o time, not number of records transfered, because the variability in throughput was high, and minimizing the amount of lost time was the important issue. I think 5 minutes between checkpoints was the default. All this continues to work as we speak -- of course the protocol it is running over is NCP...... Mike
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 18:39:58 GMT From: jeremy@swatsun.uucp (Jeremy Brest) To: comp.protocols.tcp-ip,comp.os.vms,comp.protocols.misc,comp.protocols.appletalk Subject: Any experiences w/ DECnet in a multi-vendor environment?
I'm interested in any experiences that anyone has had with trying to use DECnet as the central protocol in a multi-vendor network environment. How well (i.e., transparently) do the following work? 1) remote login to local sites? 2) remote login to wide area TCP-IP networks? 3) file transfer between local sites? 4) file transfer (anonymous FTP) over wide area TCP-IP networks? 5) local mail? 6) mail through wide area networks, including uucp, bitnet, wide area TCP-IP networks, and CSNet? Other concerns are how Macintoshes and MS-DOS machines fit into the picture. I know that with TCP-IP, software has been developed to provide login and file transfer, as well as sever implementations of mail systems. What about with DECnet? I'm also interested in how might a heterogenious network work out, that is, have a few machines that spoke both TCP-IP and DECnet, but most machines speaking one or the other. Thanks, Jeremy Brest Swarthmore College uucp: ...seismo!bpa!swatsun!jeremy CSnet: jeremy@swatsun.swarthmore.edu Internet: jeremy%swatsun.swarthmore.edu@relay.cs.net
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 20:55:19 GMT From: ron@topaz.rutgers.edu (Ron Natalie) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together???
XNS and TCP/IP will coexist on an Ethernet. They use different Ethernet Type numbers. I have the TCP/IP version of flight simulator when you're ready. -Ron
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 21:23:55 GMT From: wiltzius@lll-lcc.aRpA (Dave P. Wiltzius) To: comp.protocols.tcp-ip Subject: Raw Sockets
I'm being a bit lazy here: I want to use an IP raw socket to implement a non-Internet transport protocol on IP (please, this is an exercise and not my idea). The particular UNIX system is Sun's 3.2. Can only "super-user" use the IP raw socket? I suspect this is a silly question, but can there only be one process on the system using the IP raw socket? For those of you that did this (as it was intended) to prototype and debug transport code, what was the difference in performance between the raw socket implementation and the kernel implementation. Any comments as an aside would be welcome - perhaps more appropriately as E-mail. Thank you. -------------------------------------------------------------------- Dave Wiltzius (wiltzius@lll-lcc.llnl.gov)
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 3 May 88 23:10:20 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: Another problem with usage charges
The discussion of refunding aborted FTPs reminds me of a common trick among the Cornell RJE terminal operations staff back during my undergrad hacking days. The system (IBM OS/360, batch oriented) charged for each line actually printed. However, since line printers jam from time to time, the RJE operator could command the system to restart a print job from the beginning, canceling the charges for the copy already printed. But it became common practice among those operators whose funny-money accounts were running low to add several pages of unneeded garbage to their job output. When the useful stuff had all been printed, they would restart the job and then kill it, thus costing them NOTHING for the output they did print. Clearly any FTP refund scheme would invite exactly the same sort of abuse. On the other hand, I would like to repeat a quote I saw on the net almost 10 years ago. I wish I could remember who said it. It seems relevant to the subject at hand: "There may be no such thing as a free lunch, but sometimes it costs more to collect money than to give away food". Phil
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 4 May 88 04:44:16 GMT From: wales@CS.UCLA.EDU To: sci.research,comp.protocols.tcp-ip Subject: Research on protocol optimization for slow networks?
I am looking for any leads to recent research on the question of how to improve the performance of a communications protocol to make it more acceptable for use over a "slow" network link. By "slow", I am thinking (roughly speaking) of 9600 bits/sec or slower for interactive work. If the application involves transfer of large amounts of data, then some people might consider faster links (e.g., 56K bits/sec) to be "slow". I'm open to the possibility of improving protocol performance at any or all levels. I haven't tried to narrow myself down very much yet. I'm aware, for instance, of the work of various high-speed modem manu- facturers in implementing data compression and/or certain protocols in their modems (e.g., Telebit's UUCP packet protocol implementation). But I haven't had much luck in finding other material. Any pointers to current or recent research in this area would be grate- fully appreciated. -- Rich Wales // UCLA CS Dept // wales@CS.UCLA.EDU // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA ...!(ucbvax,rutgers)!ucla-cs!wales ...!uunet!cs.ucla.edu!wales "Mr. LaForge, when I left this ship it was in one piece!"
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 4 May 88 05:40:04 GMT From: RMRichardson.PA@XEROX.COM (Rich) To: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
In article <51442@sun.uucp> limes@sun.com (Greg Limes) writes: > In article <218@turbo.RAY.COM> Robin@turbo.RAY.COM (Robin Alston) writes: > >Can XNS and TCP-IP share the same coax cable with no possible problems? > ... It is even possible (gag) to run both TCP/IP and XNS through the same > physical interface, but the bottom layer does need to know where to send > each packet type. ... My workstation can talk PUP, XNS and TCP/IP simultaneously, i.e., three connections at once, all on the same wire. I make no claims about speed, etc., just that it can be done, so you should be able to do the same. > >Can we have our own domain (we really have no interest at this time in > >talking to our vaxes), while decnet has its own on the same cable? This should be ok; the fun part comes when you do want to talk to each other. Then you need an XNS package on the vaxes, or TCP-IP on your other machines. Rich
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Wed, 4 May 88 17:42:45 PDT From: croft@csli.stanford.edu (Bill Croft) To: tcp-ip@sri-nic.ARPA Cc: croft@csli.stanford.edu, karwowska@dg-rtp.dg.com Subject: re: Public Domain Software for BOOTP
> Date: 28 Apr 88 19:11:28 GMT > From: rti!xyzzy!karwowska@mcnc.org (Joanna Karwowska) > Subject: Public Domain Software for Bootp > > I would like to get an access to the public domain software > for remote bootstrap protocol - bootp (RFC951). > Can anybody help? > > Joanna Karwowska > karwowska@dg-rtp.dg.com > Data General, Research Triangle Park, NC > <the known world>!mcnc!rti-sel!rtp46!karwowska You can anonymous FTP the files 'bootp.client.shar' and 'bootp.server.shar' from the pub directory on safe.stanford.edu. The client code autoconfigures to find and boot from a couple of different ether interfaces (3COM/Interlan). The server runs under 4.X BSD UNIX. A number of vendors are now supporting this boot mechanism.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 4 May 88 14:39:31 GMT From: dheeraj@chakra.cs.umd.EDU To: comp.protocols.tcp-ip Subject: LSRR option in IP
I have been trying to use LSRR option of IP to route a packet through various machines on the campus. Most machines just drop the packet. I went into the ip_input code. It seems that ip_forward(ip, ifp) drops the packet if 1. ipforwarding is off OR 2. in_interfaces is <= 1 That means that hosts with only one interface cannot have packets loose source routed through them. I don't understand why this should be the case. If some Gateway is trying to route the packet through this machine, then it make sense to let the Gateway know that it is inefficient to route the packet this way but if a user is forcing the packet through this machine then I don't see why should the packet be dropped. Actually, if the machine has more than one interfaces and the routing alogrithm decides to forward the packet through the same interface as it came on then the packet is not dropped. (Isn't it similar to having one interface and forwarding the packet through the same one.) Thanks, dheeraj sanghi
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 5 May 88 00:42:45 GMT From: croft@CSLI.STANFORD.EDU (Bill Croft) To: comp.protocols.tcp-ip Subject: re: Public Domain Software for BOOTP
You can anonymous FTP the files 'bootp.client.shar' and 'bootp.server.shar' from the pub directory on safe.stanford.edu. The client code autoconfigures to find and boot from a couple of different ether interfaces (3COM/Interlan). The server runs under 4.X BSD UNIX. A number of vendors are now supporting this boot mechanism.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 05/05/88 18:03:11 From: Keith R. Hacke <M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA> To: <tcp-ip@sri-nic.arpa> Subject: Wollongong's TCP/IP
We are planning to purchase Wollongong's TCP/IP implementation for a MicroVAX running VMS. I am particularly interested in its use for Domain Name Serving between our Ethernet and the DDN (we have a Milnet connection). VMS is used on our VAXs, UNIX on the Suns and Silicon Graphics. What do you think of Wollongong's TCP/IP? Is anyone using it for Domain Name Serving? With a VAX running VMS? Other ideas (I know about using a Sun for the Domain Server)? Thanks Keith R. Hacke McDonnell Douglas 314-895-5343 PS Thanks to those who gave info on D. Comer's TCP/IP book. Our company library is getting it.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 5 May 88 13:27:31 GMT From: per@erix.UUCP (Per Hedeland) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Subnetting
Excuse me if the question below is trivial, but I really haven't seen much
discussion on subnetting, and neither RFC reading nor local asking-around
has gotten me very far...
This is the scenario: The basic structure of our LAN is a backbone segment,
to which a number of Sun server/client groups are connected. Each client group
has it's own Ether segment, with the server acting as gateway to the backbone.
Typically there are 5-10 clients in each group. There are currently some 20
such groups, but predictions are for hundreds in the not too distant future,
i.e. considering other connected equipment, far more than 256 addresses are
required for the backbone.
Due to us not being connected to the Internet, and inadequate planning of the
growth of the LAN, network numbering is a mess, which we would like to clean up
as soon as possible, and this prompts my question: It seems to be a terrible
waste of adress space to use a separate class C number for each of the client
groups, so we figured that subnetting would be appropriate, but how do we use
it to an advantage?
Specifically, given the abovementioned structure, there's a conflict between:
a) It appears that the intended use of subnetting assumes that all the "subs"
of a "whole" net are interconnected, i.e. the backbone and the client
segments in our case should be "subs" of the same "whole" - in particular,
"automatic" routing by means of routed (which we desire) will not work
otherwise, as far as I can understand.
and:
b) "Subs" of a given "whole" must be of equal size.
We do believe that the arguments for the current structure (such as handling
the load from diskless clients, avoiding extra cabling given the physical
location of servers and clients, allowing use of the backbone for e.g. DECnet
traffic) are valid, and it seems rather silly having to modify it to
accommodate the IP adressing scheme. But of course, neither the structure nor
the requirement for "automatic" routing are carved in stone, i.e. any and all
suggestions are welcome (preferrably via e-mail, and I will summarize to the
net if requested).
Thanks In Advance
--Per Hedeland
Internet: per@erix.ericsson.se
Non-MX: per%erix.ericsson.se@uunet.uu.net
UUCP: {mcvax,munnari,uunet}!enea!erix!per
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 5 May 88 13:29:41 GMT From: dnwcv@dcatla.UUCP (William C. VerSteeg) To: comp.protocols.tcp-ip Subject: Bootp information
This is a request for information on the Bootp protocol. As I understand it, this protocol allows a dumb device to be loaded from from a server device. I am particularly interested to know if the protocol works using IP routers, subnets, fragmentation, etc. Also an approximation of the PROM space required to contain enough of this code to boot a device from power-up (i.e. one that doesn't know its own IP address) Please send a pointer to the apropriate information to me directly. I will summarize to the net if there is enough interest. Thanks in Advance Bill VerSteeg
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 May 88 18:30:32 EDT From: Lyle Evans <EVANSL%VTVM1.BITNET@CUNYVM.CUNY.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: Federation of American Research Networks (FARnet)
Sergio Heker <heker@jvnca.csc.org> writes > ... >As a point of information, there is a task force whithin the Federation >of American Research Networks (FARnet), working on this issue right now. Could somebody give me some more information about the Federation of American Research Networks FARnet ? Lyle Evans (Bitnet: Evansl @ VTVM1 )
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 5 May 88 14:44:43 GMT From: ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) To: comp.protocols.tcp-ip Subject: Whither Chargeback
The issues being discussed here regarding chargeback are faced regularly by every corporation which has a private telecommunications network. Consider the following: 1. What to do when different networks have different prices? This is eminently true of today's telecommunications providers. MCI, AT&T, and Sprint all have different price schedules. You can buy leased lines with flat rates for service up to a bandwidth limit, WATS lines which are distance insensitive but usage priced (after a minimum), and regular Direct Distance Dialed (DDD) service which is priced by both time and distance. Corporations buy Private Branch Exchanges (PBXs) with Least Cost Routing (LCR) software which decides on a call-by-call basis which network to use. Calls go by preference over leased lines since you've paid for them anyway. If the leased line is busy, there are several alternatives: a) you get a busy signal and the client places the call again, perhaps specifying an alternate carrier; b) the call automatically overflows onto the next highest cost facility. As to chargeback in this environment, again there are several approaches. You can calculate the average cost per minute over the various networks (leased lines, WATS, etc.) for all calls from A to B and use that as the basis for chargeback. This puts the burden on the telecom manager to optimize the LCR and the facilities to minimize total costs. Or, particularly with option a) above, the user pays the cost for the facility used; if he replaces the call on the DDD network rather than waiting for the tie line to become free, he pays a higher price for the call. Time of day pricing leads users to defer traffic such as mail to off peak hours. This reduces the peak traffic and the corresponding network capacity required. There are lots of variations in between. 2. Connection charges versus usage charges. Both are clearly required. Much of the network cost is in access, so connection charges should probably recover a large chunk of the total cost. But usage charges are also important: how else do you justify investing in that FTP implementation that uses the restart facility? Usage charges create incentives to write better software (or to go out and buy better software) that will cut the usage cost. In the same way, time usage charges on DDD networks lead customers to justify buying higher speed modems or data compression boxes. Right now, there is only the small incentive of minimizing processor interrupts to get people to write network code that does sensible thinks about packet acknowledgements. 3. Money for capacity expansion. In the U.S. the carriers have always financed capacity expansion out of profits or borrowing. In Europe, for example France before 1970, capacity expansion had to be funded out of legislative appropriations; all profits were returned to the treasury. Anyone who ever tried to use a phone in France before 1970 knows how the French underfunded capacity expansion under this regime. Corporations without chargeback to the internal users have the same problem justifying appropriations from corporate budget directors. 4. Volume discounts. Volume discounts can make usage charges fair to both large users and smaller ones. After all, a T1 link costs less than 24 56 kbps links; large users enable the network to buy more cost effective transmission links. We have volume discounts for electric power and for telecommunication users in the commercial world. 4. Cross subsidies. There should be subsidies for various "deserving" users, like lifeline telephone rates. They should be explicitly targeted, not general for everyone. Most of the issues being discussed have been faced and the consequences of alternative policies understood by corporate telecom managers. Some research into what has already been done in other settings would be very useful. Marvin Sirbu
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Thu, 05 May 88 23:03:31 PDT From: satz@clash.cisco.com To: tcp-ip@sri-nic.arpa Subject: DDN X.25 Standard diagnostic codes
Would someone be so kind as to forward me a copy of the latest DDN specific diagnostic codes? The codes I have are from the latest DDN specification circa 1983 and it seems newer codes are being returned in CLEAR REQUEST packets. Thanks!
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 5 May 88 18:21:05 GMT From: paulf@Shasta.STANFORD.EDU (Paul A. Flaherty) To: comp.protocols.tcp-ip Subject: att.com domain wierdness
I've noticed that the att.com MX entry keeps on drifting between att.arpa and rutgers.edu; can anyone give an explaination? -- -=Paul Flaherty, N9FZX | One Internet to rule them all, -- Tome Computer Systems Laboratory | One Internet to find them; of Stanford University | One Internet to bring them all, Internet ->paulf@shasta.Stanford.EDU | And in the Ether bind them. Hacking
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 5 May 88 22:30:32 GMT From: EVANSL@VTVM1.BITNET (Lyle Evans) To: comp.protocols.tcp-ip Subject: Federation of American Research Networks (FARnet)
Sergio Heker <heker@jvnca.csc.org> writes > ... >As a point of information, there is a task force whithin the Federation >of American Research Networks (FARnet), working on this issue right now. Could somebody give me some more information about the Federation of American Research Networks FARnet ? Lyle Evans (Bitnet: Evansl @ VTVM1 )
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 01:03:11 GMT From: M197993%SLVM307.McAuto.Tymnet@OFFICE-1.ARPA (Keith R. Hacke) To: comp.protocols.tcp-ip Subject: Wollongong's TCP/IP
We are planning to purchase Wollongong's TCP/IP implementation for a MicroVAX running VMS. I am particularly interested in its use for Domain Name Serving between our Ethernet and the DDN (we have a Milnet connection). VMS is used on our VAXs, UNIX on the Suns and Silicon Graphics. What do you think of Wollongong's TCP/IP? Is anyone using it for Domain Name Serving? With a VAX running VMS? Other ideas (I know about using a Sun for the Domain Server)? Thanks Keith R. Hacke McDonnell Douglas 314-895-5343 PS Thanks to those who gave info on D. Comer's TCP/IP book. Our company library is getting it.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 01:45:51 GMT From: zemon@felix.UUCP (Art Zemon) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together???
Other people have given you the theoretical whys and
wherefores about doing this. I thought I would chip in some
practical experience in case you are the type who wants
"real proof". (I'm not trying to be derogatory here, just
helpful.)
We run one Ethernet cable with the following protocols on
it:
TCP/IP
XNS
DECnet
DEC LAT
DEC MOP
Everything runs just fine. Don't worry about it.
--
-- Art Zemon
By Computer: ...!hplabs!felix!zemon
By Air: Archer N33565
By Golly: moderator of comp.unix.ultrix
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Fri, 6 May 1988 09:15:33 LCL From: John M Wobus <JMWOBUS@SUVM.ACS.SYR.EDU> To: TCP-IP Discussion Group <TCP-IP@SRI-NIC.ARPA> Subject: Discussion group on campus-sized networks.
This is a reminder that there is an electronic-mail "list" or "discussion
group" dedicated to campus-sized networks. I created it largely because I
saw messages on the TCP-IP list that were really more about campus-sized
networks than about TCP-IP and thought it would be nice to have a place
where we wouldn't feel guilty discussing the stuff. You are welcome to
join this list (which typically has about half the volume of TCP-IP).
See the "blurb" below.
John Wobus
Syracuse University
=-------------------
BIG-LAN@SUVM.ACS.SYR.EDU (Internet)
BIG-LAN@SUVM (Bitnet)
This list is for the discussion of issues in designing and operating
Campus-Size Local Area Networks, especially complex ones utilizing
multiple technologies and supporting multiple protocols. Topics
include repeaters, bridges, routers and gateways; how to incorporate
smaller Personal-Computer type LANs into the campus-wide LAN; how to
unify the mail systems, etc. This is an ideal list in which to debate
the relative merits of bridges vs routers.
All requests to be added to or deleted from this list, problems,
questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet)
or BIG-REQ@SUVM (Bitnet). Those familiar with revised LISTSERV can
subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM
(Bitnet).
Archives are available through revised LISTSERV.
Coordinator: John Wobus <JMWOBUS@SUVM.ACS.SYR.EDU>
<JMWOBUS@SUVM>
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 06:03:31 GMT From: satz@CLASH.CISCO.COM To: comp.protocols.tcp-ip Subject: DDN X.25 Standard diagnostic codes
Would someone be so kind as to forward me a copy of the latest DDN specific diagnostic codes? The codes I have are from the latest DDN specification circa 1983 and it seems newer codes are being returned in CLEAR REQUEST packets. Thanks!
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 14:36:41 GMT From: JMWOBUS@SUVM.ACS.SYR.EDU (John M Wobus) To: comp.protocols.tcp-ip Subject: Discussion group on campus-sized networks.
This is a reminder that there is an electronic-mail "list" or "discussion
group" dedicated to campus-sized networks. I created it largely because I
saw messages on the TCP-IP list that were really more about campus-sized
networks than about TCP-IP and thought it would be nice to have a place
where we wouldn't feel guilty discussing the stuff. You are welcome to
join this list (which typically has about half the volume of TCP-IP).
See the "blurb" below.
John Wobus
Syracuse University
=-------------------
BIG-LAN@SUVM.ACS.SYR.EDU (Internet)
BIG-LAN@SUVM (Bitnet)
This list is for the discussion of issues in designing and operating
Campus-Size Local Area Networks, especially complex ones utilizing
multiple technologies and supporting multiple protocols. Topics
include repeaters, bridges, routers and gateways; how to incorporate
smaller Personal-Computer type LANs into the campus-wide LAN; how to
unify the mail systems, etc. This is an ideal list in which to debate
the relative merits of bridges vs routers.
All requests to be added to or deleted from this list, problems,
questions, etc., should be sent to BIG-REQ@SUVM.ACS.SYR.EDU (Internet)
or BIG-REQ@SUVM (Bitnet). Those familiar with revised LISTSERV can
subscribe with LISTSERV@SUVM.ACS.SYR.EDU (Internet) or LISTSERV@SUVM
(Bitnet).
Archives are available through revised LISTSERV.
Coordinator: John Wobus <JMWOBUS@SUVM.ACS.SYR.EDU>
<JMWOBUS@SUVM>
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 15:33:53 GMT From: bc@halley.UUCP (Bill Crews) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting
In article <1607@erix.UUCP> per@erix.ericsson.se (Per Hedeland) writes: > >Typically there are 5-10 clients in each group. There are currently some 20 >such groups, but predictions are for hundreds in the not too distant future, >i.e. considering other connected equipment, far more than 256 addresses are >required for the backbone. > It seems to be a terrible >waste of adress space to use a separate class C number for each of the client >groups, so we figured that subnetting would be appropriate, It does to me, too. So, why not just use class B addresses? Based on the criteria you dictate, that would seem to be adequate for now and the future. -bc -- Bill Crews Tandem Computers bc@halley.UUCP Austin, Texas ..!rutgers!im4u!halley!bc (512) 244-8350
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 19:39:34 GMT From: LYNCH@A.ISI.EDU (Dan Lynch) To: comp.protocols.tcp-ip Subject: Re: Campus Network Query
Greg, There is excellent brand new book on thart subject. It is called "Campus Networking Strategies", Caroline Arms, Editor. It is "sponsored" by EDUCOM, published by Digital Press, ISBN 1-55558-009-2, Order No. EY-6736E-DP. It is a collection of description sof the campus networks and how they came to be. All written by knowledgable people. The campuses included are: Wesleyan, Dartmouth, CMU, Rensselaer, MIT, Stanford, Cornell, Michigan, Minnesota and Penn State. Dan -------
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 23:49:17 GMT From: egisin@watmath.waterloo.edu (Eric Gisin) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together???
One thing no-one has mentioned yet is the case where the ethernet type is a valid 802.3 packet length. I think Xerox PUP falls in to this catagory (what's PUP anyway?). What do 802.3 compatible systems do with such packets? VMS 4.4, for example, supports 802.3 LLC headers.
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 6 May 88 23:53:11 GMT From: chris@MIMSY.UMD.EDU (Chris Torek) To: comp.protocols.tcp-ip Subject: A new record?
PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes 64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms 64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms So where *was* that packet for four minutes and 13 seconds? (Maybe it was routed via the University of Mars :-) ) Chris
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 7 May 88 04:09:30 GMT From: Mills@UDEL.EDU To: comp.protocols.tcp-ip Subject: Re: Campus Network Query
Dan, That sounds like a fantastically useful book. Do you have information on publisher or ISBN? Dave
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 7 May 88 11:50:06 GMT From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) To: comp.protocols.tcp-ip Subject: Re: A new record?
Chris: not a record, unfortunately. Dave Mills, at least, has one that returned after 16 minutes and something -- I'll bet there are even better ones. Scott
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 7 May 88 12:24:09 GMT From: milazzo@RICE.EDU (Paul Milazzo) To: comp.protocols.tcp-ip Subject: Re: A new record?
Chris: I once ran ping for hours on a newly-installed proNet-10, with similarly frightening results. My host, a lightly-loaded VAX-11/750, was pinging itself because it was the only host on the ring. Amidst thousands of 20 msec round-trip times, one ping returned---out of sequence---after 11.5 seconds! Where could it have hidden for that long? I assume it was parked in an mbuf somewhere; a three-million kilometer detour seems unlikely... Paul G. Milazzo <milazzo@rice.EDU> Dept. of Computer Science Rice University, Houston, TX
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 7 May 88 13:17:57 GMT From: steven@lakesys.UUCP (Steven Goodman) To: comp.protocols.tcp-ip Subject: 3.1 & Excelan
Recently installed the Excellan TCP/IP software and 205T board
in an AT&T 8386 box, running AT&T's UNIX System V Release 3.1.
The Excellan software is 8014-01.
The machines seem to be able to "talk" ok with the exception of
some failures with "rcp", "ftp", and "rsh" (remsh). Now Excellan
does not presently support 3.1 and I am looking for someone whom perhaps has this package presently running under 3.1.
Actually with the exception of the above problems, the system
appears to perform fairly well although I have not yet done any
programing with this package, any exchange of information regarding
this would be appreciated. The other machines are running the "WIN"
TCP/IP on AT&T 3B15's and UNIX 2.1.2.
Some of the failures are in having the WIN software talk to the
Excellan, and could possibly be the resault of the new stuff
in 3.1 ( ie; /etc/shadow ) although I have not yet spent alot of
time examining this possibility. It's unfortunate that I have only
one Excellan package running to examine if this is a problem
resaulting in the 2.1.2 and 3.1 or WIN to Excellan.
Might also mention that I would gladly assist anyone attempting
this port as well to get you at least as far as we have.
--
Steven M. Goodman
Lake Systems - Milwaukee, Wisconsin
{ihnp4,uwvax}!uwmcsd1!lakesys!steven
{rutgers,uunet}!marque!/
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 7 May 88 15:11:58 GMT From: Doug_Nelson@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Re: Subnetting
In message <1607@erix.UUCP>, Per Hedeland writes: > a) It appears that the intended use of subnetting assumes that all the "subs" > of a "whole" net are interconnected, i.e. the backbone and the client > segments in our case should be "subs" of the same "whole" - in particular, > "automatic" routing by means of routed (which we desire) will not work > otherwise, as far as I can understand. Yes, that has to be true - you can only advertise your full network, not your subnets, to the Internet at large. > b) "Subs" of a given "whole" must be of equal size. This is a mistaken assumption. There is nothing that prevents you from using subnets of different sizes on a given net, except for software that isn't up to speed on subnetting (notably SunOS 3.x). For example, our campus-wide network is a class B sized subnet of a class A network. The Merit network itself is a class A/2 subnet, and Univ of Michigan has parceled out a number of class C-sized subnets. I plan to pass out class C-sized subnets of our network (or possibly smaller) to several other campus Ethernets, as soon as we get SunOS 4.0 installed. Doug Nelson den@serv1.cl.msu.edu Michigan State University 08071den@msu.bitnet Computer Laboratory
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 8 May 88 02:03:27 GMT From: earle@mahendo.Jpl.Nasa.Gov (Greg Earle) To: comp.protocols.tcp-ip Subject: The ultimate solution to the packet chargeback problem
In article <[A.ISI.EDU]29-Apr-88.18:15:38.CERF> cerf@a.ISI.EDU writes:
>The accounting issue comes up for two reasons: the MILNET operation folks
>need to allocate costs among the users of MILNET and the general growth
>of the Internet infrastructure can't be supported solely on government
>subsidy in today's climate.
I say add an extra MX missile or two to the military's budget request for each
year, but instead funnel the money to AT&T et al. to pay for all the
ARPANET & MILNET network links. That way we don't need chargeback, the
government can subsidize it, and I'll feel just an epsilon better about where
my tax dollars went. Without politicizing the argument, there is so much
waste of government money in the military-industrial complex that I don't
see how anyone in the government could complain about having to subsidize
these networks, which are a sterling example of non-wasted monies buying
such virtuousness :-) I mean, how many months of a 56 Kb line could be
paid for with the price of an Air Force plane toilet seat?
There. That was easy, now wasn't it?
[ BTW: :-) ]
--
Greg Earle earle@mahendo.JPL.NASA.GOV
Indep. Sun consultant earle%mahendo@jpl-elroy.ARPA [aka:]
(Gainfully Unemployed) earle%mahendo@elroy.JPL.NASA.GOV
Lake View Terrace, CA ...!{cit-vax,ames}!elroy!jplgodo!mahendo!earle
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 8 May 88 04:24:48 GMT From: wilson@laic.UUCP (Robin Wilson) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
We have a very large network here at Lockheed. We have Ungermann/Bass terminal servers using XNS, and Vaxen using DECnet, SUNs using NFS and TCP, Symbolics using CHAOS (TCP derivative), and assundry "special" cases using there own brand of protocols. Our primary concern, in having them all use the same cable (baseband Ethernet bridged together with protocol independant VitaLink TransLAN Bridges), is coordinating additions of new devices of the SAME protocol. For example, I work at the Research Lab in Palo Alto, and we are bridged over a VitaLink to the main Lockheed facility in Sunnyvale; we are constantly having problems when the Sunnyvale people connect stuff up to their network and forget to tell us. One time, our DECnet crapped out because we were set to route to only 30 nodes. The Sunnyvale facility had connected a very extensive network to theirs using a VitaLink, the new network had about 40 DECnet nodes, and when they added them to our DECnet, our router began to swap between the thirty most recently seen nodes, and then trashed. The long and the long (no short story here) of it is that if you connect alot of different protocols to your network, be sure you keep tight reigns on the addition of new devices, some of them may have effects you never dreamed of on your other nodes out there. R.D. WILSON "Keep your grubby paws off of my views!"
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 8 May 88 16:02:14 GMT From: wd@dg2kk.rmi.de (Walter Doerr) To: comp.protocols.tcp-ip Subject: Info on TCP/IP book wanted
Can anyone please tell me the price of Doug Comer's book about TCP/IP. I'd like to know because ordering US book here in Germany can be quite expensive. Thanks. Walter
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 8 May 88 16:44:23 GMT From: romkey@kaos.UUCP (John Romkey) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Chaosnet (Re: Many things on ethernet together???)
In article <233@laic.UUCP> wilson@laic.UUCP (Robin Wilson) writes: >... Symbolics using CHAOS (TCP derivative)... Point of information: the Chaos protocols are not TCP-derivative. They were developed independently at the MIT AI Laboratory just before or at about the same time as TCP was first being worked on. The Chaosnet protocols were developed along with the Chaosnet hardware, which is pretty much gone today. They look a lot like TCP except that Chaos addresses are smaller, the reliable stream protocol is sequences blocks of data rather than bytes, and the "IP" and "TCP"-like parts of it are smooshed together, Chaos has 'contact names' rather than well known ports...well, the Chaos protocols bear some resemblance, anyway. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 8 May 88 19:12:51 GMT From: joe@tekbspa.UUCP (Joe Angelo) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting
in article <358@halley.UUCP>, bc@halley.UUCP (Bill Crews) says: > Xref: tekbspa comp.dcom.lans:150 comp.protocols.tcp-ip:495 > > > It does to me, too. So, why not just use class B addresses? Based on the > criteria you dictate, that would seem to be adequate for now and the future. > Now, the classes of IP addresses is simple enough to understand -- But what about subnetting? When does one want to *really* use two IP network address on the same cable? And what performance advantages does this give you? Were does the netmask come it at? Is subnetting just a nice admistrativia thing? Or does your local enet board not receive the packets, period? Or is it the high level software that ignores the packet? Does anything really ignore anything? -- "I'm trying Joe Angelo -- Senior Systems Engineer/Systems Manager to think at Teknekron Software Systems, Palo Alto 415-325-1025 but nothing happens!" uunet!tekbspa!joe -OR- tekbspa!joe@uunet.uu.net
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 8 May 88 21:00:45 GMT From: ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) To: comp.protocols.tcp-ip Subject: Re: A new record?
In article <8805062353.AA23117@mimsy.umd.edu> chris@MIMSY.UMD.EDU (Chris Torek) writes: >PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes >64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms >64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms > >So where *was* that packet for four minutes and 13 seconds? >(Maybe it was routed via the University of Mars :-) ) > >Chris Well, in 253.239 seconds light can travel 75,971,700 klicks. Mars is (ruff-ly) around 120,000,000 klicks away right now, so it didn't get routed through the Protion gateway at U of Mars. My guess is that some VAX at a circular partical accellerator is going flakey and routed this ICMP into the partical beam path...round and round your data goes... --ritchey ruff ruffwork@cs.orst.edu -or- ...!hp-pcd!orstcs!ruffwork
-----------[000059][next][prev][last][first]----------------------------------------------------
Date: 9 May 88 07:27:22 GMT
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To: comp.protocols.tcp-ip
Subject: Re: Subnetting> > b) "Subs" of a given "whole" must be of equal size. > > This is a mistaken assumption. There is nothing that prevents you > from using subnets of different sizes on a given net, except for > software that isn't up to speed on subnetting (notably SunOS 3.x). Unfortunately, there -are- problems with dividing a network into variable-sized subnets -- not just incomplete software implementations but real engineering problems. They relate to cases where hosts or gateways need to know the size of a subnet they're not attached to: e.g. when interpreting an ICMP network redirect, synthesizing a remote broadcast address, or routing to a remote subnet. You may be able to live with the effects of misinterpretations if things are kept simple enough (so long as nothing sends you a network redirect :->). The subnetting RFCs, e.g. 917, 936, 950 discuss some possible conventions for determining subnet sizes, including equal sizes on a given network (easy) and self-encoding subnet sizes analogous to the class A/B/C sizing for ordinary networks. I suppose it would also be possible to distribute a table of subnet sizes to every host and gateway on a network. But in general, you -do- have to be able to know the sizes of sibling subnets, and the equal-size case seems to be the closest one to a standard. Stuart Levy
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 12:11:05 GMT From: grr@cbmvax.UUCP (George Robbins) To: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted
In article <477@dg2kk.rmi.de> wd@dg2kk.UUCP writes:
> Can anyone please tell me the price of Doug Comer's book about TCP/IP.
> I'd like to know because ordering US book here in Germany can be quite
> expensive.
I got my copy at Reiter's bookstore in Wash. DC for $36.00 - I assume
this is the list price. I haven't read the whole thing yet, but it
appears to be an excellent overview of the subject...
--
George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 18:33:00 EST From: <wontrop@bluto.scc.com> To: "tcp-ip" <tcp-ip@sri-nic.arpa> Subject: TCP/IP for WANG devices?
I am doing a report for a client within the Federal Government. Does anyone know of an implementation of TCP/IP for either the WANG Alliance Minicomputer or the WANG Wise Box? The configuration includes DOS terminals connected to the Alliance Minicomputer forming a star, and some Wise Boxes - All WANG equipment. I do not know the exact operating system version, and I have tried the TCP/IP vendors guide. Any help would be appreciated. Please send responses directly to me...I will post if anyone else is interested in this. Thanks Ron Wontrop Contel Federal Systems WONTROP@BLUTO.SCC.COM
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 15:34:15 GMT From: dls@mace.cc.purdue.edu (David L Stevens) To: comp.protocols.tcp-ip Subject: Re: Subnetting
Differing subnet sizes are not really a problem on all systems--
the "only if your software isn't up to snuff" comment applies.
4.3BSD includes enhancements to ICMP to ask for the interface's
netmask ("ICMP_MASKREQ"). I don't know of any user-level program that uses
this (yet).
Also, I don't think it's been clear that the "variable size" subnets
are by individual bits, not just bytes. You can split a class B net number
into 17 bits of network and 15 bits of host, if that's what you really want
to do. Some software only supports A subnetted to B and B subnetted to C
(ie, by bytes), though. Void where prohibited. Your mileage may vary.
Of course, if you have sources, you can fix it.
--
+-DLS (dls@s.cc.purdue.edu)
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 16:11:40 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Subnetting
> > b) "Subs" of a given "whole" must be of equal size. > > This is a mistaken assumption. There is nothing that prevents you > from using subnets of different sizes on a given net, except for > software that isn't up to speed on subnetting (notably SunOS 3.x). Unfortunately, there -are- problems with dividing a network into variable-sized subnets -- not just incomplete software implementations but real engineering problems. They relate to cases where hosts or gateways need to know the size of a subnet they're not attached to: e.g. when interpreting an ICMP network redirect, synthesizing a remote broadcast address, or routing to a remote subnet. Stuart, Let's consider the three examples you cite. Network Redirect: It is recognized that network redirects are a problem in a subnetted environment, and therefore the Gateway Specification RFC-1009 says that gateways should only be sending host redirects. If you have a gateway within your subnetted environment that is sending network redirects, it should be brought up to spec. Synthesizing a remote broadcast -- presumably you mean a directed broadcast. Yes, this is a real engineering problem, although it is an application-level problem, not an IP level problem. If you have an application that is sending directed broadcasts into another subnet of the same network, that application needs some configuration information -- obviously, it needs the remote subnet number. You might as well configure it with the complete 32-bit Internet directed broadcast address. Synthesizing IP addresses should be avoided whenever possible. Routing to a remote subnet -- This is entirely a gateway problem. The solution, as RFC-1009 suggests, is simply to include the subnet masks with the network numbers in the routing updates among the subnet gateways. I wonder why no one has extended RIP in this obvious way yet. As you say, it is merely a matter of a little engineering. After all this, I would challenge your statement that "in general, you -do- have to be able to know the sizes of sibling subnets" (at least, if "you" is a host, not a gateway). Bob Braden
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 16:15:45 GMT From: bzs@bu-cs.BU.EDU (Barry Shein) To: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted
>Can anyone please tell me the price of Doug Comer's book about TCP/IP. >I'd like to know because ordering US book here in Germany can be quite >expensive. I don't see any list price on it, I bought it at Stacey's in Palo Alto, CA for $36.00. Beyond that you should probably call Prentice-Hall. -Barry Shein, Boston University
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 16:32:08 GMT From: Doug_Nelson@UM.CC.UMICH.EDU To: comp.protocols.tcp-ip Subject: Re: Subnetting
As a couple of you have pointed out, routing is the problem with multiple subnets of different sizes. We manage routing within our subnet very trivially - we don't really do routing, since we have only a single gateway to the outside world. I encourage our Sun owners to add a default route pointing to their own system, which adds a few ARPs to our local network, but finds the gateway just fine. What really is needed is a subnet routing protocol which passes netmasks along with the network numbers. Is anyone working on this yet? Can anyone tell me if 4.3bsd includes the netmask in each routing table entry? We need this to make such a protocol usable. Doug Nelson
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 17:21:12 GMT From: karn@thumper.bellcore.com (Phil R. Karn) To: comp.protocols.tcp-ip Subject: Re: The ultimate solution to the packet chargeback problem
> ... Without politicizing the argument, there is so much > waste of government money in the military-industrial complex that I don't > see how anyone in the government could complain about having to subsidize > these networks... You don't understand how bureaucrats work. When faced with a budget crunch, they do NOT respond by trimming the most wasteful expenditures first. Rather, they immediately zero in on the most visible, efficient, essential and popular programs, hoping that the resulting public backlash will pressure the legislators into restoring their original budget. This is a standard ploy at all levels of government. Phil
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 17:45:19 GMT From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) To: comp.protocols.tcp-ip Subject: Honeywell and DG
Good morning all! I am going to be running Honeywell and Data General systems on a LAN soon and have been told by a customer that they have TCP/IP implement- ations running on them. Does anyone have any comments, suggestions, war stories or anything else that relates to these implementations? I have never been one for reinventing the wheel and would be very grateful for any input that could make this a bit easier. Thanks in advance, Chris VandenBerg ACC chris@acc-sb-unix.arpa
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 18:37:55 GMT From: ed@mtxinu.UUCP (Ed Gould) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Subnetting
>Now, the classes of IP addresses is simple enough to understand --
>
>But what about subnetting? When does one want to *really* use
>two IP network address on the same cable? And what performance
>advantages does this give you? Were does the netmask come it at?
The purpose of subnetting is not to run multiple IP addresses
on the same cable, but to make a local collection of networks
appear as if it were one network from the outside. To do this,
one takes a standard IP adress (ususally a Class B address, but
this isn't required) and uses some of the bits that are normally
the "host number" part of the address as if they were part of
the "network number." The netmask determines the division between
host part and network part that is used locally.
For example, consider the following /etc/hosts excerpt, which lists
several Class B addresses. Keep in mind a netmask of 0xFFFFFF00
(the normal Class B netmask is 0xFFFF0000).
129.1.1.1 main-sys
129.1.2.1 main-sys-gw
129.1.2.2 second-sys
129.1.2.3 third-sys
One topology this could represent is
net to outside internal net
(129.1.1) (129.1.2)
________ _________________________________
| | | |
| | | |
----------- ------------- --------------
| | | | | |
| main-sys| | second-sys| | third-sys |
| | | | | |
----------- ------------- --------------
In this case, there are two physical networks: one connecting the
three machines locally, and one connecting the main system to the
outside world. To the outside world, the three machines look as if
they are connected together on a single Class B network. Internally,
though, they look as if they were on two separate Class C networks with
a gateway.
--
Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA
{ucbvax,uunet}!mtxinu!ed +1 415 644 0146
"I'll fight them as a woman, not a lady. I'll fight them as an engineer."
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 18:40:45 GMT From: PAYNE@CDCCENTR.BITNET (JAMES M. PAYNE (612) 482-2575 CDC ARH207) To: comp.protocols.tcp-ip Subject: RIP
YES WE ARE CONSIDERING RIP. JIM
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 20:26:09 GMT From: espo@bpa.BELL-ATL.COM (Bob Esposito) To: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted
The price is $46.00 for Doug Comer's TCP/IP book.
--
Bob Esposito, Bell of Pennsylvania uucp: {rutgers|cbmvax|bellcore}!bpa!espo
A Bell Atlantic Company domain: espo@bpa.bell-atl.com
Philadelphia, PA. phone: +1 215 466 6831
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 22:16:34 GMT From: mckay@ea.ecn.purdue.edu (Dwight D Mckay) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
While we're on the topic: Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and AppleTalk (ethertalk?)? --Dwight Mckay, ECN Workstation Software Support [arpanet: mckay@ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay] [Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561]
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 9 May 88 23:33:00 GMT From: wontrop@BLUTO.SCC.COM To: comp.protocols.tcp-ip Subject: TCP/IP for WANG devices?
I am doing a report for a client within the Federal Government. Does anyone know of an implementation of TCP/IP for either the WANG Alliance Minicomputer or the WANG Wise Box? The configuration includes DOS terminals connected to the Alliance Minicomputer forming a star, and some Wise Boxes - All WANG equipment. I do not know the exact operating system version, and I have tried the TCP/IP vendors guide. Any help would be appreciated. Please send responses directly to me...I will post if anyone else is interested in this. Thanks Ron Wontrop Contel Federal Systems WONTROP@BLUTO.SCC.COM
-----------[000073][next][prev][last][first]----------------------------------------------------
Date: 10 May 88 01:23:39 GMT
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To: comp.protocols.tcp-ip
Subject: Re: SubnettingOK. If we have permission to squash systems sending subnet redirects it'll make the situation easier. (At the University of Minnesota we've had real operational problems with this in the past.) And when we do have routing protocols that carry explicit subnet masks I'll happily shut up. It'll still seem useful, though, OK, maybe not essential for hosts to be able to find the subnet structure of a net. For sending directed broadcasts, suppose you want to say "broadcast on the net where host X lives" where X is known by name. It might be desirable to use the normal mechanism for finding X's address rather than hard-wiring an IP address into an application. In that case, since the domain name system doesn't (and shouldn't) record network structure, how could you find the right broadcast address? Admittedly this may stretch the point a bit but not too far, I think. Likewise, if a host and several gateways are on some (sub)net, the host might want to set up its routing tables for a "good" choice of gateway to other subnets. Granting that routing should work if the host picks -some- gateway and depends on that to forward and/or redirect traffic as needed, it could still make good use of the information if it could get it. Again, routing protocols designed for variable-sized subnets would let this happen naturally. Stuart
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 01:50:38 GMT From: braden@VENERA.ISI.EDU To: comp.protocols.tcp-ip Subject: Re: Subnetting
It'll still seem useful, though, OK, maybe not essential for hosts to be able to find the subnet structure of a net. For sending directed broadcasts, suppose you want to say "broadcast on the net where host X lives" where X is known by name. It might be desirable to use the normal mechanism for finding X's address rather than hard-wiring an IP address into an application. In that case, since the domain name system doesn't (and shouldn't) record network structure, how could you find the right broadcast address? Admittedly this may stretch the point a bit but not too far, I think. Stuart, Directed broadcast is generally a poor idea (the right solution is the IP multicasting). No architectural decision should be taken on the grounds that it makes makes directed broadcasting easier. Likewise, if a host and several gateways are on some (sub)net, the host might want to set up its routing tables for a "good" choice of gateway to other subnets. Granting that routing should work if the host picks -some- gateway and depends on that to forward and/or redirect traffic as needed, it could still make good use of the information if it could get it. I disagree. The Internet standard approach for a host: pick any gateway and let it redirect you... is simple and effective. You REALLY DON'T want hosts to know about routing, even subnet routing!! Bob Braden
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 02:08:29 GMT From: lear@athos.rutgers.edu (eliot lear) To: comp.protocols.tcp-ip, paulf@Shasta.STANFORD.EDU Subject: Re: att.com domain wierdness
Thank you for your note. The problem has been noted and corrective action has been taken on this end. -- Eliot Lear [lear@rutgers.edu]
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 13:25:13 GMT From: almes@RICE.EDU (Guy Almes) To: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
RD: The key point here is that ethernet is a ``local area network'' technology, and that its designers *never* intended it to be a wide area network. This is not to say that long-distance bridging is never the right thing to do, but only that you should not be surprised when it exhibits limits. This idea of `local' suggests, not only physically proximity, but also adminstrative unity. In your case, it wasn't the physical distance, but the administrative distance that caused the problems. If you stay with the single pseudo-ethernet bridged approach, then you will need to have admini- strative structures that treat it as a single ethernet. -- Guy
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 14:24:00 GMT From: DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer) To: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
Date: 8 May 88 04:24:48 GMT
From: pyramid!leadsv!laic!wilson@decwrl.dec.com (Robin Wilson)
False information alert!
... Symbolics using CHAOS (TCP derivative) ...
Chaos is not a TCP derivative. Chaos was in active service at MIT
around 1978 or so, which I think was before TCP became operational.
Chaos is more a derivation of (Xerox) PUP and Arpanet NCP, with a bunch
of things "fixed." In some ways it is more powerful than TCP/IP, and in
some ways less. It is certainly not a derivative of TCP, even though
Chaos's designers worked in the same building as some of the major
contributors to the TCP design.
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 16:51:17 GMT From: tsf@arizona.edu (Ted Frohling @ CCIT-Telcommunications, University of Arizona) To: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted
The price for Douglas' book is $US 36.00. -- Ted Frohling Internet: tsf@rvax.ccit.arizona.edu Network Support BITNET: tsf@arizrvax.BITNET CCIT - Telecommunications AT&T: (602) 621-4834 University of Arizona, Tucson, AZ 85721
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 16:59:13 GMT From: mckee@fiona50a.ccs (george mckee) To: comp.protocols.tcp-ip Subject: controlling IP "type of service"
Thinking about network pricing policies and accepting for the moment that relays don't grow on trees, I see on p.12 of RFC791 a description of a "Type of Service" field in an IP packet header that requests different levels of delay, throughput, and reliability, as well as specifying priorities ranging from "routine" through "flash override" and beyond. Do any of the popular implementations actually try to set this field, and does it affect the delivered performance of the network? (My Unix man page for ip(4P) says "other options are ignored".) - George McKee NU Computer Science
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 17:23:56 GMT From: jsloan@wright.EDU (John Sloan) To: comp.protocols.tcp-ip,comp.sys.dec Subject: Plenum-Rated Ethernet Transceivers
I've seen references on the net to plenum-rated ethernet transceivers but have never read any specific citations. Plenum-rated transceivers could be used in the plenum, the environmental air space above drop ceilings (and other places). Plenum-rated transceiver and coax cable is common. I note that the standard DEC transceiver says on its label very specifically that it is NOT plenum rated, as do the BICC and 3COM transceivers we use. The Cabletron transceiver literature says "conforms to UL 910 and NEC 725-2(b) requirements for installation in air-handling spaces". A quick phone call to our rep had him reading this verbatum over the phone, which wasn't much help. Other phone calls have yielded similar results. A call to our University electrician, who is supposed to know at least the codes, was not of much use. So here I am wasting everyone's bandwidth. Does anyone have specific recommendations, including vendor name and part number? If anyone else is interested, I'll investigate it from there and summerize results. Thanks! -- John Sloan, The SPOTS Group Wright State University Research Building CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan +1-513-259-1384 +1-513-873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 17:29:04 GMT From: chuck@excelan.UUCP (Chuck Kollars) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP
(Dwight D Mckay) writes:
>...Is it possible to have Novell NetWare on the same wire with TCP/IP,
XNS and AppleTalk (ethertalk?)?
Yes, all protocols can run on the same Ethernet wire at the
same time. Novell's network OS can run over many different
media, one of which is Ethernet.
If you're using Ethernet with NetWare, consider attaching
*all* the NetWare Servers and *all* the Workstations to one
Ethernet cable. Multiple NetWare Servers on a single cable
works fine. And the Workstations will have direct access
not only to the NetWare Servers, but also to all the
non-NetWare nodes if and when they need it.
--
Chuck Kollars, Excelan, Inc. (chuck@excelan.UUCP)
mabell: (408) 434-7434 Internet: mtxinu!excelan!chuck@ucbvax.Berkeley.COM
telex: 176610 uucp: ...!{mtxinu,leadsv,cae780}!excelan!chuck
fax: (408) 434-2310 post: Excelan, 2180 Fortune Drive, San Jose CA, 95131
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 May 88 00:24 CST From: Derek Andrew <ANDREW%SASK.BITNET@CORNELLC.CCS.CORNELL.EDU> To: TCP-IP@SRI-NIC.ARPA Subject: RE: Re: Many things on ethernet together???
We run many different protocols over the same Ethernet network. We have
encountered one problem which is currently under study.
We had these two 3COM labs for our students. Each lab has a file server. When
both labs were added to the campus network, the servers would both compete for
control over the workstations. That is, machines in one lab would try to log
into the server in the other lab.
The moral of the story is that it is not multiple protocols that will kill you,
but rather networking companies like 3COM with limited vision as to the
environments in which their products will be used.
Note that we run XNS in the 3COM labs, not TCP/IP.
Derek Andrew, Manager of Computer, Networking and Technical Services
University of Saskatchewan
andrew@sask on bitnet
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 10 May 88 23:21:11 GMT From: jqj@HOGG.CC.UOREGON.EDU To: comp.protocols.tcp-ip Subject: Re: Subnetting
> The Internet standard approach for a host: pick any >gateway and let it redirect you... is simple and effective. .... but works abysmally given the typical host software that allows you either to (1) set a static default route to the world, or (2) run passive RIP or something like it. If I choose option 1 and the default gateway crashes, it won't be around to send ICMP redirects telling me to use the backup gateway. Phrased differently, the "Internet standard" does not adequately address the issue of how a host should pick the first gateway to try. >You REALLY DON'T want hosts to know about routing. At issue here is a critical point: how smart is it desirable for hosts to be? Braden argues that they should be very dumb. I would argue that they can be dumb if they don't really need connectivity off their network, but should be a little bit smarter if possible. If you concede that, then the next step is to decide whether it is better for a host to have: (1) a static list (n>1) of gateways to try; (2) some as yet undefined dynamic discovery mechanism for a host on a network to find the list of gateways without getting routing data; (3) hosts that listen to routing traffic and hence could potentially use the data to avoid that first bad choice of a gateway. My personal bias: Passive RIP works just fine in the XNS world as a HOST protocol as well as as a gateway protocol. It works adequately in the IP world for typical CANs and moderately complex LANs. I see no real alternative available at present.
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 00:33:12 GMT From: bob@cloud9.UUCP (Bob Toxen) To: comp.dcom.lans,comp.protocols.tcp-ip,comp.unix.wizards Subject: Re: Many things on ethernet together???
You can run just about any protocl on the same ethernet cable.
This is because anyone wanting to devise a new protocol is supposed
to obtain a protocol number from Xerox. This protocol number is
encoded in the sent packet. Receivers are expected to recognize only
the protocols they are prepared to deal with. This is why this works.
--
Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob
Stratus Computer, Marlboro, MA
Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 00:51:06 GMT From: RMRichardson.PA@Xerox.COM (Rich) To: comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
From: clyde!watmath!egisin@bellcore.com (Eric Gisin) > One thing no-one has mentioned yet is the case where the ethernet type is > a valid 802.3 packet length. I think Xerox PUP falls in to this catagory > (what's PUP anyway?). PUP -- PARC Universal Packet PARC -- Palo Alto Research Center (Xerox) It means you can't talk PUP to hosts that act that way. One way around this is to change the PUP type numbers to outside the valid length range. This means all the PUP speakers on the net must all do this or you will have split the net into two types of PUP speakers who can talk to only their own type. The other is to hack the other guy (e.g., VMS) to figure out what is coming in. Rich
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 03:28:20 GMT From: cyrus@hi.unm.edu (Tait Cyrus) To: comp.protocols.tcp-ip Subject: Question about LLC
I hate to admit this, but I don't know diddly about the new 802 LLC frame
format. Is there an RFC or some document on sri-nic that describes this
format? If not, what texts contains such a description?
The reason I ask is because devices on our net use the old dst/src/type
format and now some of the newer devices are using the dst/src/len/llc
and I can't make heads or tails of what these new devices are "saying".
What is the `correct' way to refer to dst/src/type (IEEE 802.?) ?
The `correct' way to refer to dst/src/len/llc (IEEE 802.3)?
Thanks in advance.
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of Electrical & Computer Engineering
@__|_______@ | Parallel Processing Research Group (PPRG)
| | | | UNM/LANL Hypercube Project
| | hc | | Albuquerque, New Mexico 87131
| @.......|..@
| / | / e-mail:
@/_________@/ cyrus@hc.dspo.gov
-----------[000087][next][prev][last][first]----------------------------------------------------
Date: 11 May 88 03:51:40 GMT
From: slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To: comp.protocols.tcp-ip
Subject: Re: SubnettingIt looks as though 4.3BSD subnetting code doesn't store a net mask per route. There's a net mask per -interface-, but it doesn't seem to be used the way you'd hope. There's effectively just one subnet mask per net for routing purposes (I think it uses the mask set by the first interface on the net) -- that is, 4.3BSD silently assumes equal-sized subnets on a given net. If I say ifconfig ex0 128.101.1.2 netmask 255.255.255.0 ifconfig ex1 128.101.27.27 netmask 255.255.240.0 the interface route for ex1 has a destination address of "128.101.16.0" (reasonable) BUT the route is only used when sending to 128.101.16.anything. Sending to 128.101.17.anything, ..., 128.101.31.anything does not increment the interface route's usage count. 4.3's multiple subnet masks are meaningful for interfaces on different nets but not for variable-sized subnets on a single net. It'll be interesting to see whether SUN 4.0 works the same way.
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 04:19:17 GMT From: greg@vertical.oz (Greg Bond) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes:
>Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and
>AppleTalk (ethertalk?)?
Certainly is. We have one thin enet cable here running SUNs (TCP/IP)
and NetWare 2.0a concurrently. In fact, I have a PC that has a 3com
enet card talking PC-NFS (TCP) and a Gateway G-net card talking Netware
(on a separate cable!) at the same time. So if I had 2 enet cards I guess
I could do both at once on the same cable from the same PC.
--
Gregory Bond, Vertical Software, Melbourne, Australia
Internet: greg@vertical.oz.au (or greg%vertical.oz.au@uunet.uu.net)
UUCP: {uunet,pyramid,mnetor,ukc,ucb-vision}!munnari!vertical.oz!greg
ACSnet: greg@vertical.oz
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 04:28:59 GMT From: barmar@think.COM (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Honeywell and DG
In article <8805091745.AA24461@ACC-SB-UNIX.ARPA> chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) writes: >Good morning all! > I am going to be running Honeywell and Data General systems on a >LAN soon and have been told by a customer that they have TCP/IP implement- >ations running on them. I don't know about DG, but I know that Honeywell Bull has several completely unrelated operating systems, running on almost as many different hardware architectures: GCOS-8, Multics, GCOS-6, and HVS1 to name a few (there's another I know of, but can't think of the name). Which one are you talking about? Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 04:29:15 GMT From: hedrick@athos.rutgers.edu (Charles Hedrick) To: comp.protocols.tcp-ip, chris@mimsy.umd.edu Subject: Re: A new record?
In article <8805062353.AA23117@mimsy.umd.edu> chris@MIMSY.UMD.EDU (Chris Torek) writes: >PING okeeffe.berkeley.edu (128.32.130.3): 56 data bytes >64 bytes from 128.32.130.3: icmp_seq=11. time=253239. ms >64 bytes from 128.32.130.3: icmp_seq=294. time=1070. ms > >So where *was* that packet for four minutes and 13 seconds? Presumably in various gateway queues. However you might also check your ping to make sure it handles timing correctly when lots of packets are being dropped. One could imagine a bug that would cause it to report a time for the wrong one. This has happened to TCP implementations, as I'm sure you know.
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: Wed, 11 May 88 09:46:05 EDT From: "Drew M. Powles" <dpowles@ccd.bbn.com> To: tcp-ip@sri-nic.arpa Cc: dpowles@ccd.bbn.com Subject: Who's got the time?
Can someone please tell me which protocol is the most widely accepted for synchronizing Network Time? What work is being done in this area? What do most vendors implement? Is it RFC 958? Is there a later version? Thanks in advance for any and all information. Drew Powles BBN Communications dpowles@bbn.com
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 06:24:00 GMT From: ANDREW@SASK.BITNET (Derek Andrew) To: comp.protocols.tcp-ip Subject: RE: Re: Many things on ethernet together???
We run many different protocols over the same Ethernet network. We have
encountered one problem which is currently under study.
We had these two 3COM labs for our students. Each lab has a file server. When
both labs were added to the campus network, the servers would both compete for
control over the workstations. That is, machines in one lab would try to log
into the server in the other lab.
The moral of the story is that it is not multiple protocols that will kill you,
but rather networking companies like 3COM with limited vision as to the
environments in which their products will be used.
Note that we run XNS in the 3COM labs, not TCP/IP.
Derek Andrew, Manager of Computer, Networking and Technical Services
University of Saskatchewan
andrew@sask on bitnet
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 09:52:18 GMT From: whna@cgcha.uucp (Heinz Naef) To: comp.protocols.tcp-ip,comp.protocols.ibm,comp.sources.wanted,eunet.general Subject: TCP/IP-to-SNA File Transfer Gateway
We are planning to implement a TCP/IP-to-SNA file transfer gateway to be used
as a central service to provide file transfer capabilities between our TCP/IP
network and some IBM MVS mainframes hanging off an SNA network.
Our evaluation resulted in a concept based on an application level gateway,
where the application is the most commonly used file transfer mechanism at
each side of the gateway:
- At the TCP/IP side, it is, of course, the File Transfer Protocol (FTP).
- At the SNA side, we are thinking of an implementation based on the
Enhanced Connectivity Facility (ECF) File Copy function.
As a first step, we are planning to implement the requester (client)
function of the IBM 3270 PC File Transfer Program.
Please remember the following requirements:
- The service only needs to ASYMMETRIC, where the IBM SNA side plays the
passive role.
- The service *has to* be INTERACTIVE because of security systems at the
IBM hosts.
- Development of software for the IBM hosts *must be* avoided. Only the gateway
-- which could be an IBM -- can incorporate new software.
With the proposed solutions, development of server entities for the IBM hosts
can be avoided, since there are IBM program products available for both
major operating systems, MVS and VM. Furthermore, possible requirements for
a batch file transfer capability can be met by adding the Batch File Transfer
Program (BFTP) - upon its availability - to the TCP/IP side of the gateway.
Did anyone attempt or even complete an implementation of such a gateway?
Please reply by mail, I will summarize your comments within a month or so.
Thanks in advance, and best regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1032.5.62, P.O.Box, CH-4002 Basel
uucp: whna@cgch.uucp - bitnet: whna%cgch.uucp@cernvax.bitnet
phone: (+41) 61 37 26 75
fax: (+41) 61 36 43 54 (Attn: H.Naef, R-1032.5.62)
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 12:29:07 GMT From: mo@maximo.UUCP (Mike O'Dell) To: comp.protocols.tcp-ip Subject: Comer's book
Price correction: $36.00 At least, that's what I paid for it at Jim Joyce's UNIX Bookstore. For another $6 you get it UPS Blue. -Mike
-----------[000095][next][prev][last][first]----------------------------------------------------
Date: 11 May 88 13:46:05 GMT
From: dpowles@CCD.BBN.COM ("Drew M. Powles")
To: comp.protocols.tcp-ip
Subject: Who's got the time?Can someone please tell me which protocol is the most widely accepted for synchronizing Network Time? What work is being done in this area? What do most vendors implement? Is it RFC 958? Is there a later version? Thanks in advance for any and all information. Drew Powles BBN Communications dpowles@bbn.com
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 14:26:42 GMT From: narten@PURDUE.EDU (Thomas Narten) To: comp.protocols.tcp-ip Subject: Re: Info on TCP/IP book wanted
Typos and comments concerning Doug Comer's TCP/IP book can be sent to:
tcp-typos@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!tcp-typos
This is not a mail list, so please do not ask to join; it serves as a
collection point for funnelling comments back to the author.
Sorry, no points given for noting the mistake on the front cover.
Thomas Narten
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 17:08:22 GMT From: stewarta@sco.COM (Stewart I. Alpert) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Many things on ethernet together???
In article <2962@ea.ecn.purdue.edu> mckay@ea.ecn.purdue.edu.UUCP (Dwight D Mckay) writes: > >While we're on the topic: > >Is it possible to have Novell NetWare on the same wire with TCP/IP, XNS and >AppleTalk (ethertalk?)? > Yes
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 17:41:22 GMT From: bruce@ssc-vax.UUCP (Bruce Stock) To: comp.protocols.tcp-ip Subject: 802 (.2).3 TCP/IP
Does anyone have any wisdom to share regarding the ability of TCP/IP versions based on Ethernet 2 frame formats to communicate with 802 (.2).3 based versions ( on the same network)? I just got a flyer for the Wollongong WIN/H3000 software (FTP, Telnet, SMTP) for the HP 3000 series of computers. This package uses the underlying 802 (.2).3 frame formats of HP's TCP/IP implementation for its lower layers. Most ( all?) other TCP implementations seem to use the Ethernet 2 frame formats and would probably not communicate with this package. Any experience to relate? It would seem that HP's TCP/IP implementation is grossly out of step with prevailing practice in the TCP arena. Are there any reasons to choose it, based on either short term or long term considerations? Bruce E. Stock Boeing Aerospace uw-beaver!ssc-vax!bruce
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 11 May 88 21:17:02 GMT From: VAF@SCORE.STANFORD.EDU (Vince Fuller) To: comp.protocols.tcp-ip Subject: Password transmission and encryption query
Recently, some people here have begun to grumble about the insecurities of having user passwords transmitted in the clear during TELNET sessions, FTP transfers, etc. I was wondering what solutions other places have devised to deal with this problem. I'd appreciate any information that TCP-IP readers have and any pointers to more information. Vince Fuller, Stan