The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1985)
DOCUMENT: TCP-IP Distribution List for October 1985 (126 messages, 44348 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Oct-85 14:31:00 EDT
From:      stanonik@NPRDC.ARPA (Ron Stanonik)
To:        fa.tcp-ip
Subject:   4.2BSD tftp doesn't retransmit acks

Description:
	A RRQ on receiving a duplicate data packet doesn't retransmit
	the last ack.
Repeat-By:
	This would happen intermittently between our vax and a pc,
	but the problem can be reproduced by hacking tftpd.c to
	not advance its block count and then tftp'ing to yourself.
Fix:
	Move the retransmit code into the inner loop in recvfile().
	This actually causes tftp to retransmit on receiving anything
	but the next expected packet or an error packet.  I believe
	that's in keeping with RFC783, but at any rate it makes tftp
	"generous in what it accepts".
	
	We haven't really observed the corresponding WRQ problem with
	duplicate acks, but the logic is the same, so we fixed(?) it too.

	Oh, the diff will probably only make sense if you've already
	installed the fixes from mogul@gregorio and satz@joyce.

Ron Stanonik
stanonik@nprdc.arpa

RCS file: RCS/tftp.c,v
retrieving revision 1.3
diff -c -r1.3 tftp.c
*** /tmp/,RCSt1001512	Tue Oct  1 09:43:20 1985
--- tftp.c	Tue Oct  1 09:43:00 1985
***************
*** 73,85
  		}
  		timeout = 0;
  		(void) setjmp(timeoutbuf);
- 		if (trace)
- 			tpacket("sent", stp, size + 4);
- 		n = sendto(f, sbuf, size + 4, 0, (caddr_t)&sin, sizeof (sin));
- 		if (n != size + 4) {
- 			perror("tftp: sendto");
- 			goto abort;
- 		}
  		do {
  			alarm(rexmtval);
  			do {

--- 73,78 -----
  		}
  		timeout = 0;
  		(void) setjmp(timeoutbuf);
  		do {
  			if (trace)
  				tpacket("sent", stp, size + 4);
***************
*** 81,86
  			goto abort;
  		}
  		do {
  			alarm(rexmtval);
  			do {
  				fromlen = sizeof (from);

--- 74,86 -----
  		timeout = 0;
  		(void) setjmp(timeoutbuf);
  		do {
+ 			if (trace)
+ 				tpacket("sent", stp, size + 4);
+ 			n = sendto(f, sbuf, size + 4, 0, (caddr_t)&sin, sizeof (sin));
+ 			if (n != size + 4) {
+ 				perror("tftp: sendto");
+ 				goto abort;
+ 			}
  			alarm(rexmtval);
  			do {
  				fromlen = sizeof (from);
***************
*** 144,157
  		}
  		timeout = 0;
  		(void) setjmp(timeoutbuf);
- 		if (trace)
- 			tpacket("sent", stp, size);
- 		if (sendto(f, sbuf, size, 0, (caddr_t)&sin,
- 		    sizeof (sin)) != size) {
- 			alarm(0);
- 			perror("tftp: sendto");
- 			goto abort;
- 		}
  		do {
  			alarm(rexmtval);
  			do

--- 144,149 -----
  		}
  		timeout = 0;
  		(void) setjmp(timeoutbuf);
  		do {
  			if (trace)
  				tpacket("sent", stp, size);
***************
*** 153,158
  			goto abort;
  		}
  		do {
  			alarm(rexmtval);
  			do
  				n = recvfrom(f, rbuf, sizeof (rbuf), 0,

--- 145,158 -----
  		timeout = 0;
  		(void) setjmp(timeoutbuf);
  		do {
+ 			if (trace)
+ 				tpacket("sent", stp, size);
+ 			if (sendto(f, sbuf, size, 0, (caddr_t)&sin,
+ 			    sizeof (sin)) != size) {
+ 				alarm(0);
+ 				perror("tftp: sendto");
+ 				goto abort;
+ 			}
  			alarm(rexmtval);
  			do
  				n = recvfrom(f, rbuf, sizeof (rbuf), 0,

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Oct-85 15:31:39 EDT
From:      Myer@DEWEY.UDEL.EDU
To:        fa.tcp-ip
Subject:   Papers on tcp/ip

I am doing a study of tcp/ip. I would like to have a bibliography on papers
that have anything to do with tcp or ip.

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Oct-85 20:31:00 EDT
From:      CERF@USC-ISI.ARPA
To:        fa.tcp-ip
Subject:   Re:  Papers on tcp/ip

Jon Postel probably has the best bibliography - also check with the NIC.

Vint

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 1985 19:12:46 PDT
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   TCP Testing

Hi:

Back in the olden days when TCP's were first being tested by those
"old network boys" of legend, there were a couple of events called
"TCP Bakeoff"s.  The first bakeoff was held at ISI with all the
implementers of different TCP in the same room (well actually a set of
offices on a common hall) -- all six of them.  The date of this event
escapes me just now.  The second bakeoff was held over the network in
the spring of 1980.  I've dug up the rules used in that bakeoff and
appended them below.  They may or may not be helpful in suggesting
some testing for current implementations of TCP.

--jon.




< INC-PROJECT, BAKEOFF.NLS.2, >, 8-Apr-80 22:12 JBP ;;;;


                           TCP & IP BAKE OFF
                           --- - -- ---- ---

This is the procedure for the distributed TCP & IP Bake Off.  Each
implementer of a TCP & IP is to perform the following tests and to
report the results.  You are on the honor system.  I will try to figure
out some way of presenting the results.  The testing period is from now
through 27 April.  All results must be reported via sndmsg to LINDA@ISIE
by midnight (Pacific time) on Monday 28 April.

Scoring

   Note that many of the following apply for each distinct TCP contacted
      (for example, in the Middleweight Division there is a possibility
      of 20 points for each other TCP in the Bake Off).

   Note Bene: Checksums must be enforced.  No points will be awarded if
      the checksum test is disabled.

   Featherweight Division

      1  points for talking to yourself (opening a connection)

      1  points for saying something to yourself (sending and receiving
         data)

      1  points for gracefully ending the conversation (closing the
         connection without crashing)

      2  point for a repeating the above without reinitializing the TCP

      5  points for a complete conversation via the testing gateway

   Middleweight Division

      2  points for talking to someone else (opening a connection)

      2  points for saying something to someone else (sending and
         receiving data)

      2  points for gracefully ending the conversation (closing the
         connection without crashing)

      4  points for a repeating the above without reinitializing the TCP

      10 points for a complete conversation via the testing gateway

   Heavyweight Division

      10 points for being able to talk to more than one other TCP at the
         same time (multiple connections open and active simultaneously
         with different TCPs)

      10 points for correctly handling urgent data

      10 points for correctly handling rubber baby buffer bumpers in
         both directions (End of Letter sequence number adjustments)

      10 points for correctly handling sequence number wraparound

      10 points for correctly being able to process a "Kamikaze" packet
         (AKA Nastygram, Christmas tree packet, lamp test segment, et
         al.) That is, correctly handle a segment with the maximum
         combination of features at once, e.g., a SYN URG EOL FIN
         segment with options and data.

      30 points for KOing your opponent with legal blows (That is,
         operate a connection until one  TCP or the other crashes, the
         surviving TCP has KOed the other.  Legal blows are segments
         that meet the requirements of the specification.)

      20 points for KOing your opponent with dirty blows (Dirty blows
         are segments that do not meet the requirements of the
         specification.)

      10 points for showing your opponents checksum test is faulty or
         disabled

   Host & Gateway IP Division

      25 points for doing fragmentation and reassembly

      15 points for doing source route option

      10 points for doing return route option

      10 points for using quench messages

      10 points for using routing advice messages

      5  points for doing something with the type of service

      5  points for doing something with the security option

      5  points for doing something with the timestamp option

      5  points for showing that a gateway forwards datagrams without
         decreasing the time to live

      5  points for showing that a gateway forwards datagrams with the
         time to live equal zero

      10 points for showing that a gateway or hosts checksum test is
         faulty or disabled

   Bonus Points

      10 point for the best excuse

      20 points for the fewest excuses

      30 points for the longest conversation

      40 points for the most simultaneous connections

      50 points for the most simultaneous connections with distinct TCPs

The following tests have been identified for checking the capabilities
of a TCP implementation.  These may be useful in attempting to KO an
opponent.

   1.  Single connection.  Open & close a single connection many times.

   2.  Multi connections.  Open several connections simultaneously.  Two
       connections to the same socket (i.e., a-b and a-c) check proper
       separation of data.

   3.  Half Open Connection.  Open a connection, crash local TCP and
       attempt to open same connection again.

   4.  Piggy-back Loop.  Open connections via Telnet.

      user telnet--->TCP--->TCP--->server telnet
                                       !
                                       V
      server telnet<---TCP<---TCP<---user telnet
          !
          V
      user telnet--->...

   5.  Maximum connections.  Open connections between a pair of TCP
       until refused or worse.

   6.  Refused connection.  Open a connection to a non-accepting socket,
       does it get refused?

   7.  Zero Window.  Try to send data to a TCP that is presenting a zero
       window.

   8.  Fire Hose.  Make many connections to data source ports (e.g.,
       TTYTST at TENEX), or connections to a data sink and send as fast
       as you can.

   9.  Urgent Test.  Try to send data to a user program that only
       receives data when in urgent mode.

   10. Kamikazi Segment.  Send and Receive NASTYGRAMS.  A NASTYGRAM is a
       segment with SYN, EOL, URG, and FIN on and carrying one octet of
       data.

   11. Sequence Wraparound.  Test proper functioning when sequence
       numbers (a) pass 2**31 (i.e., go from plus to "minus") and (b)
       pass 2**32 (i.e., go from 2**32-1 to 0).

   12. Buffer size.  With buffer size not equal to one, send data in
       letters of various sizes, use urgent occasionally.

   13. Send a NASTYGRAM into a half open connection when the sequence
       number is about to wrap around.

*** end ***
-------
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Oct-85 22:12:46 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        fa.tcp-ip
Subject:   TCP Testing


Hi:

Back in the olden days when TCP's were first being tested by those
"old network boys" of legend, there were a couple of events called
"TCP Bakeoff"s.  The first bakeoff was held at ISI with all the
implementers of different TCP in the same room (well actually a set of
offices on a common hall) -- all six of them.  The date of this event
escapes me just now.  The second bakeoff was held over the network in
the spring of 1980.  I've dug up the rules used in that bakeoff and
appended them below.  They may or may not be helpful in suggesting
some testing for current implementations of TCP.

--jon.




< INC-PROJECT, BAKEOFF.NLS.2, >, 8-Apr-80 22:12 JBP ;;;;


                           TCP & IP BAKE OFF
                           --- - -- ---- ---

This is the procedure for the distributed TCP & IP Bake Off.  Each
implementer of a TCP & IP is to perform the following tests and to
report the results.  You are on the honor system.  I will try to figure
out some way of presenting the results.  The testing period is from now
through 27 April.  All results must be reported via sndmsg to LINDA@ISIE
by midnight (Pacific time) on Monday 28 April.

Scoring

   Note that many of the following apply for each distinct TCP contacted
      (for example, in the Middleweight Division there is a possibility
      of 20 points for each other TCP in the Bake Off).

   Note Bene: Checksums must be enforced.  No points will be awarded if
      the checksum test is disabled.

   Featherweight Division

      1  points for talking to yourself (opening a connection)

      1  points for saying something to yourself (sending and receiving
         data)

      1  points for gracefully ending the conversation (closing the
         connection without crashing)

      2  point for a repeating the above without reinitializing the TCP

      5  points for a complete conversation via the testing gateway

   Middleweight Division

      2  points for talking to someone else (opening a connection)

      2  points for saying something to someone else (sending and
         receiving data)

      2  points for gracefully ending the conversation (closing the
         connection without crashing)

      4  points for a repeating the above without reinitializing the TCP

      10 points for a complete conversation via the testing gateway

   Heavyweight Division

      10 points for being able to talk to more than one other TCP at the
         same time (multiple connections open and active simultaneously
         with different TCPs)

      10 points for correctly handling urgent data

      10 points for correctly handling rubber baby buffer bumpers in
         both directions (End of Letter sequence number adjustments)

      10 points for correctly handling sequence number wraparound

      10 points for correctly being able to process a "Kamikaze" packet
         (AKA Nastygram, Christmas tree packet, lamp test segment, et
         al.) That is, correctly handle a segment with the maximum
         combination of features at once, e.g., a SYN URG EOL FIN
         segment with options and data.

      30 points for KOing your opponent with legal blows (That is,
         operate a connection until one  TCP or the other crashes, the
         surviving TCP has KOed the other.  Legal blows are segments
         that meet the requirements of the specification.)

      20 points for KOing your opponent with dirty blows (Dirty blows
         are segments that do not meet the requirements of the
         specification.)

      10 points for showing your opponents checksum test is faulty or
         disabled

   Host & Gateway IP Division

      25 points for doing fragmentation and reassembly

      15 points for doing source route option

      10 points for doing return route option

      10 points for using quench messages

      10 points for using routing advice messages

      5  points for doing something with the type of service

      5  points for doing something with the security option

      5  points for doing something with the timestamp option

      5  points for showing that a gateway forwards datagrams without
         decreasing the time to live

      5  points for showing that a gateway forwards datagrams with the
         time to live equal zero

      10 points for showing that a gateway or hosts checksum test is
         faulty or disabled

   Bonus Points

      10 point for the best excuse

      20 points for the fewest excuses

      30 points for the longest conversation

      40 points for the most simultaneous connections

      50 points for the most simultaneous connections with distinct TCPs

The following tests have been identified for checking the capabilities
of a TCP implementation.  These may be useful in attempting to KO an
opponent.

   1.  Single connection.  Open & close a single connection many times.

   2.  Multi connections.  Open several connections simultaneously.  Two
       connections to the same socket (i.e., a-b and a-c) check proper
       separation of data.

   3.  Half Open Connection.  Open a connection, crash local TCP and
       attempt to open same connection again.

   4.  Piggy-back Loop.  Open connections via Telnet.

      user telnet--->TCP--->TCP--->server telnet
                                       !
                                       V
      server telnet<---TCP<---TCP<---user telnet
          !
          V
      user telnet--->...

   5.  Maximum connections.  Open connections between a pair of TCP
       until refused or worse.

   6.  Refused connection.  Open a connection to a non-accepting socket,
       does it get refused?

   7.  Zero Window.  Try to send data to a TCP that is presenting a zero
       window.

   8.  Fire Hose.  Make many connections to data source ports (e.g.,
       TTYTST at TENEX), or connections to a data sink and send as fast
       as you can.

   9.  Urgent Test.  Try to send data to a user program that only
       receives data when in urgent mode.

   10. Kamikazi Segment.  Send and Receive NASTYGRAMS.  A NASTYGRAM is a
       segment with SYN, EOL, URG, and FIN on and carrying one octet of
       data.

   11. Sequence Wraparound.  Test proper functioning when sequence
       numbers (a) pass 2**31 (i.e., go from plus to "minus") and (b)
       pass 2**32 (i.e., go from 2**32-1 to 0).

   12. Buffer size.  With buffer size not equal to one, send data in
       letters of various sizes, use urgent occasionally.

   13. Send a NASTYGRAM into a half open connection when the sequence
       number is about to wrap around.

*** end ***
-------

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Oct-85 01:47:21 EDT
From:      @CSNET-RELAY.ARPA,@case.CSNET:CHANDNA@cwru-20 (Asheem)
To:        fa.tcp-ip
Subject:   Intel 310 Networking


Hi,

I am working on a year long LAN project that utilizes the Intel 310
OEM Microcomputer system.

I was wondering if anyone on the net has used the Intel 310 System
for  LAN applications. I'd appreciate receiving any comments, advice, 
misc. info. from anyone who has worked with any of the following Intel
products :

1. the iSBC 186/51 COMMputer Multibus board (Ethernet)
2. the iSBC 550/550 Kit Multibus board (Ethernet)
3. iNA 960 Network Software
4. iRMX Net
5. OpenNET .
6. the new iSXM 554 Multibus board (MAP - Token Passing Bus)

I also have some specific questions relating to the above, but it's 
probably more appropriate to carry on a detailed discussion individually
between interested parties.

Thanks in advance for your help.

Asheem Chandna	
EE Senior
Case Western Reserve U.


ARPANET : chandna%cwr20b@cu20b.arpa 
       OR chandna%cwru-20b%cwruecmp@csnet-relay.arpa

BITNET  : chandna%cwr20b@cu20b.bitnet

CSNET   : chandna%cwru-20b%case.csnet
-------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu 3 Oct 85 01:47:21-EDT
From:      Asheem <@CSNET-RELAY.ARPA,@case.CSNET:CHANDNA@cwru-20>
To:        tcp-ip@sri-nic.ARPA
Subject:   Intel 310 Networking

Hi,

I am working on a year long LAN project that utilizes the Intel 310
OEM Microcomputer system.

I was wondering if anyone on the net has used the Intel 310 System
for  LAN applications. I'd appreciate receiving any comments, advice, 
misc. info. from anyone who has worked with any of the following Intel
products :

1. the iSBC 186/51 COMMputer Multibus board (Ethernet)
2. the iSBC 550/550 Kit Multibus board (Ethernet)
3. iNA 960 Network Software
4. iRMX Net
5. OpenNET .
6. the new iSXM 554 Multibus board (MAP - Token Passing Bus)

I also have some specific questions relating to the above, but it's 
probably more appropriate to carry on a detailed discussion individually
between interested parties.

Thanks in advance for your help.

Asheem Chandna	
EE Senior
Case Western Reserve U.


ARPANET : chandna%cwr20b@cu20b.arpa 
       OR chandna%cwru-20b%cwruecmp@csnet-relay.arpa

BITNET  : chandna%cwr20b@cu20b.bitnet

CSNET   : chandna%cwru-20b%case.csnet
-------

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Oct-85 13:32:54 EDT
From:      wjc@LL-VLSI.ARPA (Bill Chiarchiaro)
To:        fa.tcp-ip
Subject:   System V -- Help!


I have unfortunately been saddled with three machines running UNIX System V.
Does anyone know of any successful implementation of TCP/IP support for this
system?

Please respond to wjc@ll-vlsi as I am not on this mailing list; if the
list's administrator is listening, I'd like to be added.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Oct-85 16:27:38 EDT
From:      Bhobe@DEWEY.UDEL.EDU
To:        fa.tcp-ip
Subject:   lan internetworking

Hello
      I have to present a paper on LAN INTERNETWORKING in the class.As of 
today I have been able to locate only afew good ones like the one by Dr.
Dalal on 'Why 48 bits address for Ethernet' and another one on Campusnet.
Can somebody let me know a few more at their earliest.Awaiting your reply.
                                           shailesh

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Oct-85 16:47:59 EDT
From:      WUTS@USC-ECLC.ARPA (Maurice J. Wuts)
To:        fa.tcp-ip
Subject:   Time servers

I know there are Unix time pollers / servers out there.  Is there anyone
with a Tops20 version?  
				Maurice Wuts
-------

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5-Oct-85 22:45:40 EDT
From:      medin%orion@AMES.ARPA (Milo Medin, NASA ARC Code EDN  Advanced Systems G)
To:        fa.tcp-ip
Subject:   IBM TCP/IP product


Folks, my division is considering buying the IBM TCP/IP package which
was developed by UWISC for IBM.  For various reasons, we'd like an
ethernet connection to our 4381 machine, and this looks like a 
pretty good way, especially with the peripheral programs like
tn3270 and the rest which do block mode emulation.  If anybody out
there has any experience with this product, both positive and negative,
I'd appreciate a note with your comments.  I know spartacus has a similar
product, buts I don't know of any running on the internet, and I'm not
sure about block mode support.

					Thanks,
					  Milo

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 1985 08:36 PST
From:      Gary Krall <GARY@ACC.ARPA>
To:        TCP-IP@SRI-NIC
Cc:        MEDIN%ORION@AMES,FALSETTI%ORION@AMES
Subject:   IBM Ethernet attach

ACC has recently delivered to Rutgers University (re:  Messrs. Hendrick
and Marantz) a IBM to Ethernet attachment.  Functionally it is the same
basic hardware as the 370/DDN interface (ie.  Block Mux interface to the
channel with 68000 micro's running in a multi-processing environment)
except that it attaches directly to the LAN.  For host processors
running MVS it uses the UCLA developed code set (re:  Bob Braden) and
has yet to be tested for VM (which we believe should work based on
the McKay article in Signal).

The Rutgers system is a beta site and ACC will keep you aprised
as to the developments.

Let me know if you require additional information.

Regards,

Gary Krall
------
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 85 09:07:00 PDT
From:      HATFIELD, WILLIAM T <hatfield@ge-crd>
To:        tcp-ip <tcp-ip@sri-nic>
I'd like to get on the mailing list to receive information dealing
with work going on in the area of TCP-IP and Clients.
------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Oct-85 12:36:00 EDT
From:      GARY@ACC.ARPA (Gary Krall)
To:        fa.tcp-ip
Subject:   IBM Ethernet attach


ACC has recently delivered to Rutgers University (re:  Messrs. Hendrick
and Marantz) a IBM to Ethernet attachment.  Functionally it is the same
basic hardware as the 370/DDN interface (ie.  Block Mux interface to the
channel with 68000 micro's running in a multi-processing environment)
except that it attaches directly to the LAN.  For host processors
running MVS it uses the UCLA developed code set (re:  Bob Braden) and
has yet to be tested for VM (which we believe should work based on
the McKay article in Signal).

The Rutgers system is a beta site and ACC will keep you aprised
as to the developments.

Let me know if you require additional information.

Regards,

Gary Krall
------

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Oct-85 13:05:02 EDT
From:      minshall@UCBOPAL.CC (Greg Minshall)
To:        fa.tcp-ip
Subject:   Wisconsin code

Hi.  We've been running the Wisconsin code for a couple of years.  Installing
it (especially for the DACU) is somewhat of a pain, but actually it runs
fairly well.  It is not clear to me whether you are better off trying to
get the code from U of Wisconsin or from IBM.  Each piece of code has things
that the other does not have.

In terms of performance (which you didn't ask about, but still...), a single
Vax <-> 370 connection can run from 12 to 20 kBytes/second.  This isn't too
swift, given that a Vax <-> Vax connection can run about 50-80 kBytes/second.
However, in the Vax <-> 370 case, the numbers appear to be additive; thus
two Vax <-> 370 connections (two Vaxen, one 370 = 3081) seems to run about
twice as fast as one, three connections run three times as fast, etc.

The Spartacus people DO support 3270 emulation.  They do the protocol
conversion in the 370, which allows you to run from, say, an IBM PC or
TOPS20, or whatever.  This is a plus.  The downsides are two:  1) every
character is echoed from the 370; and 2) the 370 needs to know "/etc/termcap"
information about every terminal that will connect to it.  (please note:
I've never used the Spartacus boxes or software, so I am commenting
based on what I remember from reading and discussing.

The Spartacus people do have tn3270, and may be trying to support that
interface as well.

Hope this helps.

Greg Minshall

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Oct-85 13:06:37 EDT
From:      medin%orion@AMES.ARPA (Milo Medin, NASA ARC Code EDN  Advanced Systems G)
To:        fa.tcp-ip
Subject:   Re: IBM Ethernet attach


I'd heard about the ACC product, and it looks to be pretty fast, but I'm
concerned about the software support, especially re: block mode emulation
of remote TTY's.  I believe the remote system should be the guy to do the
block mode interpretation, not the IBM machine, since the remote machine
certainly should know the screen characteristics of the terminal...

						Milo

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Oct-85 14:54:31 EDT
From:      poggio@SRI-TSC.ARPA (Andy Poggio)
To:        fa.tcp-ip
Subject:   ACM Sigcomm Announcement


			     CALL FOR PAPERS

			ACM SIGCOMM '86 SYMPOSIUM
		 Communications Architectures and Protocols

			      Stowe, Vermont
			     August 5-7, 1986


The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.  Authors are invited to
submit full papers concerned with both theory and practice.  The areas
of interest for the symposium include, but are not limited to the
following: 

Computer network architectures and algorithms
Local area networks
Computer-based multimedia communications
Network interconnection
Packet radio networks
Satellite and wideband networks
Computer networking standards
Distributed operating systems
Protocol specification, verification, and analysis
Applications of computer networks (education, office automation,
banking, factory of the future)

Papers should be about 20 double-spaced pages long and should have an
abstract of 100-150 words.  All submitted papers will be reviewed and
will be judged with respect to their quality and relevance.  Authors
of selected papers will be expected to sign an ACM copyright release
form.  The Proceedings will be distributed at the symposium and
published as a special issue of SIGCOMM's Computer Communication
Review.  Since the proceedings of this conference will be widely
disseminated, publication is likely to inhibit republications in ACM's
refereed publications.  However, a few of the submitted papers will be
selected for publication in the ACM Transactions on Computer Systems.

Submit 5 copies of each paper by February 15, 1986 to the co-program
chairman:  Dr. Jose J. Garcia Luna, SRI International, 333
Ravenswood Avenue, Menlo Park, CA  94025, USA.

			 IMPORTANT DATES

Deadline for paper submission         February 15, l986
Notification of acceptance            March 31, 1986
Camera-ready manuscripts due          May 15, 1986

General Chairman:     Walter Kosinsky, Central China University of
		      Science and Technology
Co-program Chairmen:  Jose J. Garcia Luna and Franklin F. Kuo,
		      SRI International, California

Program Committee Members:

David Cheriton, Stanford University,    Simon Lam, Univ. of Texas at Austin,
USA                                     USA

Wesley Chu, UCLA, USA                   Lawrence Landweber, Univ. of
					Wisconsin, USA

Richard desJardins, DARPA/IPTO, USA     Najah Naffah, Bull Transac, France

Michael Ferguson,                       Raphael Rom, SRI International, USA
INRS Telecommunications, Canada

Juan Garduno,                           Harry Rudin, IBM Research Lab,
Instituto Politecnico Nacional, Mexico  Switzerland

Jean-Louis Grange, INRIA, France        Nachum Shacham, SRI International, USA

Peter Kirstein, University College      Carl Sunshine, System Development
London, UK                              Corporation, USA

Hisashi Kobayashi, IBM Japan, Ltd.,     Fouad Tobagi, Stanford Univerity, USA
Japan

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 1985 15:26:24 PDT
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LYNCH@USC-ISIB.ARPA
Subject:   Excelan
I am interested in the suitability of Excelan products (hardware and
software) for internet purposes.  I recall seeing some bad press on
their Ethernet board for the Masscomp machine.  Does anyone else
have any other data, good or bad?  Just reply to me; no use filling
the disks of america needlessly.
Thanks,
Dan
-------
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Oct-85 12:53:23 EDT
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        fa.tcp-ip
Subject:   IBM block mode tty emulation


    "I believe the remote system should be the guy to do the
    block mode interpretation" - Milo Medin

Milo:

My modifications to 4.2bsd telnet to support 3278 emulation do exactly
that.  When, during option negotiation, the client is asked for its
terminal type, it assumes the server host must be a 370 and replies
that it is an IBM-3278-x, where 'x' depends on the screen size
determined from termcap.  After that it uses the curses library plus
a file containing terminal-specific key bindings to perform 3270
emulation.

My code has only been tested against the WISCNET implementation, though
after a conversation with Lou Rivas I believe it should work with the
UCLA code modulo some tweaking of the option negotiations.

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX

Domain:	milazzo@rice.EDU
ARPA:	milazzo@rice.ARPA
BITNET:	milazzo@rice-net, milazzo@ricecsvm
UUCP:	{cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Oct-85 18:26:24 EDT
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        fa.tcp-ip
Subject:   Excelan

I am interested in the suitability of Excelan products (hardware and
software) for internet purposes.  I recall seeing some bad press on
their Ethernet board for the Masscomp machine.  Does anyone else
have any other data, good or bad?  Just reply to me; no use filling
the disks of america needlessly.
Thanks,
Dan
-------

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Oct-85 09:11:45 EDT
From:      delp@HUEY.UDEL.EDU (Gary Delp)
To:        fa.tcp-ip
Subject:   Re: Excelan

dan,
	Can you let me know what your responses are?
thanks,
gary

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      09 Oct 85 09:11:45 EDT (Wed)
From:      Gary Delp <delp@huey.udel.EDU>
To:        Dan Lynch <LYNCH@usc-isib.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Excelan
dan,
	Can you let me know what your responses are?
thanks,
gary
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Oct 85 12:12:38 edt
From:      swanson@EDN-VAX.ARPA (John Swanson)
To:        tcp-ip@sri-nic.ARPA
Could the author of the TCP bakeoff message please forward me another
copy.  Our machines disk crashed and when they resored the directories
I had lost that message and I would like to have it.  
Thanks to whomever!
J. Swanson
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Oct-85 17:42:26 EDT
From:      HAL@SRI-NIC.ARPA (Hal Huntley)
To:        fa.tcp-ip
Subject:   TCP for IBM AT?

Anyone know of a TCP-IP implementation for an IBM AT running XENIX 3.0?  
Someone told me the rumor that Microsoft has it internally, but they
are not saying much about it.

Hal Huntley
-------

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Oct-85 21:52:08 EDT
From:      mills@DCN6.ARPA
To:        fa.tcp-ip
Subject:   NTP and timetelling issues

Folks,

Experimental servers for the Network Time Protocol (NTP) announced in RFC958
are running now on several fuzzballs, including DCN1, DCN6, FORD1 and UMICH1.
These are servers only and do not implement the distributed algorithms
suggested in RFC958. The servers are implemented as a user process, so are not
as accurate as ICMP Timestamp messages. Our experience indicates accuracies in
the order of 50-ms relative to NBS time should be expected as the NTP reply
timestamp leaves one of these hosts.

Two new hosts each specifically associated with a radio clock have been
activated. One of these (128.4.0.15) tracks WWVB and the other (128.4.0.14)
tracks WWV. Particular care was taken in their design to preserve the highest
accuracy of ICMP Timestamp messages. For all other protocols, including TCP
and UDP, these hosts perform only the standard echo function (RFC862).

We have made a number of changes to our fuzzballs and timetellers in order to
improve timekeeping robustness and move toward a truly distributed clock
service. In summary, we have direct access to two radio clocks (WWVB and WWV)
and indirect access to a third (GOES), all of which are available to the
local-net routing and timekeeping functions. We have arranged automatic
fallback to secondary clocks should the primary ones fail. For this prupose a
clock which has never synchronized or has either failed to respond to a poll
or has indicated loss of signal for over two minutes is considered to have
failed.

Only one radio clock will be used at any time to synchronize our local network
and its dependencies, including timestamps returned from all 128.4 hosts. In
order of preference, the WWVB clock will be chosen first. If it is down the
next choice will be the WWV clock and the last the GOES clock. If no radio
clock is up the host clock will free-run relative to the last radio-clock
update and the intrinsic drift of its crystal. The fallback procedure is
automatic and should be glitch-free, except possibly for a step offset if a
difference of over 128 milliseconds is involved.

If for some reason the host clock was never synchronized, such as when first
booted and before any radio-clock updates have occured, that host will not
respond to UDP time requests and will close TCP time requests immediately
without sending data, which is consistent with RFC868. At present there is no
provision for marking a host clock unsynchronized once it has been
synchronized; however, our experience indicates the stability of the host
clocks is such that this would be indicated only after a prolonged outage (a
matter of days) of all radio clocks, which is considered unlikely.

The intended result of all this effort is that rotten timestamps such as
recently escaped our swamp due thunderstorms and hurricanes will not recur
to destabilize the files, messages and bombs of our friends.

Dave
-------

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      11-Oct-85 21:50:16-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Cc:        mills@dcn6.arpa
Subject:   NTP and timetelling issues
Folks,

Experimental servers for the Network Time Protocol (NTP) announced in RFC958
are running now on several fuzzballs, including DCN1, DCN6, FORD1 and UMICH1.
These are servers only and do not implement the distributed algorithms
suggested in RFC958. The servers are implemented as a user process, so are not
as accurate as ICMP Timestamp messages. Our experience indicates accuracies in
the order of 50-ms relative to NBS time should be expected as the NTP reply
timestamp leaves one of these hosts.

Two new hosts each specifically associated with a radio clock have been
activated. One of these (128.4.0.15) tracks WWVB and the other (128.4.0.14)
tracks WWV. Particular care was taken in their design to preserve the highest
accuracy of ICMP Timestamp messages. For all other protocols, including TCP
and UDP, these hosts perform only the standard echo function (RFC862).

We have made a number of changes to our fuzzballs and timetellers in order to
improve timekeeping robustness and move toward a truly distributed clock
service. In summary, we have direct access to two radio clocks (WWVB and WWV)
and indirect access to a third (GOES), all of which are available to the
local-net routing and timekeeping functions. We have arranged automatic
fallback to secondary clocks should the primary ones fail. For this prupose a
clock which has never synchronized or has either failed to respond to a poll
or has indicated loss of signal for over two minutes is considered to have
failed.

Only one radio clock will be used at any time to synchronize our local network
and its dependencies, including timestamps returned from all 128.4 hosts. In
order of preference, the WWVB clock will be chosen first. If it is down the
next choice will be the WWV clock and the last the GOES clock. If no radio
clock is up the host clock will free-run relative to the last radio-clock
update and the intrinsic drift of its crystal. The fallback procedure is
automatic and should be glitch-free, except possibly for a step offset if a
difference of over 128 milliseconds is involved.

If for some reason the host clock was never synchronized, such as when first
booted and before any radio-clock updates have occured, that host will not
respond to UDP time requests and will close TCP time requests immediately
without sending data, which is consistent with RFC868. At present there is no
provision for marking a host clock unsynchronized once it has been
synchronized; however, our experience indicates the stability of the host
clocks is such that this would be indicated only after a prolonged outage (a
matter of days) of all radio clocks, which is considered unlikely.

The intended result of all this effort is that rotten timestamps such as
recently escaped our swamp due thunderstorms and hurricanes will not recur
to destabilize the files, messages and bombs of our friends.

Dave
-------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1985 10:11:33 PDT
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        Hal Huntley <HAL@SRI-NIC.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA
Subject:   Re: TCP for IBM AT?
Excelan has TCP/IP for the AT running Xenix.  You buy their Ethernet
board and software and you are on the air.  Costs about $1600 for
everything in quantity 1 lots.
Dan
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1985 14:34:48 PDT
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LYNCH@USC-ISIB.ARPA
Subject:   Excelan
I got about 10 responses on Excelan products and did some
digging myself and have the following to report.
Basically they make excellent hardware and their software has evolved 
from a shaky start to the current one where it is quite featureful 
and supports all the latest characteristics of TCP/IP.
Their basic approach is to provide a board that plugs into the backplane
((Unibus, Qbus, Multibus, VMEbus and the IBM PC)) of your machine
and drives the Ethernet from the board.  Teh board also contains
the full TCP/IP software.  The host level software makes library
calls (library software provided on a pe operating system basis)
to do the usual things (open, send/receive, close,...) thus 
freeing up the host to do other things than messing with packet
level interrupts and checksums.  There are arguments for and
against this apporach to doing networking.  I wont
detail them here.  One misfeature of the current implementation is
that since Excellan terminates the IP protocol in
the offhost processor and that offhost processor has no provision
for multiple network interfaces it cannot act as a gateway device
in an Internet environment.  

The operating systems currently supported are Xenix, Unix System V,
(for the VAX), VMS (including for the MicroVaxII), RSX-11M,PC-DOS
and some other brands of System V that are OEM related.


The real sleeper in their product line is a workstation they call
the Nutcracker.  It is a slick development/debugging/repairing
tool that sits on your Ethernet and copies all packets into its buffers 
and then depending on the various sets of filters you have established
it will take statistics of all kinds.  It is fast enought to
do tthis at full speed.  It can also inject packets for any destination
at any speed you wish and can even generate invalid packets for 
debugging purposes.  Quite a lot of work has gone into this product
and for research and development sites it looks like an invaluabe tool
at many levels of design.  The price for this complete workstation
is not low, about $50k.  You might not want to get one for home use,
but its existence in a good indication of the level of engineering talent
that exists inside the company.

The prices on their boards and host software modules are quite
reasonable and they give generous discounts for large volumes.

They are located in San Jose and can be reached at 408-434-2300.

Dan
-------
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Oct-85 13:11:33 EDT
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        fa.tcp-ip
Subject:   Re: TCP for IBM AT?

Excelan has TCP/IP for the AT running Xenix.  You buy their Ethernet
board and software and you are on the air.  Costs about $1600 for
everything in quantity 1 lots.
Dan
-------

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1985 17:43:51 PDT
From:      Dan Lynch <LYNCH@USC-ISIB.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LYNCH@USC-ISIB.ARPA
Subject:   Excelan gateway addendum

In my previous note I said that their offhost board had
no provision for anothr network interface thus
preventing it from becoming an IP gateway.  The real situation 
is that there is no existing product that performs that
way but the actual architecture of the board allows for other
I/O interfaces to be attached on the "outboard" side so one
could (with cooperation from Excelan) build such a product.
I guess they haven't seen a very large marketplace for such a product 
yet?

Dan
-------
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Oct-85 17:34:48 EDT
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        fa.tcp-ip
Subject:   Excelan

I got about 10 responses on Excelan products and did some
digging myself and have the following to report.
Basically they make excellent hardware and their software has evolved 
from a shaky start to the current one where it is quite featureful 
and supports all the latest characteristics of TCP/IP.
Their basic approach is to provide a board that plugs into the backplane
((Unibus, Qbus, Multibus, VMEbus and the IBM PC)) of your machine
and drives the Ethernet from the board.  Teh board also contains
the full TCP/IP software.  The host level software makes library
calls (library software provided on a pe operating system basis)
to do the usual things (open, send/receive, close,...) thus 
freeing up the host to do other things than messing with packet
level interrupts and checksums.  There are arguments for and
against this apporach to doing networking.  I wont
detail them here.  One misfeature of the current implementation is
that since Excellan terminates the IP protocol in
the offhost processor and that offhost processor has no provision
for multiple network interfaces it cannot act as a gateway device
in an Internet environment.  

The operating systems currently supported are Xenix, Unix System V,
(for the VAX), VMS (including for the MicroVaxII), RSX-11M,PC-DOS
and some other brands of System V that are OEM related.


The real sleeper in their product line is a workstation they call
the Nutcracker.  It is a slick development/debugging/repairing
tool that sits on your Ethernet and copies all packets into its buffers 
and then depending on the various sets of filters you have established
it will take statistics of all kinds.  It is fast enought to
do tthis at full speed.  It can also inject packets for any destination
at any speed you wish and can even generate invalid packets for 
debugging purposes.  Quite a lot of work has gone into this product
and for research and development sites it looks like an invaluabe tool
at many levels of design.  The price for this complete workstation
is not low, about $50k.  You might not want to get one for home use,
but its existence in a good indication of the level of engineering talent
that exists inside the company.

The prices on their boards and host software modules are quite
reasonable and they give generous discounts for large volumes.

They are located in San Jose and can be reached at 408-434-2300.

Dan
-------

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Oct-85 20:43:51 EDT
From:      LYNCH@USC-ISIB.ARPA (Dan Lynch)
To:        fa.tcp-ip
Subject:   Excelan gateway addendum


In my previous note I said that their offhost board had
no provision for anothr network interface thus
preventing it from becoming an IP gateway.  The real situation 
is that there is no existing product that performs that
way but the actual architecture of the board allows for other
I/O interfaces to be attached on the "outboard" side so one
could (with cooperation from Excelan) build such a product.
I guess they haven't seen a very large marketplace for such a product 
yet?

Dan
-------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Oct-85 12:45:04 EDT
From:      lwa@apollo.UUCP
To:        fa.tcp-ip
Subject:   Re: 4.2BSD tftp doesn't retransmit acks

THAT IS NOT A BUG!!

The ORIGINAL tftp spec required retransmisson of ack's, as well
as of data packets, upon receiving any old packet.  This algorithm
was shown to be faulty by Michael Greenwald at MIT.  It has the
following problem:

    Suppose host A is talking to host B.  Suppose further that host
    A's retransmit timeout is too short (a common case, since there is
    no good way to determine an initial retransmit timeout).  Now
    observe what happens:

    Host A sends packet 1

    Host A's retransmit timer goes
    off, and host A retransmits packet
    1.
                                        Host B receives packet 1, sends
                                        ack 1.
    Host A receives ack 1, sends
    packet 2. 
                                        Host B receives retransmitted packet
                                        1, retransmits ack 1.
    Host A receives retransmitted
    ack 1, retransmits packet 2.
                                        Host B receives packet 2, sends
                                        ack 2.
    Host A receives ack 2, sends
    packet 3.
                                        Host B receives retransmitted packet
                                        2, retransmits ack 2.
    Host A receives retransmitted
    ack 2, retransmits packet 3.
                .                                       .
                .                                       .
                .                                       .

Note that what has now happened is that every tftp packet is being transmitted
twice.  Furthermore, if Host A's retransmit timer goes off too early again,
every packet will be transmitted three times, and so forth.  This quickly
causes tftp performance to degrade to zero, and connections eventually time
out.

The current tftp spec avoids this problem by specifying that only data packets
are to be retransmitted in response to receipt of an old ack, and then only if
the ack is for the previously transmitted data packet.  Acks are retransmitted
ONLY when the retransmit timer expires.  I believe that this is the way the
Berkeley tftp currently (and correctly) behaves, and hence that Ron's "bug fix"
is in fact unnecessary and incorrect.

There are several other problems with the 4.2bsd tftp as distributed, including:
    1) No support for netascii mode.
    2) Relies on signals breaking through read() calls; this no longer
	   happens in 4.2 (instead the read() call is restarted after a signal).
    3) Uses the same buffer for transmit and receive, thereby clobbering the
       packet to be retransmitted if an old packet arrives.
    4) Several other problems in the retransmit code.

I believe that the PC/IP people at MIT are shipping a completely new tftp implementation
for 4.2bsd as part of their PC/IP package.  I suggest contacting John Romkey at MIT
(romkey@mit-borax.mit.edu, I think) for further information.
                                                -Larry Allen
                                                 Apollo Computer

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Oct-85 21:05:36 EDT
From:      romkey@MIT-BORAX.ARPA (John Romkey)
To:        fa.tcp-ip
Subject:   new 4.2 tftp daemon

As Larry Allen mentioned in his message about TFTP retransmissions, we
do have a completely new tftp for 4.2 and we'll be shipping it with
the next PC/IP release (I'll send in a note about that when it's
ready). BTW, Larry wrote/ported this TFTP.

The TFTP implementation is also available via anonymous ftp from
borax.mit.edu:/pub/tftp.tar.

This TFTP doesn't have any of the problems that Larry mentioned in his
message. There are a couple of potential drawbacks: we've only run the
server under Berkeley's inetd; I don't know if it works without it.
The TFTP user also doesn't have the FTP-like interface Berkeley did
for their TFTP user.
						- John Romkey

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 85 13:26:00 PDT
From:      <prodmkt@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   IBM TCP/IP survey
From:	SAGE::PRODMKT      15-OCT-1985 13:25
To:	PRODMKT
Subj:	IBM survey



The following questionaire solicits responses regarding current and 
planned useage of IBM mainframes and associated equipment at sites with
concurrent requirement for TCP/IP protocols.

This information will be used for product planning purposes here at A.C.C.
Any one wishing a compilation of the responses should request them from
me. If there is a large demand for same, I will post the compilation directly
to the net. Please respond directly to me here at A.C.C.

Thanks in advance,

Mike Kane  (PRODMKT@acc.arpa)



By the way, include all plug compatible equipment as appropriate, also.


1.  How many IBM mainframes at your site?


2.  How many 4300's?


3.  What is the primary operating system?

    If you run VM, what guest OS's do you run in addition?

4.  What is the primary application(s)? (TSO,CICS,IMS,etc)



5.  Does your site support or have planned an SNA network?


6.  Does your site have a BSC network?


7.  Is there a requirement for interfacing non-IBM, ascii hosts to
    
    existing IBM net's?

8.  If you are already doing #7, what solution did you use?


9.  Do you currently have TCP/IP running in an IBM environment?

10. Do you plan on having TCP/IP in  an  IBM environment?


11. Which in your IBM requirement set is more pressing;  ARPA style
 
    attachments, or Ethernet attachments?


12. In the case of both attachments mentioned in #11, is there a further
 
    requirement of maintaining SNA network integrity/transparency?


13. Any comments? 


14. Any suggestions regarding further questions?

------
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Oct-85 16:26:00 EDT
From:      prodmkt@ACC.ARPA
To:        fa.tcp-ip
Subject:   IBM TCP/IP survey

From:	SAGE::PRODMKT      15-OCT-1985 13:25
To:	PRODMKT
Subj:	IBM survey



The following questionaire solicits responses regarding current and 
planned useage of IBM mainframes and associated equipment at sites with
concurrent requirement for TCP/IP protocols.

This information will be used for product planning purposes here at A.C.C.
Any one wishing a compilation of the responses should request them from
me. If there is a large demand for same, I will post the compilation directly
to the net. Please respond directly to me here at A.C.C.

Thanks in advance,

Mike Kane  (PRODMKT@acc.arpa)



By the way, include all plug compatible equipment as appropriate, also.


1.  How many IBM mainframes at your site?


2.  How many 4300's?


3.  What is the primary operating system?

    If you run VM, what guest OS's do you run in addition?

4.  What is the primary application(s)? (TSO,CICS,IMS,etc)



5.  Does your site support or have planned an SNA network?


6.  Does your site have a BSC network?


7.  Is there a requirement for interfacing non-IBM, ascii hosts to
    
    existing IBM net's?

8.  If you are already doing #7, what solution did you use?


9.  Do you currently have TCP/IP running in an IBM environment?

10. Do you plan on having TCP/IP in  an  IBM environment?


11. Which in your IBM requirement set is more pressing;  ARPA style
 
    attachments, or Ethernet attachments?


12. In the case of both attachments mentioned in #11, is there a further
 
    requirement of maintaining SNA network integrity/transparency?


13. Any comments? 


14. Any suggestions regarding further questions?

------

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Oct-85 19:51:31 EDT
From:      schoff@RPICS.CSNET (Martin Lee Schoffstall)
To:        fa.tcp-ip
Subject:   SUN style RPC's


Here at RPI we are working on a PC version of the RPC's, I'm
interested in finding out who else has a version and who is
going to.  I know about the following:

  gould,pyramid,4.2vax,sun

I'd be interested in hearing about an IBM/VM RPC virtual machine
that would allow me to use a 3081D or 3090/400 eventually from
my installed base of PC's or any other large machine version.

Of intellectual interest would be if anyone is doing this for
the CRAY2, (I don't expect to cut a PO for one just yet though).

marty schoffstall
schoff%rpics.csnet@csnet-relay	ARPA
schoff@rpics			CSNET
seismo!rpics!schoff		UUCP

RPI
Computer Science Department
Troy, NY  12180
(518) 271-2654

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Oct 85 19:51:31 EDT
From:      Martin Lee Schoffstall <schoff%rpics.csnet@CSNET-RELAY.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   SUN style RPC's

Here at RPI we are working on a PC version of the RPC's, I'm
interested in finding out who else has a version and who is
going to.  I know about the following:

  gould,pyramid,4.2vax,sun

I'd be interested in hearing about an IBM/VM RPC virtual machine
that would allow me to use a 3081D or 3090/400 eventually from
my installed base of PC's or any other large machine version.

Of intellectual interest would be if anyone is doing this for
the CRAY2, (I don't expect to cut a PO for one just yet though).

marty schoffstall
schoff%rpics.csnet@csnet-relay	ARPA
schoff@rpics			CSNET
seismo!rpics!schoff		UUCP

RPI
Computer Science Department
Troy, NY  12180
(518) 271-2654

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Oct-85 07:21:00 EDT
From:      norm@NCSC.ARPA (Ernest Norman)
To:        fa.tcp-ip
Subject:   Help with host addressing

I need some help
We at NCSC 26.4.0.53 have in the past depended upon the NAVY LABRATORY
COMPUTER NETWORK (NALCON) Program Office for updates to software.  Recently
NALCON announced that they would no longer supply programming support

It appears now that NCSC is getting further from the rest of the world in
software compatibility.  Specifically addressing of hosts when using
electronic mail has become a problem.  Most sites are now using addressing
with some form of dot net (for example NCSC.ARPA). We do not (ex NCSC).  

I need to know how to get updated software to handle this addressing extension.

Currently NCSC is using 4.1bsd UNIX on a VAX 11/750.

Where do I get the updates for our software?
                                     NORM.
-------

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 85 07:21 EDT
From:      Ernest Norman <norm@ncsc>
To:        TCP-IP-REQUEST@SRI-NIC
Cc:        norm@ncsc
Subject:   Help with host addressing
I need some help
We at NCSC 26.4.0.53 have in the past depended upon the NAVY LABRATORY
COMPUTER NETWORK (NALCON) Program Office for updates to software.  Recently
NALCON announced that they would no longer supply programming support

It appears now that NCSC is getting further from the rest of the world in
software compatibility.  Specifically addressing of hosts when using
electronic mail has become a problem.  Most sites are now using addressing
with some form of dot net (for example NCSC.ARPA). We do not (ex NCSC).  

I need to know how to get updated software to handle this addressing extension.

Currently NCSC is using 4.1bsd UNIX on a VAX 11/750.

Where do I get the updates for our software?
                                     NORM.
-------
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Oct-85 11:27:00 EDT
From:      Mills@CISL-SERVICE-MULTICS.ARPA
To:        fa.tcp-ip
Subject:   French ARPANET connections?

A number of researchers at French universities are planning on setting
up a network between themselves.  They are also interested in connecting
to the ARPANET.  Does the net extend to Europe?  Who is a good person
for them to contact about geting a sponsor and/or general approval to be
on the net?

John Mills

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Oct-85 17:54:30 EDT
From:      MILLS@USC-ISID.ARPA
To:        fa.tcp-ip
Subject:   Re: French ARPANET connections?

In response to the message sent   Wed, 16 Oct 85 11:27 EDT from Mills@CISL-SERVICE-MULTICS.ARPA

John,

You might bring the issue up with Dennis Jennings at the NSF Office of Advanced Scientific
Computing. These gents might be ripe for NSFNET.

Dave (no relation)
-------

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Oct-85 19:29:25 EDT
From:      raj@UCI-ICSA.ARPA (Richard Johnson)
To:        fa.tcp-ip
Subject:   Ethernet problems

I'm not sure if this is the correct Bboard for this.  If not,
please let me know where it should be sent.

We have an ethernet which consists of 5 VAX 750s plugged into a DEC
Delni.  This is connected onto a length of cable which has 4 other
Int. Sol. machines and 2 suns.  We just recently ran about 500 ft. of
cable (which together with the already existing cable placed us
around 300 meters or so) and moved 2 of the Int. Sol. machines to the
end of this length. (All systems are running 4.2BSD [Suns run SUN's
version]) Basically our configuration looks like this:

A  B  C                          +-- added length --+
 \ | /                           V                  V
 delni ----------Sun--Sun--IS--IS--------------IS--IS
 / | \                                         (x) (y)
D  E  IS

About a week or so after this change was made we started having
problems. About every 2-4 weeks suddenly every machine on the net
claims that every other machine is down.  You can't connect to any
other machines.  I have found that if I disconnect the extra length
(recently added) the problem seems to go away. It would seem to not
be a bad ethernet board in one of the machines because I can connect
either one of the 2 IS's ('x' or 'y') onto the net by itself and the
net is still upset. However, I can reconnect the extra length (along
with the 2 machines at the end of it) after about 15-30 min's and
everything is fine for another few weeks.  Sometimes the problem
seems to just goes away on its own also!  (By the way, a "netstat -i"
says we are sending and receiving lots of packets but getting about
as many input errors as input packets!)

Has anyone ever seen anything like this?  I'm guessing it means we're
too close to the max. length for the ethernet, but I calculate the
total length as around 300 meters and the standard say 500 meters.

------------------------------------------------------------------------
Richard Johnson                             raj@uci.edu           (ARPA)
UCI ICS Research Systems Manager            ucbvax!ucivax!raj     (UUCP)

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 1985 07:37:23 CDT
From:      DDN-REQT@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        DDN-REQT@GUNTER-ADAM.ARPA
Subject:   excelan boards
Can anybody tell me if you can order the TCP/IP board with X.25
instead of the ethernet interface.  I'd also like some info on
the capabilities of the product, or rather the flexibility.
Can you do source routing and set IP options? How many connections
can the TCP support?  etc,etc

Getting some documentation on the products would be nice!


Darrel B.
DDN-REQT@GUNTER-ADAM
-------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Oct-85 08:37:23 EDT
From:      DDN-REQT@GUNTER-ADAM.ARPA
To:        fa.tcp-ip
Subject:   excelan boards

Can anybody tell me if you can order the TCP/IP board with X.25
instead of the ethernet interface.  I'd also like some info on
the capabilities of the product, or rather the flexibility.
Can you do source routing and set IP options? How many connections
can the TCP support?  etc,etc

Getting some documentation on the products would be nice!


Darrel B.
DDN-REQT@GUNTER-ADAM
-------

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 85 12:24:00 PDT
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   Request for TCP/IP test program

Before we reinvent another wheel, I'll try the network...

On BSD 4.2 we have been using FTP (in binary mode) to obtain TCP/IP
performance numbers for traffic through various network configurations.
These figures can be (and have been seen to be) impacted by internal
FTP overhead and especially disk I/O bandwidth.

What I want is one program which opens a TCP connection and sends blocks
of data (data source) and another program which accepts a TCP connection
and discards the data (data sink).  The internet address, block size and
block count should be program arguments.  Both source and sink programs
should calculate and display throughput statistics.  These should be
as simple as possible to minimize CPU loading.

If anyone has anything like this or could be used as a starting point
I would appreciate a copy.
				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Oct-85 10:47:48 EDT
From:      lbyers%xls-plexus01.amc@AMC-HQ.ARPA (Lynn)
To:        fa.tcp-ip
Subject:   Deletion

Please delete <lbyers at amc-hq> from the tcp-ip mailing list.

Thanks....Lynn

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 85 10:47:48-EDT (Thu)
From:      Lynn <lbyers%xls-plexus01.amc@AMC-HQ.ARPA>
To:        tcp-ip%sri-nic.arpa@AMC-HQ.ARPA
Subject:   Deletion
Please delete <lbyers at amc-hq> from the tcp-ip mailing list.

Thanks....Lynn
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Oct-85 11:58:18 EDT
From:      marwaha@LOUIE.UDEL.EDU
To:        fa.tcp-ip
Subject:   info on commercially available LANs

I am looking for information about commercially available LAN products.
This is for a survey report on commercially available LAN systems and 
how they map onto the various network standards proposed by the various
committees. If any body has any pointers to manufacturers/developers
of LAN products or knows where I can get such information (e.g. a LAN
manufacturers directory) I would be happy to know about it.
Thanx.

Samar Marwaha
214 Smith Hall
University of Delaware
Newark DE 19716

marwaha@udel-dewey

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Oct-85 15:24:00 EDT
From:      art@ACC.ARPA
To:        fa.tcp-ip
Subject:   Request for TCP/IP test program


Before we reinvent another wheel, I'll try the network...

On BSD 4.2 we have been using FTP (in binary mode) to obtain TCP/IP
performance numbers for traffic through various network configurations.
These figures can be (and have been seen to be) impacted by internal
FTP overhead and especially disk I/O bandwidth.

What I want is one program which opens a TCP connection and sends blocks
of data (data source) and another program which accepts a TCP connection
and discards the data (data sink).  The internet address, block size and
block count should be program arguments.  Both source and sink programs
should calculate and display throughput statistics.  These should be
as simple as possible to minimize CPU loading.

If anyone has anything like this or could be used as a starting point
I would appreciate a copy.
				"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 85 09:46:00 PDT
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   RE: Ethernet problem
> 
> About a week or so after this change was made we started having
> problems. About every 2-4 weeks suddenly every machine on the net
> claims that every other machine is down.  You can't connect to any
> other machines.  I have found that if I disconnect the extra length
> (recently added) the problem seems to go away. It would seem to not
> be a bad ethernet board in one of the machines because I can connect
> either one of the 2 IS's ('x' or 'y') onto the net by itself and the
> net is still upset. However, I can reconnect the extra length (along
> with the 2 machines at the end of it) after about 15-30 min's and
> everything is fine for another few weeks.  Sometimes the problem
> seems to just goes away on its own also!  (By the way, a "netstat -i"
> says we are sending and receiving lots of packets but getting about
> as many input errors as input packets!)
> 
> Has anyone ever seen anything like this?  I'm guessing it means we're
> too close to the max. length for the ethernet, but I calculate the
> total length as around 300 meters and the standard say 500 meters.
>

If feasable, you might consider having someone test your cable with
a Time Domain Reflectometer to make sure you don't have any significant
impedance mismatches.  You might also try flexing connectors, tranceiver
taps and terminators with the system running to look for mechanical
problems in the cable.  The DELNI is (I believe) V2 Ethernet specs, so
verify that the other equiptment is compatible. (V1 and 802.3 have slight
differences)
				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Oct-85 09:42:38 EDT
From:      MILLS@USC-ISID.ARPA
To:        fa.tcp-ip
Subject:   Re: Request for TCP/IP test program

In response to the message sent  17 Oct 85 12:24:00 PDT from  <art@acc.arpa>

Art,

I suggest you contact Ed Cain (cain@edn-unix.arpa), chairman of the Testing
Task Force. He may either ping the members or point you to the Protocol
Testing Laboratory at DCEC or both. Many old grizzlies, myself included
have well-worn TCP testing machinery, but it is not the kind you simply
drop into 4.2 and turn the key.

Dave
-------

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 1985 1341-PDT (Friday)
From:      jeff@isi-vaxa.ARPA (Jeffery A. Cavallaro)
To:        DDN-REQT@GUNTER-ADAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: excelan boards
One note, if you are 4.2BSD, you may be out of luck.  Last I heard, the
EXOS series would not support smart operation under 4.2BSD, and EXCELAN
was not planning to change things.

					Jeff
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Oct-85 12:46:00 EDT
From:      art@ACC.ARPA
To:        fa.tcp-ip
Subject:   RE: Ethernet problem

> 
> About a week or so after this change was made we started having
> problems. About every 2-4 weeks suddenly every machine on the net
> claims that every other machine is down.  You can't connect to any
> other machines.  I have found that if I disconnect the extra length
> (recently added) the problem seems to go away. It would seem to not
> be a bad ethernet board in one of the machines because I can connect
> either one of the 2 IS's ('x' or 'y') onto the net by itself and the
> net is still upset. However, I can reconnect the extra length (along
> with the 2 machines at the end of it) after about 15-30 min's and
> everything is fine for another few weeks.  Sometimes the problem
> seems to just goes away on its own also!  (By the way, a "netstat -i"
> says we are sending and receiving lots of packets but getting about
> as many input errors as input packets!)
> 
> Has anyone ever seen anything like this?  I'm guessing it means we're
> too close to the max. length for the ethernet, but I calculate the
> total length as around 300 meters and the standard say 500 meters.
>

If feasable, you might consider having someone test your cable with
a Time Domain Reflectometer to make sure you don't have any significant
impedance mismatches.  You might also try flexing connectors, tranceiver
taps and terminators with the system running to look for mechanical
problems in the cable.  The DELNI is (I believe) V2 Ethernet specs, so
verify that the other equiptment is compatible. (V1 and 802.3 have slight
differences)
				"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Oct-85 12:56:52 EDT
From:      clements@BBNCCQ.ARPA (Bob Clements)
To:        fa.tcp-ip
Subject:   Re: Request for TCP/IP test program


[Art @ ACC.ARPA asked about date source/sink programs that avoid
the overhead of using the disk for the data.]

Art,

The original TENEX/TOPS20 FTP server, which I wrote many years
ago, had a "feature" to do exactly what you are looking for: It
recognized the "NUL:" device as a special case.  Data sent to
NUL: was discarded immediately by the FTP server, without even
calling the file system to discard it.  Data requested FROM the
NUL: device was generated by the FTP server itself, and it sent a
fixed amount, one megabyte or one megabit, I think.

Sadly, I have been exiled from 36-bit land for a while, so I
don't know whether that feature is still in the current server.
I hope so.

/Rcc

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Oct 85 12:56:52 EDT
From:      Bob Clements <clements@bbnccq.ARPA>
To:        <art@acc.arpa>
Cc:        tcp-ip@sri-nic.arpa, clements@bbnccq.arpa
Subject:   Re: Request for TCP/IP test program

[Art @ ACC.ARPA asked about date source/sink programs that avoid
the overhead of using the disk for the data.]

Art,

The original TENEX/TOPS20 FTP server, which I wrote many years
ago, had a "feature" to do exactly what you are looking for: It
recognized the "NUL:" device as a special case.  Data sent to
NUL: was discarded immediately by the FTP server, without even
calling the file system to discard it.  Data requested FROM the
NUL: device was generated by the FTP server itself, and it sent a
fixed amount, one megabyte or one megabit, I think.

Sadly, I have been exiled from 36-bit land for a while, so I
don't know whether that feature is still in the current server.
I hope so.

/Rcc

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Oct-85 13:54:00 EDT
From:      stanonik@NPRDC.ARPA (Ron Stanonik)
To:        fa.tcp-ip
Subject:   Re: 4.2BSD tftp doesn't retransmit acks

Thanks.  You refer to a "current tftp spec" which says "Acks
are retransmitted ONLY when the retransmit timer expires".
The most recent tftp spec I'm aware of is rfc783 which says
"If a packet gets lost in the network, the intended recipient
will timeout and may retransmit his last packet (which may be
data or an acknowledgement)".  Is there some later tftp spec?
Where?

Also, the problem we encountered was that 4.2bsd tftp never
retransmitted the ack.  It didn't retransmit in response to
repeated data packets, and it didn't timeout because the data
packets reset the timer.  Given that "acks are only retransmitted
when the timer expires", I can see the problem appears to be
an incorrectly reset timer.

Yep, we're bagging 4.2bsd's tftp, mostly.  A couple of pc's here
are still running a version of tftp assuming 4.2bsd's damaged
netascii.

Thanks again,

Ron
stanonik@nprdc.arpa

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Oct-85 14:37:00 EDT
From:      jeff@ISI-VAXA.ARPA ("Jeffery A. Cavallaro")
To:        fa.tcp-ip
Subject:   Re: info on commercially available LANs

BRIDGE COMMUNICATIONS has a rather extensive set of turnkey/programmable
systems.  You can find them at:

1345 Shorebird Way
Mountain View, CA.  94043
(415)-969-4400

You might ask for Judith Estrin.  She is VP of Engineering.  She can
point you to the appropriate people.  A project that I worked on
had a good experience with the products and the company.

A good marketing contact is Nancy Collins, (714)-476-8844.  She was
our sales rep.  I don't know if she would cover your area.

If you call, tell Judith or Nancy that Jeff Cavallaro (formally of TRW)
sent you!
					Jeff

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 1985 17:43:12 PDT
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        art@ACC.ARPA
Subject:   re: TCP test programs

Art:

You might try the Echo Server                (port 7)  [RFC 862],
              the Discard Server             (port 9)  [RFC 862],
          and the Character Generator Server (port 19) [RFC 864].

--jon.
-------
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Fri 18 Oct 85 15:19:00-EDT
From:      Vince.Fuller@C.CS.CMU.EDU
To:        clements@BBNCCQ.ARPA
Cc:        art@ACC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Request for TCP/IP test program
As an unofficial maintainer of a TOPS-20 FTP server, I can say that it
still contains code for supporting transfers to and from the NUL: device.

	--Vince
-------
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 85 18:38:26 EDT
From:      DonWinter.pasa@Xerox.ARPA
To:        Richard Johnson <raj@UCI.EDU>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Ethernet problems
I have had a problem very similar to this involving an ad hoc Ethernet
extension here at Xerox in Pasadena. The problem involved a TRANSCEIVER
which was (a) located within minimum distance of the extra piece of net,
and (b) "shorted" out its connection for the first twenty minutes or so
aftr being turned on. The problem was thus transient for 20 minutes
every morning.

We tracked it down, because the particular user was not an early riser,
and because the ad hoc piece of net was designed for a team project
working in a bull-pen environment. Luckily, we also had a network "guru"
on the team in that room.

We used to joke about the net taking its  morning break when this one
user arrived, but paid no further attention until he didn't turn on his
machine for quite some time after arriving, and the problem occured
then.

No amount of testing from Network Support showed anything, because the
transceiver was always warm then. Our team did a test during the 20
minutes, and proved that the problem moved with the transceiver.
Replacement of that transceiver made every user in the building eternaly
grateful to the unknown team who had fixed the net's morning break.

This may not be germane to your problem, but every little bit if
information helps whenn obscure problems arise.

				Don
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Oct-85 20:43:12 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        fa.tcp-ip
Subject:   re: TCP test programs


Art:

You might try the Echo Server                (port 7)  [RFC 862],
              the Discard Server             (port 9)  [RFC 862],
          and the Character Generator Server (port 19) [RFC 864].

--jon.
-------

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Oct-85 12:40:37 EDT
From:      radzy@calma.UUCP
To:        fa.tcp-ip
Subject:   Re: Ethernet problems

In article <376.498353365@uci.edu> you write:
>I'm not sure if this is the correct Bboard for this.  If not,
>please let me know where it should be sent.

I would have sent it to net.lan, but I don't think net.tcp-ip is
INappropriate for it.  Ignore any flames.

>                                We just recently ran about 500 ft. of
>cable (which together with the already existing cable placed us
>around 300 meters or so)
>
>About a week or so after this change was made we started having
>problems. About every 2-4 weeks suddenly every machine on the net
>claims that every other machine is down.
>                 I have found that if I disconnect the extra length
>(recently added) the problem seems to go away.
>                    However, I can reconnect the extra length (along
>with the 2 machines at the end of it) after about 15-30 min's and
>everything is fine for another few weeks.
>
>Has anyone ever seen anything like this?  I'm guessing it means we're
>too close to the max. length for the ethernet, but I calculate the
>total length as around 300 meters and the standard say 500 meters.

I doubt the problem is with length.  The ethernet specification says
2.5 kilometers, not 500 meters (unless you're using experimental ether,
in which case it's still 1 kilometer).

I had problems something like that a while back.  The symptoms were
that the network was (always) slow, and there were lots of illegal
packets.  Often, you couldn't get connected, same as your net now,
but it wasn't periodic, like you're seeing.

The problem turned out to be a combination of two things, neither
of which is quite kosher, but neither of which (alone) would cause
the net to behave quite so lousy:
	1.  I had added a few sections of the thin cable to one
		end of the net, for IBM PCs to use with their
		internal transceivers.  The thin cable has a differet
		impedance than the thick cable.
	2.  Several of out transceivers were not placed at correct
		locations.  The result of this was that the machines
		connected to those transceivers were much worse about
		problems.

Could something like either of those problems be related to yours?
For the first, check if you have a bad connector (or transceiver,
if you are using 3-com type).  Also, make sure the cable is top
quality (I'm not sure of the nomenclature here, but there are a
couple of kinds and one kind costs about 1/2 what the other kind
costs -- get the expensive one).

For the second, make sure your cable has the marks at about 9-foot
intervals, and make sure all your transceivers are on one of the 
marks.


Hope this helps.

-- 
Tim (radzy) Radzykewycz
	calma!radzy@ucbvax.ARPA
	ucbvax!calma!radzy

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Oct-85 20:01:25 EDT
From:      HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
To:        fa.tcp-ip
Subject:   Re: Ethernet problems

As I read it, the spec says 500 meters.  2.5 Km is for configurations
involving multiple bridges, and also a 1 Km length of fiber optic
cable.

If it really takes you 15 - 30 min to recover once you remove the
extra length, this suggests that the problem involves software tables.
This is about the amount of time it takes Unix systems to clear their
ARP tables.  I would look carefully at the two machines on the end of
the extra cable.  Is it possible that they are set up with wrong network
configuration information, such that somehow duplicate addresses or
forwarding loops are resulting?

-------

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Oct-85 20:12:00 EDT
From:      jeff@ISI-VAXA.ARPA ("Jeffery A. Cavallaro")
To:        fa.tcp-ip
Subject:   Re: info on commercially available LANs

Sorry that this message went to the whole group.  I guess I didn't fool
our automated mail composition SW very well.  Sorry for the advertisement
overtones.  It was not meant to be one.

					Jeff

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Oct-85 08:42:55 EDT
From:      dpk@mcvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  TCP test programs

I believe there are two different implementations of the "little
services" (source, sink, echo, & others) for UNIX (4.2BSD).
I think one of them was done by Chris Kent at Purdue (cak@purdue).

-Doug-

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Oct-85 14:20:17 EDT
From:      cak@PURDUE.EDU ("Christopher A. Kent")
To:        mod.protocols.tcp-ip
Subject:   Re: TCP test programs

Nope, I didn't do any little services, just finger. We use a program
called inetd (not like SUN's inetd) from Marshall Rose.

chris
----------

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 1985 1706-EST
From:      Dale Moore <MOORE@PS1.CS.CMU.EDU>
To:        TCP-IP@NIC
I was looking into commercially available IP/TCP products for VMS.
Below is an excerpt of one candidates "IP/TCP Primer".

	INTERNET address are defined as having 4-tuples (or parts),
	[a.b.c.d].  The first address, a, stands for the actual network
	where your host is located.  For example, there could be a network
	coded as "128", supporting some number of ARPANET host systems.

	The second field, b, is the subnet of your host system.  For the
	purposes of this example, b would be equal to "30".  Each network,
	therefore, is divided into subnets.  As each network receives a
	packet, it checks to see which subnet the data is for and
	routes it accordingly.

	Address field c is the local network number of your network.  So,
	each sub-network is divided into another group of computer systems
	that are configured in a local network arrangement.  In the example,
	c is equal to "5".

	. . . . .

	Using the numbers assigned above, if someone on the INTERNET sent
	data to a system address of [128.2.5.3], The data would be delivered
	to system 3 on local network 5 on the subnetwork 30 lying on network
	128.

	Once you system has a unique address, testing the IP/TCP
	implementation can be accomplished with any (or all) of the
	approximately 500 hosts on the INTERNET.

The above is copied verbatim from their primer (The IP/TCP Primer October
1984 V1.14).  Given that the above is full of lies and misinformation, I
won't tell you the name of the company.  But their initials are TWG, and it
is the only IP/TCP code sold by DEC for VMS.

Would you by networking software from these folks?
------
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Oct-85 18:06:00 EDT
From:      MOORE@PS1.CS.CMU.EDU (Dale Moore)
To:        mod.protocols.tcp-ip
Subject:   (none)

I was looking into commercially available IP/TCP products for VMS.
Below is an excerpt of one candidates "IP/TCP Primer".

	INTERNET address are defined as having 4-tuples (or parts),
	[a.b.c.d].  The first address, a, stands for the actual network
	where your host is located.  For example, there could be a network
	coded as "128", supporting some number of ARPANET host systems.

	The second field, b, is the subnet of your host system.  For the
	purposes of this example, b would be equal to "30".  Each network,
	therefore, is divided into subnets.  As each network receives a
	packet, it checks to see which subnet the data is for and
	routes it accordingly.

	Address field c is the local network number of your network.  So,
	each sub-network is divided into another group of computer systems
	that are configured in a local network arrangement.  In the example,
	c is equal to "5".

	. . . . .

	Using the numbers assigned above, if someone on the INTERNET sent
	data to a system address of [128.2.5.3], The data would be delivered
	to system 3 on local network 5 on the subnetwork 30 lying on network
	128.

	Once you system has a unique address, testing the IP/TCP
	implementation can be accomplished with any (or all) of the
	approximately 500 hosts on the INTERNET.

The above is copied verbatim from their primer (The IP/TCP Primer October
1984 V1.14).  Given that the above is full of lies and misinformation, I
won't tell you the name of the company.  But their initials are TWG, and it
is the only IP/TCP code sold by DEC for VMS.

Would you by networking software from these folks?
------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 85 21:37:00 PDT
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Cc:        unix-wizards@brl
Subject:   Thanks for responses

This is a note of thanks to all who responded to my query for TCP/IP
test programs for 4.2 UNIX.  The response reconfirms my view that the
network is an extremely valuable resource for information sharing.

				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Oct-85 00:37:00 EDT
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   Thanks for responses


This is a note of thanks to all who responded to my query for TCP/IP
test programs for 4.2 UNIX.  The response reconfirms my view that the
network is an extremely valuable resource for information sharing.

				"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Oct-85 10:47:00 EDT
From:      Mills@CISL-SERVICE-MULTICS.ARPA
To:        mod.protocols.tcp-ip
Subject:   French ARPANET connections

Thanks to everyone who responded to my earlier request.  The number of
replies and the quality of the information was very impressive.

John Mills

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Oct-85 00:03:59 EDT
From:      ron@BRL.ARPA (Ron Natalie)
To:        mod.protocols.tcp-ip
Subject:   IP, ICMP, TCP, and UDP checksumming.

This has come up before, but I don't know if we came up with an answer.
When doing the complement of the ones complement sum, do you fix negative
zero to be zero; pick one: never, after the sum and before the complement,
after the complement.

The obvious solution is to never normalize the value you insert in the header
but always check for a comparison of 0 equals -0 when doing verification.  Or,
do we want to get more rigorous.

-Ron

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Oct 85 0:03:59 EDT
From:      Ron Natalie <ron@BRL.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   IP, ICMP, TCP, and UDP checksumming.
This has come up before, but I don't know if we came up with an answer.
When doing the complement of the ones complement sum, do you fix negative
zero to be zero; pick one: never, after the sum and before the complement,
after the complement.

The obvious solution is to never normalize the value you insert in the header
but always check for a comparison of 0 equals -0 when doing verification.  Or,
do we want to get more rigorous.

-Ron
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 1985 1839-PDT (Wednesday)
From:      Tim Mann <mann@su-pescadero.arpa>
To:        Jonathan Dreyer <jdreyer@BBNCCV.ARPA>
Cc:        tcp-ip@sri-nic
Subject:   Re: IP, ICMP, TCP, and UDP checksumming.
The problem with your analysis is that it depends on a particular way
of doing ones-complement arithmetic on a non-ones-complement machine.
(Unsigned addition followed by end-around carry, with no normalization
step.)  If I have a true ones-complement machine, it would be perfectly
legitimate for it to automatically normalize ~0 to +0 after every
addition, in which case the property "you can never get 0 in a sum
unless both addends are 0" does not hold.  Also, treating ~0 and +0 as
different makes it much more confusing to analyze the arithmetic, since
if they are treated as identical, we have modulo (2^n) - 1 arithmetic,
whose properties are well-known, but if they are treated as different,
the system is not even a group.

Nonetheless, I think your analysis is correct.  The upshot is that IF
you are checking a checksum on a twos-complement machine and doing
end-around carry in software, you will never get ~0 after complementing
if the checksum is correct.  HOWEVER, you will not be robust, since
another implementation may put +0 in the checksum field when it meant
~0, in a packet with zeroes in all other fields, in which case you WILL
get ~0.  (This is the only case in which you will get ~0.)  This
problem is a common one since it isn't absolutely clear to people who
read the IP spec that "the ones complement of the ones-complement
sum..." can never be +0.  In fact, if one uses the above
checksum-checking code to generate checksums as well, it is easy to
make that mistake.  This is a problem we actually ran into at Stanford
a while back.

In short, avoid headaches by normalizing.

	--Tim
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Oct-85 19:14:00 EDT
From:      jdreyer@BBNCCV.ARPA (Jonathan Dreyer)
To:        mod.protocols.tcp-ip
Subject:   Re: IP, ICMP, TCP, and UDP checksumming.

The following argument is so simple, it must be wrong.

You should never have to "normalize" a ones complement checksum.

In the following, by "sum" or "+" I mean the ones complement sum, by
"0" I mean positive zero (all bits are zero), and by "full checksum
computation" I mean the complement of the (ones complement) sum.

Let S be the sum of all the words in a message except the checksum
field.  The checksum field of the message should thus contain ~S.  The
full checksum computation on the message with the checksum in place is
thus

	~(S + ~S).

But the sum of anything and its complement is all ones (~0) so

	~(S + ~S) = ~(~0) = 0.

This argument is based on commutativity and associativity of the ones
complement sum.  I think this is a valid assumption but don't have the
patience to verify it.

Another way of looking at it is to note that you can never get 0 in a
sum unless both addends are 0.  Think of it: you can only get zero (of
one flavor or other) when the addends are inverses, and the addends are
inverses only when they are complements or both zero.  Thus there are
three ways to get a sum of some kind of zero:

	0 + 0 = 0
	~0 + (+/~ 0) = ~0         (left as exercise)
	nonzero + ~nonzero = ~0.

Thus a full checksum computation (complement of the sum) can never
yield ~0, except when all the data is 0.  In this special case, the
checksum field should be ~0 so again the full checksum computation
yields 0.  Thus, in no case can the full checksum computation yield
~0.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 85 19:14:00 EDT (Wed)
From:      Jonathan Dreyer <jdreyer@BBNCCV.ARPA>
To:        Ron Natalie <ron@brl.ARPA>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: IP, ICMP, TCP, and UDP checksumming.
The following argument is so simple, it must be wrong.

You should never have to "normalize" a ones complement checksum.

In the following, by "sum" or "+" I mean the ones complement sum, by
"0" I mean positive zero (all bits are zero), and by "full checksum
computation" I mean the complement of the (ones complement) sum.

Let S be the sum of all the words in a message except the checksum
field.  The checksum field of the message should thus contain ~S.  The
full checksum computation on the message with the checksum in place is
thus

	~(S + ~S).

But the sum of anything and its complement is all ones (~0) so

	~(S + ~S) = ~(~0) = 0.

This argument is based on commutativity and associativity of the ones
complement sum.  I think this is a valid assumption but don't have the
patience to verify it.

Another way of looking at it is to note that you can never get 0 in a
sum unless both addends are 0.  Think of it: you can only get zero (of
one flavor or other) when the addends are inverses, and the addends are
inverses only when they are complements or both zero.  Thus there are
three ways to get a sum of some kind of zero:

	0 + 0 = 0
	~0 + (+/~ 0) = ~0         (left as exercise)
	nonzero + ~nonzero = ~0.

Thus a full checksum computation (complement of the sum) can never
yield ~0, except when all the data is 0.  In this special case, the
checksum field should be ~0 so again the full checksum computation
yields 0.  Thus, in no case can the full checksum computation yield
~0.
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Oct-85 21:39:00 EDT
From:      mann@SU-PESCADERO.ARPA (Tim Mann)
To:        mod.protocols.tcp-ip
Subject:   Re: IP, ICMP, TCP, and UDP checksumming.

The problem with your analysis is that it depends on a particular way
of doing ones-complement arithmetic on a non-ones-complement machine.
(Unsigned addition followed by end-around carry, with no normalization
step.)  If I have a true ones-complement machine, it would be perfectly
legitimate for it to automatically normalize ~0 to +0 after every
addition, in which case the property "you can never get 0 in a sum
unless both addends are 0" does not hold.  Also, treating ~0 and +0 as
different makes it much more confusing to analyze the arithmetic, since
if they are treated as identical, we have modulo (2^n) - 1 arithmetic,
whose properties are well-known, but if they are treated as different,
the system is not even a group.

Nonetheless, I think your analysis is correct.  The upshot is that IF
you are checking a checksum on a twos-complement machine and doing
end-around carry in software, you will never get ~0 after complementing
if the checksum is correct.  HOWEVER, you will not be robust, since
another implementation may put +0 in the checksum field when it meant
~0, in a packet with zeroes in all other fields, in which case you WILL
get ~0.  (This is the only case in which you will get ~0.)  This
problem is a common one since it isn't absolutely clear to people who
read the IP spec that "the ones complement of the ones-complement
sum..." can never be +0.  In fact, if one uses the above
checksum-checking code to generate checksums as well, it is easy to
make that mistake.  This is a problem we actually ran into at Stanford
a while back.

In short, avoid headaches by normalizing.

	--Tim

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Oct-85 22:33:00 EDT
From:      don.provan@A.CS.CMU.EDU
To:        mod.protocols.tcp-ip
Subject:   Re: IP, ICMP, TCP, and UDP checksumming.

if you checksum the entire message (or header in IP), including the
checksum field, you'll always get -0 regardless of what the sending
entity put in the checksum field (assuming the packet isn't entirely
zero, which isn't legal in IP and TCP and, i think, ICMP and UDP).
if everyone used this approach (which, i believe, works just as well
if the machine does your ones complement addition, although you'd
check for +0 on a machine that normalized), we shouldn't have to
worry about which one is "right".  of course, when they change the
checksum we'll all be up a creek...

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Oct-85 03:02:34 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   BRL's ROOT Domain Server

BRL's ROOT Domain Server once again seems to be well.
For those hosts on the east coast, or on MILNET, you may wish to
experiment with using this one.  BRL-AOS.ARPA 192.5.22.82
is the place (*Not* BRL.ARPA 26.0.0.29).

We were experiencing difficulty with the software, and with the root tables.

Please let me know if you encounter any problems.  I make no claim that
things are perfect yet.
	Best,
	 -Mike

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Oct 85 3:02:34 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        TCP-IP@sri-nic.ARPA
Subject:   BRL's ROOT Domain Server
BRL's ROOT Domain Server once again seems to be well.
For those hosts on the east coast, or on MILNET, you may wish to
experiment with using this one.  BRL-AOS.ARPA 192.5.22.82
is the place (*Not* BRL.ARPA 26.0.0.29).

We were experiencing difficulty with the software, and with the root tables.

Please let me know if you encounter any problems.  I make no claim that
things are perfect yet.
	Best,
	 -Mike
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Oct-85 03:20:47 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Hyperchannel problem

At BRL we operate a 3-node Hyperchannel network which has
it's share of problems.  One node attaches to a CDC Cyber,
and the other two are A440 ("minicomputer adaptor") nodes,
using the PI-13 UNIBUS interface.

About once a week or so, one of the three PI-13 boards
in the network will get "stuck", and powering the
A440 off and on does not help, nor does performing a
UNIBUS INIT.  Only removing power from the PI-13
and restoring it will clear the condition.  This can be
a real nuisance.

Also, several times a month, each Hyperchannel adaptor
will signal a power-off, power-on transition which none
of our PDUs claim existed.  This is curious, but not
particularly harmful.

My question is:  has anybode else on the list had similar
experiences with Hyperchannel equipment, and are there
known fixes?  The vendor has not been very helpful
trying to track this problem down.
	Best,
	 -Mike

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Oct 85 3:20:47 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        TCP-IP@sri-nic.arpa
Cc:        Hardware@BRL.ARPA
Subject:   Hyperchannel problem
At BRL we operate a 3-node Hyperchannel network which has
it's share of problems.  One node attaches to a CDC Cyber,
and the other two are A440 ("minicomputer adaptor") nodes,
using the PI-13 UNIBUS interface.

About once a week or so, one of the three PI-13 boards
in the network will get "stuck", and powering the
A440 off and on does not help, nor does performing a
UNIBUS INIT.  Only removing power from the PI-13
and restoring it will clear the condition.  This can be
a real nuisance.

Also, several times a month, each Hyperchannel adaptor
will signal a power-off, power-on transition which none
of our PDUs claim existed.  This is curious, but not
particularly harmful.

My question is:  has anybode else on the list had similar
experiences with Hyperchannel equipment, and are there
known fixes?  The vendor has not been very helpful
trying to track this problem down.
	Best,
	 -Mike
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 85 12:41:00 PDT
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Cc:        unix-wizards@brl
Subject:   LH/DH-11 and IMP padding


I reviewed the 1822 spec regarding IMP message lengths and relearned some
interesting information.  The IMP was originally designed to deal with
three different machine word lengths (source machine, IMP and destination
machine).  This involves a padding scheme which adds padding as a message
goes from src->IMP and also IMP->dst.  The IMP ALWAYS appends a 1 to the
message and zero pads to the end of an IMP word (16 bits).  For machines
with an LH/DH-11 (PDP-11 or VAX) this causes the destination host to receive
16 bits more than the original message length (plus any padding the destination
host interface might have to add).  The maximum message size that an IMP
will send to a host is 8160 bits (1020 bytes).  The BSD 4.2 driver CORRECTLY
limits the messages sent to the IMP to 1018 bytes, but INCORRECTLY uses a
1018 byte buffer to receive into.  If the LH/DH-11 is healthy, the driver
logic does deal with this situation, but with unneccessary interrupt overhead
(to start a bunch of 2 byte reads).  If the LH/DH-11 occasionally drops the
EOM when DMA is restarted, messages would get concatonated, with the second
(or both) messages being ignored.  We will attempt to cause this failure
in the lab, but recommend that LH/DH-11 drivers read into at least an
1020 byte buffer.
					"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Oct-85 15:41:00 EDT
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   LH/DH-11 and IMP padding



I reviewed the 1822 spec regarding IMP message lengths and relearned some
interesting information.  The IMP was originally designed to deal with
three different machine word lengths (source machine, IMP and destination
machine).  This involves a padding scheme which adds padding as a message
goes from src->IMP and also IMP->dst.  The IMP ALWAYS appends a 1 to the
message and zero pads to the end of an IMP word (16 bits).  For machines
with an LH/DH-11 (PDP-11 or VAX) this causes the destination host to receive
16 bits more than the original message length (plus any padding the destination
host interface might have to add).  The maximum message size that an IMP
will send to a host is 8160 bits (1020 bytes).  The BSD 4.2 driver CORRECTLY
limits the messages sent to the IMP to 1018 bytes, but INCORRECTLY uses a
1018 byte buffer to receive into.  If the LH/DH-11 is healthy, the driver
logic does deal with this situation, but with unneccessary interrupt overhead
(to start a bunch of 2 byte reads).  If the LH/DH-11 occasionally drops the
EOM when DMA is restarted, messages would get concatonated, with the second
(or both) messages being ignored.  We will attempt to cause this failure
in the lab, but recommend that LH/DH-11 drivers read into at least an
1020 byte buffer.
					"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 1985 20:32:09 PDT
From:      POSTEL@USC-ISIB.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   re: serial-line ip/tcp ?

For background see RFCs 914, 916, 935.

--jon.
-------
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Oct-85 17:41:16 EDT
From:      jas@PROTEON.ARPA
To:        mod.protocols.tcp-ip
Subject:   802.2 SAP's

Given as IBM has annouced their 802.5 network, those of us
who use IP are starting to think about running IP over it.
I've looked at RFC 948 (Two methods for IP over 802.3),
and it mentions the issue of using 802.2 SAP's.

With 802.5, we don't have any choice but to use SAPs. There is
no type field in the header like there was in Ethernet. There
is a SAP for IP, as well as ones for ISO and SNA. However
we don't have a SAP for ARP, or anything like it.
All three of the 802.[345] networks use 48-bit addresses,
so all of them will need ARP to map from 32 bits to 48.
(Now is not the time to start using translation tables.)

Has anybody seen any efforts in this direction from
standards bodies? Who beat up the IEEE 802.2 committee to
get the IP SAP in the first place?

It would be really nice if there were a good RFC as to how IP runs over
802.2/802.5 before a line of code gets written. Let's not
have incompatible IP's.

(Of course, maybe all this is solved by 802.1, but I doubt it.)
-------

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Oct-85 21:28:40 EDT
From:      wales@LOCUS.UCLA.EDU (Rich Wales)
To:        mod.protocols.tcp-ip
Subject:   Serial-line TCP/IP?

Has anyone implemented TCP/IP over serial lines in 4.2BSD UNIX?

We are connecting a couple of systems via a 9600-baud leased line,
and it would be wonderful if we could make them into a two-host
local network talking ARPA protocols.

I seem to remember hearing about something like this -- but I don't
remember who did it.

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@LOCUS.UCLA.EDU  -or-  wales@UCLA-LOCUS.ARPA
	UUCP:   ...!(ucbvax,ihnp4)!ucla-cs!wales

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Oct-85 23:32:09 EDT
From:      POSTEL@USC-ISIB.ARPA
To:        mod.protocols.tcp-ip
Subject:   re: serial-line ip/tcp ?


For background see RFCs 914, 916, 935.

--jon.
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Oct-85 01:01:52 EDT
From:      cperry@MITRE.ARPA (Chris Perry)
To:        mod.protocols.tcp-ip
Subject:   Re:  Serial-line TCP/IP?

I'm forwarding your note to Bryan Gorman (gorman@isid), since I
think he knows of somebody in the Washington, DC area who has
implemented a 19.2 Kbps serial IP.

Chris

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Oct-85 01:06:29 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        mod.protocols.tcp-ip
Subject:   Re:  Serial-line TCP/IP?

rick@seismo did it, ghg@purdue did a low-overhead version thereof.

	-Mike

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Oct 85 1:06:29 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        Rich Wales <wales@locus.ucla.edu>
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re:  Serial-line TCP/IP?
rick@seismo did it, ghg@purdue did a low-overhead version thereof.

	-Mike
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 1985 14:18-PDT
From:      the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
To:        wales@LOCUS.UCLA.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:        Serial-line TCP/IP?
Marshall Rose of UCI wrote something like this, suggest you
contact him.  Particulars available from NIC WHOIS.

g
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Oct-85 13:43:38 EDT
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: LH/DH-11 and IMP padding

In response to the message sent  25 Oct 85 12:41:00 PDT from  <art@acc.arpa>

Art,

Every year some poor dude relearns about IMP padding and sends a message like
yours and reminds the rest of us. This year it was you. Don't feel bad, a couple
of years ago it was me. Those who forget the lessons of history are bound to
repeat them. Or something like that.

Dave
-------

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 85 16:53:00 PDT
From:      <gary@acc.arpa>
To:        "wales" <wales@locus.ucla.edu>
Cc:        tcp-ip@sri-nic
Subject:   TCP/IP over serial lines

Thomas Ferrin (ucsfcgl!tef) at Univ. of California, San Francisco
has written a paper entitled "A Recipe for Establishing Point-to-Point
TCP/IP Network Links with 4.2 BSD Unix".  In the paper he describes
the procedures necessary for establishing a point-to-point network link.
Tom points out the necessary hardware, software, and costs of
establishing either a 9600 baud or 56 K baud dedicated link.  A working
network link between UCSF and UCB was used as a model.

ACC participated by supplying the Host Interface (the ACP 6100) at
the UCSF site.

Gary Krall/ACC
------
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Oct 85 19:47:29 PDT
From:      tencati@JPL-VLSI.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP over serial lines...

I too have a similar need.  I am looking for a TCP/IP program to connect
two vaxes running VMS.  One of the VAXes is running V3.7, the other runs
V4.2.  The software broke when JPL-VLSI went to V4.1.  At that time, host
JPL-ROBOTICS was forced off the ARPAnet.

I will check with the references already listed in responses to the UNIX 
query, but if anyone knows of a program that will run under both versions
of VMS (or at least V4.x), I would appreciate the pointers.

Thanks in advance,

Ron Tencati
JPL-VLSI.ARPA

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Oct-85 19:18:00 EST
From:      Geoff@SRI-CSL.ARPA (the tty of Geoffrey S. Goodfellow)
To:        mod.protocols.tcp-ip
Subject:   Re:        Serial-line TCP/IP?

Marshall Rose of UCI wrote something like this, suggest you
contact him.  Particulars available from NIC WHOIS.

g

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Oct-85 21:53:00 EST
From:      gary@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   TCP/IP over serial lines


Thomas Ferrin (ucsfcgl!tef) at Univ. of California, San Francisco
has written a paper entitled "A Recipe for Establishing Point-to-Point
TCP/IP Network Links with 4.2 BSD Unix".  In the paper he describes
the procedures necessary for establishing a point-to-point network link.
Tom points out the necessary hardware, software, and costs of
establishing either a 9600 baud or 56 K baud dedicated link.  A working
network link between UCSF and UCB was used as a model.

ACC participated by supplying the Host Interface (the ACP 6100) at
the UCSF site.

Gary Krall/ACC
------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27-Oct-85 01:47:29 EST
From:      tencati@JPL-VLSI.ARPA
To:        mod.protocols.tcp-ip
Subject:   TCP/IP over serial lines...


I too have a similar need.  I am looking for a TCP/IP program to connect
two vaxes running VMS.  One of the VAXes is running V3.7, the other runs
V4.2.  The software broke when JPL-VLSI went to V4.1.  At that time, host
JPL-ROBOTICS was forced off the ARPAnet.

I will check with the references already listed in responses to the UNIX 
query, but if anyone knows of a program that will run under both versions
of VMS (or at least V4.x), I would appreciate the pointers.

Thanks in advance,

Ron Tencati
JPL-VLSI.ARPA

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27-Oct-85 23:53:31 EST
From:      scott@cdp.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP and FTP for MS-DOS

I'm looking for public domain or commercial software that implements
TCP/IP and FTP on MS-DOS.  Please reply to me directly, since I'm
not on this list.

-scott
cdp!scott@SU-Glacier.arpa

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 00:34:29 EST
From:      km@emory.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP on 3B2?


Does anyone know anything firm about the availability of
TCP/IP for the 3B2? I remember a press release a while
back about TWG doing a port, but don't recall seeing a
product announcement. I also know that Sun is porting NFS
to the 3B2, but again don't know when or if it will be a
product (or if it necessarily uses TCP).


Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322

{akgua,sb1,gatech,decvax}!emory!km   USENET
km@emory                      CSNET
km.emory@csnet-relay          ARPANET

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 09:01:00 EST
From:      cain@EDN-UNIX.ARPA (Edward A. Cain)
To:        mod.protocols.tcp-ip
Subject:   Re: 802.2 SAP's

Working with Rob Rosenthal of the National Bureau of Standards, I put 
together a case for a SAP for IP using the IEEE 802 committee's rules
for standard SAP assignments -- basically arguments about universal use
and widespread deployment. The IP SAP assignment for IP was an exception
to the usual practice of assigning SAPs to "international standards".

I tried the same route for ARP a few months ago, even though ARP isn't
nearly as universal as IP. I was told: 

	1. There is a critical shortage of reserved numbers, even limiting
	them to the ISO and CCITT standards.

	2. There are a bunch of numbers available for unofficial 
	assignment, and one of these numbers ought to be picked for 
	things like ARP. A directory of these unoffical number 
	assignment is available to help avoid stepping on already 
	assigned "toes".

	3. Don't push your luck.

Ed Cain

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 1985  9:01:00 EST
From:      Edward A. Cain <cain@EDN-UNIX.ARPA>
To:        jas@proteon.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: 802.2 SAP's
Working with Rob Rosenthal of the National Bureau of Standards, I put 
together a case for a SAP for IP using the IEEE 802 committee's rules
for standard SAP assignments -- basically arguments about universal use
and widespread deployment. The IP SAP assignment for IP was an exception
to the usual practice of assigning SAPs to "international standards".

I tried the same route for ARP a few months ago, even though ARP isn't
nearly as universal as IP. I was told: 

	1. There is a critical shortage of reserved numbers, even limiting
	them to the ISO and CCITT standards.

	2. There are a bunch of numbers available for unofficial 
	assignment, and one of these numbers ought to be picked for 
	things like ARP. A directory of these unoffical number 
	assignment is available to help avoid stepping on already 
	assigned "toes".

	3. Don't push your luck.

Ed Cain


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 09:03:49 EST
From:      raklein@MITRE.ARPA (Richard Klein)
To:        mod.protocols.tcp-ip
Subject:   Re:  802.2 SAP's

The Manufacturing Automation Protocol (MAP) is an ISO based internetworking 
concept. MAP uses TP4 and IP on top of X.25 and 802.2 LLC type 1;  802.4 and
802.3 are currently supported.  Plans call for including support for 802.2 LLC
type 3 and Proway PLC.  The people at NBS (John Heafner, 301-921-3537) and the
GM Technical Center (Gary Workman, 313-575-0632) can give you more details on
the architecture, protocols, and implementation of the system.  A demo of MAP 
will be presented at the AUTOFACT 85 conference in Detroit, during the first 
week of November.

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 85 16:17:37 PST (Mon)
From:      Geoffrey H. Cooper <imagen!geof@su-shasta.arpa>
To:        shasta!DDN-REQT@GUNTER-ADAM.ARPA
Cc:        shasta!tcp-ip@sri-nic.ARPA
Subject:   Re: TCP/IP and FTP for MS-DOS

Since you asked...

    To: "Scott Weikart; Community Data Processing; 415-322-9069" <cdp!scott%glacier@shasta.UUCP>
    Subject: Re: TCP/IP and FTP for MS-DOS
    Date: 28 Oct 85 09:36:06 PST (Mon)
    
    There is a package called PC/IP from MIT -- contact (John) romkey@borax
    for details.  It is public domain and provides telnet and TFTP.  FTP is
    not supported, because the TCP implementation supports only one connection
    at a time.
    
    - Geof
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 1985 14:34:21 CST
From:      DDN-REQT@GUNTER-ADAM.ARPA
To:        "Scott Weikart; Community Data Processing; 415-322-9069" <cdp!scott@SU-GLACIER.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, DDN-REQT@GUNTER-ADAM.ARPA
Subject:   Re: TCP/IP and FTP for MS-DOS
   -------
Return-Path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: FROM SRI-NIC.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 28 Oct 85 11:00:01 CST
Received: from glacier by SRI-NIC.ARPA with TCP; Sun 27 Oct 85 20:49:09-PST
Received: by glacier with Sendmail; Sun, 27 Oct 85 20:53:31 pst
Date: Sun, 27 Oct 85 20:53:31 pst
From: "Scott Weikart; Community Data Processing; 415-322-9069" <cdp!scott@glacier>
To: tcp-ip@sri-nic.ARPA
Message-Id:  <cdp.0.16689.499317770@cdp.UUCP>
Subject:  TCP/IP and FTP for MS-DOS

I'm looking for public domain or commercial software that implements
TCP/IP and FTP on MS-DOS.  Please reply to me directly, since I'm
not on this list.

-scott
cdp!scott@SU-Glacier.arpa

   -------


If anybody comes up with good information ion this one, please make sure
the rest of wus hear about it.  're  here at the Air Force DDN PMO and
would sure like to be able to pass this kink ofd of info to our users.


Link Verstegen (DDN=-REQT@GUNTER-ADAM.ARPA)


-------
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 13:57:04 EST
From:      smoot@POP.UTEXAS.EDU (Smoot Carl-Mitchell)
To:        mod.protocols.tcp-ip
Subject:   subnet bug fixes under 4.2

I discovered a botch in my subnet implementation which I posted
about a month ago. I've updated the sources whcih are available
in ~ftp/pub/subnet.tar on sally.utexas.edu (formerly ut-sally.arpa).

In addition I added a sanity check to allow hosts with non-zero
subnets to coexist with hosts with subnet 0 on the same network.
The pertinent code changes are in if_subenable (in if_ether.c) and
in if_loop.c. (which is where the botch is).

The botch which I overlooked is in loattach (in if_loop.c).  Change
the following line:

        sin->sin_addr.s_addr = 0xff000000;

to:
        sin->sin_addr.s_addr = htonl(0xff000000);

The error is obvious and dumb.

Here is a listing of the latest version of if_subenable with the
sanity check added:

/* determine if target address is on an interface with arp subnet routing
 * enabled
 */
if_subenable(itaddr, sinterface)
struct in_addr itaddr;
struct ifnet *sinterface;
{
        struct route ro;
        struct sockaddr_in *sin;
        struct sockaddr wildcard;
        extern struct ifnet *if_ifonnetof();
 
        /* target address is on a local network */
        if (in_localaddr(itaddr)) {
                int net;
                struct ifnet *interface;
 
                net = in_netof(itaddr);
                /* sanity check - don't match if target is on the same
                 * interface the arp request came from */
                if (sinterface != NULL && net == sinterface->if_net)
                        return(0);
                interface = if_ifonnetof(net);
                if (interface == NULL) { /* this should never happen */
printf("subenable - interface not found for net - %x\n", net);
                        return(0);
                }
                return(interface->if_flags & IFF_SUBARP);
        }
        /* if target is not local then
         * look in routing table for the interface to use
         */
        sin = (struct sockaddr_in *)(&ro.ro_dst);
        sin->sin_family = AF_INET;
        sin->sin_addr = itaddr;
        ro.ro_rt = NULL;
        (void) rtalloc(&ro);
        if (ro.ro_rt != NULL
            && ((struct sockaddr_in *)(&ro.ro_rt->rt_dst))->sin_addr.s_addr != 0
            && ro.ro_rt->rt_ifp->if_flags & IFF_SUBARP
            && sinterface != ro.ro_rt->rt_ifp)
                return(1);
        return(0);
}

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 15:34:21 EST
From:      DDN-REQT@GUNTER-ADAM.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP and FTP for MS-DOS


   -------
Return-Path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: FROM SRI-NIC.ARPA BY GUNTER-ADAM.ARPA WITH TCP ; 28 Oct 85 11:00:01 CST
Received: from glacier by SRI-NIC.ARPA with TCP; Sun 27 Oct 85 20:49:09-PST
Received: by glacier with Sendmail; Sun, 27 Oct 85 20:53:31 pst
Date: Sun, 27 Oct 85 20:53:31 pst
From: "Scott Weikart; Community Data Processing; 415-322-9069" <cdp!scott@glacier>
To: tcp-ip@sri-nic.ARPA
Message-Id:  <cdp.0.16689.499317770@cdp.UUCP>
Subject:  TCP/IP and FTP for MS-DOS

I'm looking for public domain or commercial software that implements
TCP/IP and FTP on MS-DOS.  Please reply to me directly, since I'm
not on this list.

-scott
cdp!scott@SU-Glacier.arpa

   -------


If anybody comes up with good information i on this one, please make sure
the rest of w us hear about it.   're  here at the Air Force DDN PMO and
would sure like to be able to pass this kink of    d of info to our users.


Link Verstegen (DDN= -REQT@GUNTER-ADAM.ARPA)


-------

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 15:38:00 EST
From:      Vshank@WEIZMANN.BITNET (Henry Nussbacher)
To:        mod.protocols.tcp-ip
Subject:   Pc/Ip

Could someone please direct me to the Pc-Ip forum?  Is there one?  How
many different versions of Pc/Ip are there?  I now of the ones mentioned
at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem
to remember that certain sites where doing further development in this
area (especially in the 3270 emulation area).  Any leads?

Thanks,
Hank

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 19:11:15 EST
From:      leong%CMU-ITC-LINUS@PT.CS.CMU.EDU (John Leong)
To:        mod.protocols.tcp-ip
Subject:   Re: 802.2 SAP's


We have been toying around the 802.2 SAP problem for a while.

First of all, we think that RFC 948 should apply for all IP using 802.2
service quite regardless of the underlying network services (802.3,
802.4 or 802.5).

Secondly, the SAP address for IP as per assigned by IEEE is not decimal
96 as in RFC 943, Page 21. IEEE has assigned the patent 01100000 for
IP. In IEEE's notation, the least significant bit is the *leftmost*
bit (section 3.3.1.2 of 802.2). Hence 01100000 is really decimal 6.

Thirdly, having just 7 bit (exclusive of the LSB) for SAP is plain short
sighted giving only 128 SAP's. This is further reduce by the fact that
IEEE has reserved only the range X1DDDDDD (i.e 64 numbers !!). [ It
appears that X0DDDDDD is fair game for anyone ].  I asked Jon Postel
to see if he can get IEEE to get another number for ARP from IEEE. It
looks as though they are quite reluctant to assign one of their scarce
numbers for a protocol rather than a class of protocol.  So, offically,
we are kind of stuck.  There are a number of things we can do :

(a) Twist IEEE's arm until they cough up a number .....

(b) For DSAP, always use X1100000 for IP as per assigned. But for SSAP
field, we will use the un-IEEE reserved convention - X0SSSSSS : Hence
X0100000 will means IP type and X0110000 for ARP.

(c) In view of the IEEE reserved usage of SAP is for really higher level
protocol ID (or equivalent in function to the Ethernet type field),
the SSAP field essentially is redundant (unless there is such unusal
cases where we will like to have two different protocol sets communicating
directly with each other). We can, therefore, bastardise the SSAP field
for our own purpose. Hence SSAP X1100000 can be made to mean IP and
X1110000 for ARP.

My own preference is for (a) then (b).  If (a) does not produce any
result by the end of the year, I will like to produce an RFC based on(b)
to replace 948.

John Leong@*
leong@@h.cs.cmu.edu

P.S. : For those interested in the 802.5 (a..k.a. IBM token ring), there
is, in my opinion, a major oversight - I do not see a maximum packet
size specified any where!!!!  Imagine the case where different interface
cards have different buffer sizes ....... [ we then have to use 802.2's
XID to exchange buffer size information, and, of course, the format
of such exchange is not defined .....]

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Oct-85 19:17:37 EST
From:      geof@imagen.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: TCP/IP and FTP for MS-DOS


Since you asked...

    To: "Scott Weikart; Community Data Processing; 415-322-9069" <cdp!scott%glacier@shasta.UUCP>
    Subject: Re: TCP/IP and FTP for MS-DOS
    Date: 28 Oct 85 09:36:06 PST (Mon)
    
    There is a package called PC/IP from MIT -- contact (John) romkey@borax
    for details.  It is public domain and provides telnet and TFTP.  FTP is
    not supported, because the TCP implementation supports only one connection
    at a time.
    
    - Geof

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 85 08:17:00 PST
From:      <gary@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic>
Subject:   TCP/IP over serial lines

Correction:  ACC has a board capable of supporting T1 data rates which
is supported on a VAX system running 4.2.  UCSF is in the process of
purchasing a board from ACC in their point-to-point link mentioned
earlier.

Gary Krall
------
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Oct 85 22:38 O
From:      Henry Nussbacher  <Vshank%Weizmann.BITNET@WISCVM.ARPA>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Pc/Ip
Could someone please direct me to the Pc-Ip forum?  Is there one?  How
many different versions of Pc/Ip are there?  I now of the ones mentioned
at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem
to remember that certain sites where doing further development in this
area (especially in the 3270 emulation area).  Any leads?

Thanks,
Hank
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Oct-85 11:17:00 EST
From:      gary@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   TCP/IP over serial lines


Correction:  ACC has a board capable of supporting T1 data rates which
is supported on a VAX system running 4.2.  UCSF is in the process of
purchasing a board from ACC in their point-to-point link mentioned
earlier.

Gary Krall
------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Oct-85 14:17:54 EST
From:      delp@HUEY.UDEL.EDU (Gary Delp)
To:        mod.protocols.tcp-ip
Subject:   Re: Pc/Ip


>> Could someone please direct me to the Pc-Ip forum?  Is there one?  How
>> many different versions of Pc/Ip are there?  I now of the ones mentioned
>> at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem
>> to remember that certain sites where doing further development in this
>> area (especially in the 3270 emulation area).  Any leads?

There is a bboard on louie.udel.edu that discusses these issues, the
mailing address to be added to the bboard is:
pcip-request@louie.udel.edu

In addition to the MIT version, there is one from stanford that
supports multiple connections, and hence ftp.  wisconsin, and maryland
as well as udel are working on other versions.

Gary Delp
140 Evans Hall
Department of Electrical Engineering
University of Delaware
Newark DE 19716
(302) 451-6653

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 85 14:17:54 EST (Tue)
From:      Gary Delp <delp@huey.udel.EDU>
To:        Henry Nussbacher <Vshank%Weizmann.BITNET@wiscvm.wisc.EDU>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Pc/Ip

>> Could someone please direct me to the Pc-Ip forum?  Is there one?  How
>> many different versions of Pc/Ip are there?  I now of the ones mentioned
>> at SRI-NIC (TCPIP-IMPLEMENTATION.TXT if I remember correctly) but I seem
>> to remember that certain sites where doing further development in this
>> area (especially in the 3270 emulation area).  Any leads?

There is a bboard on louie.udel.edu that discusses these issues, the
mailing address to be added to the bboard is:
pcip-request@louie.udel.edu

In addition to the MIT version, there is one from stanford that
supports multiple connections, and hence ftp.  wisconsin, and maryland
as well as udel are working on other versions.

Gary Delp
140 Evans Hall
Department of Electrical Engineering
University of Delaware
Newark DE 19716
(302) 451-6653

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Oct-85 19:36:14 EST
From:      Kluger.osbunorth@XEROX.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: 802.2 SAP's


Don't Panic!

There are contributions before the 802.x committees which will fix the
problem of only 64 SAPs. 

The best contribution fixes the problem by proposing that one of the
reserved 64 saps serve as an escape, opening up another field of 40 bits
which is then used to demultiplex protocols.

(It'll work very well.)

The 802.1 contribution is by Tony Lauck <Lauck%Bergil.Dec@decwrl.Arpa>
and Arthur Harvey <GAHarvey%Bergil.Dec@decwrl.Arpa> of DEC. The best
would be for you all to go to the next meeting and support the proposal
(if you agree with it).

For more information, you can contact the proposal's authors.

=====>>>> But have an influence, go to the IEEE 802 Meetings !!!!

It is ONLY by attending the meetings that the work can be influenced.
(The reason we got into this pickle in the first place is because not
enough people with internetting experience have attended the meetings in
the past.)

The next meeting is November 11-15, '85 in Atlanta, Georgia at the
Ritz-Carlton hotel in Buckhead. Registration fee is $100 at the meeting.

Regards,

Larry Kluger
Team Leader for Internet Services
Xerox Palo Alto

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Oct-85 09:52:58 EST
From:      JNC@MIT-XX.ARPA ("J. Noel Chiappa")
To:        mod.protocols.tcp-ip
Subject:   Re: 802.2 SAP's


	Yow! Can you say 'variable length wrappers'? (Those things
give packet switches (routers) fits; unless you are prepared to copy data
around, you can always think up wierd situations in which preallocated
speace on the front of the buffer for construction of local headers isn't
big enough.)
	How on Earth did they manage to use 64 numbers anyway? Does anyone
have a list of the assigned numbers they could post? I'm wondering how
long the edifice of computer networks will last before it collapses under
the weight of its own complexity and braindamage, like some modern day
Tower of Babel.

	Noel
-------

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 85 21:02:00 PST
From:      <art@acc.arpa>
To:        "gds" <gds@sri-spam>
Cc:        tcp-ip@sri-nic
Subject:   DEC IMP interfaces

>Does anyone out there know of a board that DEC makes which can be used
>to talk to an IMP?  It would be called something like an imp11.  Also,
>are there any Unix drivers written for it?

Be aware that DEC CSS made two different IMP interfaces.  The first,
the IMP11-A, was based on a pair of DR11-B interfaces.  The second,
the IMP11-B, was based on the KMC-11 microprocessor.  The css driver
in BSD 4.2 was for the IMP11-A and I doubt it will talk to an
IMP11-B given the difference in base hardware.

				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Oct-85 18:17:16 EST
From:      gds@SRI-SPAM.ARPA (Greg Skinner)
To:        mod.protocols.tcp-ip
Subject:   DEC 1822 interface board

Does anyone out there know of a board that DEC makes which can be used
to talk to an IMP?  It would be called something like an imp11.  Also,
are there any Unix drivers written for it?

Please respond to me by mail if you know of any such board.

--gregbo

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Oct-85 20:50:07 EST
From:      gds@SRI-SPAM.ARPA (Greg Skinner)
To:        mod.protocols.tcp-ip
Subject:   imp11 1822 interface board

Thanks to all who responded.  I found the source for the driver, it's
in /sys/vaxif/if_css.c in the 4.2bsd distribution.

--gregbo

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31-Oct-85 00:02:00 EST
From:      art@ACC.ARPA
To:        mod.protocols.tcp-ip
Subject:   DEC IMP interfaces


>Does anyone out there know of a board that DEC makes which can be used
>to talk to an IMP?  It would be called something like an imp11.  Also,
>are there any Unix drivers written for it?

Be aware that DEC CSS made two different IMP interfaces.  The first,
the IMP11-A, was based on a pair of DR11-B interfaces.  The second,
the IMP11-B, was based on the KMC-11 microprocessor.  The css driver
in BSD 4.2 was for the IMP11-A and I doubt it will talk to an
IMP11-B given the difference in base hardware.

				"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31-Oct-85 04:31:59 EST
From:      BILLW@SU-SCORE.ARPA (William "Chops" Westfield)
To:        mod.protocols.tcp-ip
Subject:   Improving TCP throughput.

The Tops20 TCP implementation attempts to be "sociable" by not
sending bare ACKs.  In order to do this, whenever it receives
a packet that requires an ACK, it tells itself to wait for 250
milliseconds for some data to appear that is going in the opposite
direction so that the ACK can go with it.  On something like
a telnet connection, this can essentially half the number of
packets being sent, and so it is an excellent and widely
implemented idea.

Unfortunately, Many TCP connections are essentially "one-way".
There is never going to be any data to send in the reverse
direction to piggyback the ACK on, and the system ends up
waiting when it should send and ack immediately.
Furthermore, some TCPs (including TOPS20's) calculate their
retransmission interval based on how long it takes them to receive the
ACK for a packet they have sent.  Delaying your ACK waiting for data
disturbs this calculation, as pointed out by Alan Larson on
the TOPS20 mailing list (27-Jun-85).

Now, if the time it takes the other system to fill the window
(presumably including data transmission time) is less than the
time that your system waits to send the ACK, transmission
becomes bursty, and you get serious performance degradation.
This is aggravated by fast networks and small windows.

Such was the case on Stanford Tops20 systems (which are on ethernets)
running programs using the DEC JFN interface to TCP (which advertises
a maximum 1456 byte window).  Using FTP, for example, getting a file
transfer speed of greater than 30K bps was rare.  Using a BBN/CMU FTP
(which advertises much larger windows), higher throughputs could be
achieved (up to over 300Kbps, if irratically, and in extreme cases),
which provided additional frustration.  PUP FTP regularly beat 150Kbps.

To improve upon this situation, I have implemented a concept I call
"Interactivity".  A connection is maximally interactive if a packet is
sent every time a packet is received, and minimally interactive if it
never sends any packets.  In the first case, you want to wait a bit to
try to piggyback acks on the outgoing data, but in the second case
this introduces delays, and you want to send acks immediately.
"Inverse interactivity" can be approximated by counting the number of
packets received between each one sent.  If greater than N, it is
probably a good idea to send ACKs immediately.  [Note: Immediately in
this case mean AFTER to have chosen not to avoid sending the ACK to
prevent the Silly Window Syndrome].

After performing this operation on the local tops20 systems, FTP data
rates (using the JFN interface) as high as 150kbps were seen on the
local ethernet.  As might be expected from the above discussion, little
increase in performance was seen on connections to hosts "further
away" or on connections that used very large windows.

I am CCing this message to various mailing lists besides TOPS20 since
the idea may be useful within other TCP implementations.

[The new tops20 sources (ANAUNV, TCPBBN, TCPTCP, STG) are available
 from Sierra in <6-1-monitor>, although these modules include some
 additional TCP fixes of a less general nature.  They are also on
 Score, though those sources may be in transitory states.  This
 monitor has been running on Score and Sushi since last friday
 without any apparent ill effects.]

BillW
-------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31-Oct-85 18:43:36 EST
From:      milazzo@RICE.EDU (Paul Milazzo)
To:        mod.protocols.tcp-ip
Subject:   proNET driver for Celerity?

We would dearly love to have a proNET driver for a Celerity C1200, of
which several have recently appeared.  If you have one, or are working
on one, please let me know!  If not, could anyone estimate the
difficulty involved in writing one?  Since it is a 4.2bsd machine with
a Multibus, perhaps one could use the SUN driver for inspiration?

				Thanks,
				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX

Domain:	milazzo@rice.EDU
ARPA:	milazzo@rice.ARPA
BITNET:	milazzo@ricecsvm
UUCP:	{cbosgd,convex,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1-Nov-85 00:31:27 EST
From:      MILLS@USC-ISID.ARPA
To:        mod.protocols.tcp-ip
Subject:   Re: Improving TCP throughput.

In response to the message sent  Thu 31 Oct 85 01:31:59-PST from BILLW@SU-SCORE.ARPA

Bill,

It's refreshing to see that somebody is still brave enough to keep hacking
at TCP trying to improve performance. We have seem some awful broken
things wandering by our gateway, some of which caused massive congestion
due imappropriate choices of retransmission timeouts, packetization, etc.

Our darling fuzzballs were taught a very similar trick some time back for
the same reason - to improve throughput on low-delay nets while sustaining
good packetization efficiency on long-delay ones. However, we took a slightly
different approach. If the left window edge moves an ACK will be guaranteed
after no more than a nominal delay (about the same as yours). If the right
window edge moves more than MSS octets since the last ACK, an ACK is
forced immediately. Thus, high-volume traffic with max-size packets is
not delayed, while interactive traffic with tinygrams is delayed for
piggybacking opportunities. Using the Nagle Algorithm together with this
technique, a typist can twinkle on a keyboard with a TOPS-20 or fuzzball
(but not a 4.2) and result in one segment flipping end-for-end picking
up data, remote-echoes and ACKs as it flips. The gateways love it.

Dave
-------

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1-Nov-85 03:35:34 EST
From:      mills@DCN6.ARPA
To:        mod.protocols.tcp-ip
Subject:   Time lurches on

Folks,

They think our giant panda is pregnant, which might be a good omen. Nevertheless,
today an ionospheric glitch blitzed our WWVB radio clock and the host caring
for our WWV clock was several times off-net. Our ritzy new clock-backup
features built into the local-net protocols switched everything around so
our timestamps served to the world had nary a hiccup. However, turns out our
third backup (GOES at Ford Research) had the wrong patchcords, so they were
tracking us. The result was that we both walked the plank, but never swayed
off more than a couple of hundred milliseconds, which is an eon around here.
It was the intent that the GOES clock be the Ford primary, while their sfirst
backup be us and second backup be a WWV clock at U Michigan.

Grin while you might at all this ticking and tocking, but it's great fun and
something refreshingly different. But, as the Potomac Electic technocrat said
when I asked howcum they couldn't keep their clocks straighter, it's not a
tariffed service...

Dave
-------

END OF DOCUMENT