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 July 1985 (198 messages, 63214 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1985/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jul-85 16:52:54 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   The great leap forward

From: mills@dcn6.arpa

Folks,

The Internetional Clockwatching Weekend was a mixed bag. I was loaded for
bear, with half a dozen radios listening and machines whirring the protocols
and data recorders, when the great one-second leap (forward, backward?)
ocurred on Sunday evening. NBS radio WWV was buried in static and D-region
absorption on all frequencies, but Canadian radio CHU was beeping happily on
several frequencies. From the latter, the offset from atomic time (UT0) to
navigation time (UT1) was broadcast as -500 milliseconds before the leap and
+400 milliseconds afterward. I assume the missing 100 milliseconds was either
roundoff error or was dropped in a gateway.

Since WWV was unhearable from here at the time, the Backroom WWV radio clock
wasn't even aware of the leap until an hour and a half later, when it was
heard again and began telling the corrected time. The Pogo WWVB radio clock
took over three hours to realize something had changed, presumably due to low
signal levels from the Boulder transmitter as received here near Washington,
DC. The Ford GOES satellite clock near Detroit apparently had antenna fever,
since its quality indicator indicated confidence only to the +-500 millisecond
order. Its offset relative to the WWVB radio clock drifted lazily from +60 to
-90 millsiseconds over the weekend.

I gleefully watched the power grid, which normally wanders +-2000 milliseconds
over the 24-hour period, crank in 60 additional cycles of steam so that
ordinary synchronous-motor clocks would read correctly (are there any of these
left?). One question remains: who paid for the extra steam?

I have quite a collection of data, with raw sample offsets recorded every
sixteen seconds, formatted ASCII transcriptions, data-reduction programs (in
BASIC) and a bunch of graphics plots in gorgeous color for the Peritek (512 x
640) bit-map display. All this stuff is online, if anybody is interested.

The results demonstrate that the fuzzballs and DCNet protocols really can
synchronize clocks within a residual error of a few milliseconds. They also
demonstrate that the Heath WWV radio clock is surprisingly good and easily
makes the specifications of +-100 milliseconds in lock. In fact, most of the
time it wanders within +-30 milliseconds unsmoothed, even after nearly 24
hours without a radio fix. However, the results also demonstrate a clear lack
of functionality in all broadcast formats in that no advance notice is
provided for a leap second, even though extra bits are available in the frame.
Unless this is done, there is no way a device that must integrate information
over several minutes or hours can determine in which minute an epochal event
like a leap second occurs.

One way to solve this problem, as well as the year ambiguity (the broadcast
formats don't provide for this either, but some formats provide for a
Daylight-Savings time indicator!), is with a manual command to the radio clock
itself, which then hiccups at 23:59:60Z as required. Note that this command
must be broadcast everywhere in the net, so that all dependent host clocks
hiccup at the same time.

Dave
-------

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      01-Jul-85 17:24:19-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   The great leap forward
Folks,

The Internetional Clockwatching Weekend was a mixed bag. I was loaded for
bear, with half a dozen radios listening and machines whirring the protocols
and data recorders, when the great one-second leap (forward, backward?)
ocurred on Sunday evening. NBS radio WWV was buried in static and D-region
absorption on all frequencies, but Canadian radio CHU was beeping happily on
several frequencies. From the latter, the offset from atomic time (UT0) to
navigation time (UT1) was broadcast as -500 milliseconds before the leap and
+400 milliseconds afterward. I assume the missing 100 milliseconds was either
roundoff error or was dropped in a gateway.

Since WWV was unhearable from here at the time, the Backroom WWV radio clock
wasn't even aware of the leap until an hour and a half later, when it was
heard again and began telling the corrected time. The Pogo WWVB radio clock
took over three hours to realize something had changed, presumably due to low
signal levels from the Boulder transmitter as received here near Washington,
DC. The Ford GOES satellite clock near Detroit apparently had antenna fever,
since its quality indicator indicated confidence only to the +-500 millisecond
order. Its offset relative to the WWVB radio clock drifted lazily from +60 to
-90 millsiseconds over the weekend.

I gleefully watched the power grid, which normally wanders +-2000 milliseconds
over the 24-hour period, crank in 60 additional cycles of steam so that
ordinary synchronous-motor clocks would read correctly (are there any of these
left?). One question remains: who paid for the extra steam?

I have quite a collection of data, with raw sample offsets recorded every
sixteen seconds, formatted ASCII transcriptions, data-reduction programs (in
BASIC) and a bunch of graphics plots in gorgeous color for the Peritek (512 x
640) bit-map display. All this stuff is online, if anybody is interested.

The results demonstrate that the fuzzballs and DCNet protocols really can
synchronize clocks within a residual error of a few milliseconds. They also
demonstrate that the Heath WWV radio clock is surprisingly good and easily
makes the specifications of +-100 milliseconds in lock. In fact, most of the
time it wanders within +-30 milliseconds unsmoothed, even after nearly 24
hours without a radio fix. However, the results also demonstrate a clear lack
of functionality in all broadcast formats in that no advance notice is
provided for a leap second, even though extra bits are available in the frame.
Unless this is done, there is no way a device that must integrate information
over several minutes or hours can determine in which minute an epochal event
like a leap second occurs.

One way to solve this problem, as well as the year ambiguity (the broadcast
formats don't provide for this either, but some formats provide for a
Daylight-Savings time indicator!), is with a manual command to the radio clock
itself, which then hiccups at 23:59:60Z as required. Note that this command
must be broadcast everywhere in the net, so that all dependent host clocks
hiccup at the same time.

Dave
-------
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jul 85 18:18:42 PDT
From:      sun!l5!gnu@Berkeley (John Gilmore)
To:        tcp-ip@Berkeley
Subject:   tftp for bootstrap
Sun would like to use "standard" protocols for diskless bootstrap in
new products.  We're looking at tftp/rarp/arp as described in RFC 906
and have run into some trouble which I hope the Internet community can
shed some light on.

How do you put useful information in a name that contains only
alphanumeric characters?  We'd like to put either the machine's
internet address e.g. 192.9.1.23, or its machine type e.g. Sun-2/120,
in the name, but these both use punctuation and don't work very well if
run-together.

It's not clear how many systems will do a tftp file transfer of an
unqualified name (without any directory specified) or whether you want
to put a set of boot files in the directory it would pick for that
case.

It's not clear whether upper and/or lower case letters are possible or
preferred.

[My personal preference would be a SunRPC based boot protocol, but
SunRPC has not seen much use in the Internet yet, is not as "standard"
as tftp, and would require people to port RPC if they wanted to boot
from non-Unix machines.  How big a problem are these?]

[Note that the protocol and administrative setup required would also
be used for booting from Sun servers, thus it must be easy to set up and
explain and administer.]
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 1985 16:37-EST
From:      "Benoy P. De Souza" <benoy%suny-sb.csnet@csnet-relay.ARPA>
To:        tcp-ip@Berkeley, fa.tcp-ip
Subject:   Help needed in implementing IP in Modula-2 on 68K network.

Here at SUNY Stony Brook we have a distributed OS running on a network
of M68Ks. We call it SAM2S (Stand-Alone-Modula-2-System). The present
communication subsytem is based on XNS protocols which does not help
when everything else (at least in our LAN) being based on Unix 4.2 
speaks TCP/IP. Hence we are working on implementing TCP/IP in our kernel.

I have taken up the task of implementing the IP part (and possibly ARP
since each of these have Ethernet interfaces). I would appreciate it if
anyone could give me any pointers, help, etc. on either IP and/or ARP 
code which is documented/explained. I am at present going through 
UNIX 4.2's C code written for the VAX 750/780s. I don't have any 
documentation (except for the tutorials on IPC from UC Berkeley). Thanks.

					- Benoy De Souza
					  Computer Science, SUNY
					  Stony Brook, NY 11794
					  (516)-246-7146
					  
					  benoy@sbcs.csnet



-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jul-85 22:53:57 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   tftp for bootstrap

From: sun!l5!gnu@BERKELEY (John Gilmore)

Sun would like to use "standard" protocols for diskless bootstrap in
new products.  We're looking at tftp/rarp/arp as described in RFC 906
and have run into some trouble which I hope the Internet community can
shed some light on.

How do you put useful information in a name that contains only
alphanumeric characters?  We'd like to put either the machine's
internet address e.g. 192.9.1.23, or its machine type e.g. Sun-2/120,
in the name, but these both use punctuation and don't work very well if
run-together.

It's not clear how many systems will do a tftp file transfer of an
unqualified name (without any directory specified) or whether you want
to put a set of boot files in the directory it would pick for that
case.

It's not clear whether upper and/or lower case letters are possible or
preferred.

[My personal preference would be a SunRPC based boot protocol, but
SunRPC has not seen much use in the Internet yet, is not as "standard"
as tftp, and would require people to port RPC if they wanted to boot
from non-Unix machines.  How big a problem are these?]

[Note that the protocol and administrative setup required would also
be used for booting from Sun servers, thus it must be easy to set up and
explain and administer.]

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed 3 Jul 85 01:16:57-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        sun!l5!gnu@Berkeley, tcp-ip@Berkeley
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: tftp for bootstrap
	MIT has used TFTP to boot diskless gateways for about 5 years
now. It works quite well. We really like TFTP since it is a standard
IP protocol and machines usually come with server TFTP implementations.
	We handle the 'punctuation characters' problem by using a file
name that consists of the IP address with all the fields three characters
long; thus, a gateway at 18.10.0.11 would boot from a file named
'018010000011'. (Actually, we use octal because we are wierd, but you
get the idea).
	In general, we use built in configuration information, kept in
some non-volatile storage. While you can avoid this on an Ethernet
with broadcast, this method does not work on non-broadcast nets. In
general, the spirit of IP is that the 'base solution' to any problem
should work on a non-broadcast net with no gateways. We thus feel that
having some small non-volatile store for information such as which
directories to look in on which hosts is reasonable.

	Noel
-------
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 02:13:04 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	MIT has used TFTP to boot diskless gateways for about 5 years
now. It works quite well. We really like TFTP since it is a standard
IP protocol and machines usually come with server TFTP implementations.
	We handle the 'punctuation characters' problem by using a file
name that consists of the IP address with all the fields three characters
long; thus, a gateway at 18.10.0.11 would boot from a file named
'018010000011'. (Actually, we use octal because we are wierd, but you
get the idea).
	In general, we use built in configuration information, kept in
some non-volatile storage. While you can avoid this on an Ethernet
with broadcast, this method does not work on non-broadcast nets. In
general, the spirit of IP is that the 'base solution' to any problem
should work on a non-broadcast net with no gateways. We thus feel that
having some small non-volatile store for information such as which
directories to look in on which hosts is reasonable.

	Noel
-------

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 07:01:35 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Help needed in implementing IP in Modula-2 on 68K network.

From: "Benoy P. De Souza" <benoy%suny-sb.csnet@csnet-relay.ARPA>


Here at SUNY Stony Brook we have a distributed OS running on a network
of M68Ks. We call it SAM2S (Stand-Alone-Modula-2-System). The present
communication subsytem is based on XNS protocols which does not help
when everything else (at least in our LAN) being based on Unix 4.2 
speaks TCP/IP. Hence we are working on implementing TCP/IP in our kernel.

I have taken up the task of implementing the IP part (and possibly ARP
since each of these have Ethernet interfaces). I would appreciate it if
anyone could give me any pointers, help, etc. on either IP and/or ARP 
code which is documented/explained. I am at present going through 
UNIX 4.2's C code written for the VAX 750/780s. I don't have any 
documentation (except for the tutorials on IPC from UC Berkeley). Thanks.

					- Benoy De Souza
					  Computer Science, SUNY
					  Stony Brook, NY 11794
					  (516)-246-7146
					  
					  benoy@sbcs.csnet

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed 3 Jul 85 10:35:02-PDT
From:      LYNCH@SRI-KL.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   MAP Protocol
I see that Boeing is going to have a demonstration of interconnecting
the 802.4 LAN protocls with the 802.3 LAN protocols in November at
the Automotive factory automation show.  How does one find out what
MAP is?  GM is making a big fuss (as did DoD) about being able to 
interconnect products they buy.  It sure was nice of them to dream up
a different set of protocols...  Guess I'd better learn about them.
So, the question is: where does one get the info?

Thanks,
Dan
-------
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1985 11:55:06 PDT
From:      POSTEL@USC-ISIF.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   IP/TCP Protocol Specifications

Folks:

The protocol specifications for the IP/TCP family of protocols are in
the Internet Protocol Transition Workbook, the Internet Protocol
Implementation Guide, the Internet Protocol Telnet Protocol and
Options, and the Internet Mail Protocols volumes.  These volumes
contain most of the protocols used in the ARPA-Internet community.
The Assigned Numbers (RFC-943) and Official Protocols (RFC-944) notes
provide a index and annotated index to the protocols.  All these above
are available from the Network Information Center (send a note to
NIC@SRI-NIC.ARPA).

Several of the Internet Protocol documents have now been issued as
military standards (MIL-STDs).  The MIL-STDs listed below are the
official DoD versions of these commmunication protocols and should be
consulted for any DoD implementations.

	Internet Protocol (IP)  		MIL-STD-1777
	Transmission Control Protocol (TCP)	MIL-STD-1778
	File Transfer Protocol (FTP)		MIL-STD-1780
	Simple Mail Transfer Protocol (SMTP)	MIL-STD-1781
	Telnet Protocol and Options (TELNET)	MIL-STD-1782

These documents may be ordered from:

	Naval Publications and Forms Center, Code 3015
	5801 Tabor Ave
	Philadelphia, PA 19120
	1-215-697-3321

Requests can be initiated by telephone, telegraph, or mail; however,
it is preferred that private industry use form DD1425, if possible.

The ARPA specifications for IP (RFC-791) and TCP (RFC-793) and the DoD
specifications above are intended to describe exactly the same
protocols.  Any difference in the protocols specified by these sets of
documents should be reported to DCA and to ARPA.  The RFCs and the
MIL-STDs for IP and TCP differ in style and level of detail.  It is
strongly advised that the two sets of documents be used together.  The
ARPA and the DoD specifications for the FTP, SMTP, and Telnet
protocols are essentially the same documents (RFCs 765, 821, 854).
The MIL-STD versions have been edited slightly.  Implementers should
also check the "Official Protocols" memo for comments on protocol
status or pending changes (RFC 944).

--jon.
-------
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 1985 1548-PDT (Wednesday)
From:      Jeff Mogul <mogul@Navajo>
To:        tcp-ip@sri-nic.ARPA
Cc:        sun!l5!gnu@Berkeley (John Gilmore)
Subject:   Re: tftp for bootstrap
One thing you might want to consider is a multi-stage bootstrap, where
TFTP is used to load a small program that then determines (via NFS
or whatever you prefer) what the host's configuration should be.

For example, we have Suns here that run the V-system (instead of
Sun Unix.)  They load a short program called Vload, using whatever
protocol Suns bootload with.  Vload then reads a configuration
file (located using the hardware ethernet address as an identifier)
which says what programs should really be loaded.  Vload uses
the V protocols (which is unfortunate but that's another story)
to read the config file and load the real program; all that is
needed from the original bootstrap protocol is the ability to
load the second-phase bootstrap program.

The point here is that the non-volatile storage need not reside
on the workstation or whatever; as long as the first-phase boot
program can find a database on some server, either by broadcast
or by wiring the server address into the code, the rest is
just a matter of chasing pointers.

I think TFTP is preferable to ND or NFS or FTP or whatever because
it's extremely simple, which is important when it has to be squeezed
into a ROM, and because it's widely available, unlike certain
manufacturers' proprietary protocols.  If you only care about
loading Suns as Suns, then using NFS might make sense because
of efficiency or convenience; if you care about loading a variety
of hosts with a variety of operating systems, then TFTP makes
more sense because it's simpler and more available.

As to the problem of default directories:  perhaps what we
need is to separate the TFTP protocol from the intended use.
TFTP is currently expected to listen on port 69, but there
is no reason why a TFTP-based boot server couldn't listen on
some other port; the port-69 server would not need a default
directory, while the behaviour of the port-XX server would be
defined so that alphanumeri-only file names would refer to a
default directory.  Alternatively (this is what our pseudo-ND
server does), the TFTP-boot server might be allowed to look
at the requesting host address to look up in a database which
file to download.
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed,  3 Jul 85 15:07:26 EDT
From:      jas@proteon.arpa
To:        sun!l5!gnu@Berkeley (John Gilmore)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: tftp for bootstrap
I'd agree with Noel about the need to some small EAROM or such
for the configuration data.

You might consider using the domain nameserver protocols to get
additional information beyond that in the EAROM. (I don't love
these protocols, but I guess there here for good now...) The HINFO
record has the CPU type and O/S. You might invent a new
record type for booting information. (Sometimes is it better
to tweak an existing protocl a little than develop a new one.)
Of course, this requires keeping the address of a domain nameserver
in EAROM.

My TFTP does have a default directory, but I suspect that this is
very rare. Most need fully qualified names. I suspect that servers
are case sensitive if the O/S behind them is, otherwise not.

I suspect the hard facts of life would point at some amount of data
being kept in EAROM (or EPROM). Once you surrender this point,
the rest gets rather easy.
-------

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 15:28:48 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   MAP Protocol

From: LYNCH@SRI-KL.ARPA

I see that Boeing is going to have a demonstration of interconnecting
the 802.4 LAN protocls with the 802.3 LAN protocols in November at
the Automotive factory automation show.  How does one find out what
MAP is?  GM is making a big fuss (as did DoD) about being able to 
interconnect products they buy.  It sure was nice of them to dream up
a different set of protocols...  Guess I'd better learn about them.
So, the question is: where does one get the info?

Thanks,
Dan
-------

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jul 85 16:27:32 EDT
From:      Jim Berets <jberets@BBN-VAX.ARPA>
To:        LYNCH@SRI-KL.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, jberets@BBN-VAX.ARPA
Subject:   Re:  MAP Protocol
"The Manufacturing Automation Protocol document is based on existing
and proposed national standards for Local Area Networks.  [The] document
has been and will continue to be updated as new national standards
are approved."
		-- from MAP documentation foreword

For information on MAP (Manufacturing Automation Protocol), trying
writing to:

MAP Chairman
General Motors Technical Center
Manufacturing Building, A/MD-39
30300 Mound Road
Warren, MI   48090-9040

Jim
jberets@bbn-vax.arpa
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 16:37:40 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   IP/TCP Protocol Specifications

From: POSTEL@USC-ISIF.ARPA


Folks:

The protocol specifications for the IP/TCP family of protocols are in
the Internet Protocol Transition Workbook, the Internet Protocol
Implementation Guide, the Internet Protocol Telnet Protocol and
Options, and the Internet Mail Protocols volumes.  These volumes
contain most of the protocols used in the ARPA-Internet community.
The Assigned Numbers (RFC-943) and Official Protocols (RFC-944) notes
provide a index and annotated index to the protocols.  All these above
are available from the Network Information Center (send a note to
NIC@SRI-NIC.ARPA).

Several of the Internet Protocol documents have now been issued as
military standards (MIL-STDs).  The MIL-STDs listed below are the
official DoD versions of these commmunication protocols and should be
consulted for any DoD implementations.

	Internet Protocol (IP)  		MIL-STD-1777
	Transmission Control Protocol (TCP)	MIL-STD-1778
	File Transfer Protocol (FTP)		MIL-STD-1780
	Simple Mail Transfer Protocol (SMTP)	MIL-STD-1781
	Telnet Protocol and Options (TELNET)	MIL-STD-1782

These documents may be ordered from:

	Naval Publications and Forms Center, Code 3015
	5801 Tabor Ave
	Philadelphia, PA 19120
	1-215-697-3321

Requests can be initiated by telephone, telegraph, or mail; however,
it is preferred that private industry use form DD1425, if possible.

The ARPA specifications for IP (RFC-791) and TCP (RFC-793) and the DoD
specifications above are intended to describe exactly the same
protocols.  Any difference in the protocols specified by these sets of
documents should be reported to DCA and to ARPA.  The RFCs and the
MIL-STDs for IP and TCP differ in style and level of detail.  It is
strongly advised that the two sets of documents be used together.  The
ARPA and the DoD specifications for the FTP, SMTP, and Telnet
protocols are essentially the same documents (RFCs 765, 821, 854).
The MIL-STD versions have been edited slightly.  Implementers should
also check the "Official Protocols" memo for comments on protocol
status or pending changes (RFC 944).

--jon.
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 17:46:42 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: jas@proteon.arpa

I'd agree with Noel about the need to some small EAROM or such
for the configuration data.

You might consider using the domain nameserver protocols to get
additional information beyond that in the EAROM. (I don't love
these protocols, but I guess there here for good now...) The HINFO
record has the CPU type and O/S. You might invent a new
record type for booting information. (Sometimes is it better
to tweak an existing protocl a little than develop a new one.)
Of course, this requires keeping the address of a domain nameserver
in EAROM.

My TFTP does have a default directory, but I suspect that this is
very rare. Most need fully qualified names. I suspect that servers
are case sensitive if the O/S behind them is, otherwise not.

I suspect the hard facts of life would point at some amount of data
being kept in EAROM (or EPROM). Once you surrender this point,
the rest gets rather easy.
-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 18:47:59 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  MAP Protocol

From: Jim Berets <jberets@BBN-VAX.ARPA>

"The Manufacturing Automation Protocol document is based on existing
and proposed national standards for Local Area Networks.  [The] document
has been and will continue to be updated as new national standards
are approved."
		-- from MAP documentation foreword

For information on MAP (Manufacturing Automation Protocol), trying
writing to:

MAP Chairman
General Motors Technical Center
Manufacturing Building, A/MD-39
30300 Mound Road
Warren, MI   48090-9040

Jim
jberets@bbn-vax.arpa

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jul-85 21:26:21 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: Jeff Mogul <mogul@Navajo>

One thing you might want to consider is a multi-stage bootstrap, where
TFTP is used to load a small program that then determines (via NFS
or whatever you prefer) what the host's configuration should be.

For example, we have Suns here that run the V-system (instead of
Sun Unix.)  They load a short program called Vload, using whatever
protocol Suns bootload with.  Vload then reads a configuration
file (located using the hardware ethernet address as an identifier)
which says what programs should really be loaded.  Vload uses
the V protocols (which is unfortunate but that's another story)
to read the config file and load the real program; all that is
needed from the original bootstrap protocol is the ability to
load the second-phase bootstrap program.

The point here is that the non-volatile storage need not reside
on the workstation or whatever; as long as the first-phase boot
program can find a database on some server, either by broadcast
or by wiring the server address into the code, the rest is
just a matter of chasing pointers.

I think TFTP is preferable to ND or NFS or FTP or whatever because
it's extremely simple, which is important when it has to be squeezed
into a ROM, and because it's widely available, unlike certain
manufacturers' proprietary protocols.  If you only care about
loading Suns as Suns, then using NFS might make sense because
of efficiency or convenience; if you care about loading a variety
of hosts with a variety of operating systems, then TFTP makes
more sense because it's simpler and more available.

As to the problem of default directories:  perhaps what we
need is to separate the TFTP protocol from the intended use.
TFTP is currently expected to listen on port 69, but there
is no reason why a TFTP-based boot server couldn't listen on
some other port; the port-69 server would not need a default
directory, while the behaviour of the port-XX server would be
defined so that alphanumeri-only file names would refer to a
default directory.  Alternatively (this is what our pseudo-ND
server does), the TFTP-boot server might be allowed to look
at the requesting host address to look up in a database which
file to download.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 1985 0925-PDT (Friday)
From:      lewis <lewis@sri-tsc>
To:        Jeff Mogul <mogul@Navajo>
Cc:        sun!l5!gnu@Berkeley (John Gilmore), tcp-ip@sri-nic.ARPA
Subject:   Re: tftp for bootstrap
We have been using a loader server for several years to load TIUs, BBN
and Jeff Mogul also use versions of it to load GWYs. In our user testbeds,
the same physical hardware is a multifunction box, depending on which
module is loaded. We have found that the users often complained that
the server was down, when in fact they specified improper file name
syntax. This caused us to come up with two changes.

There is a data base on the server hosts, which maps requestor's
internet IDs to load file names (TOPS20 or Unix pathnames, depending on
server).  Wildcards in the database for Internet IDs exist to shorten
the list.  A default load then retrieves the file found in the
database.  In addition, Internet IDs with or without wildcards can be
paired with another database file name, allowing separation of database
administration for different hosts and ranges of hosts. Alternatively,
the user can specify a file name to be loaded from the server.

The first change involves finding the file to boot. If the user specifies
any file, the database is not queried. To make it easier for the user
to remember how to specify file names, we now allow suffixes to be left
off and uppercase is converted to lower, and preceding blanks
( MYLOAD is myload.ext). In this case the default directory is searched.
If the file name requested begins with a system directory delimiter,
"<" on TOPS20 or "/" on Unix, the server takes the request literally,
for people who supposedly know what they want.

The second change, not implemented yet, is to return a text string to
indicate the status. Currently, if the file is not found, the only
perception the user has is the three minute timeout. The string packet
should probably be allowed asynchronously with loading progress.
It could report (file not found / illegal file name / file broken / etc.).

The servee code resides in about 6K bytes nonvolatile memory, and the
internet address is used as the database key for default booting.
Probably some mechanism for privacy/accounting should be considered.

-Mark Lewis

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      05 Jul 85 10:05:51 EDT (Fri)
From:      Dennis Rockwell <drockwel@CSNET-SH.ARPA>
To:        tcp-ip@SRI-NIC.ARPA, xni-list@CSNET-RELAY.ARPA, gateway@BBNCCM.ARPA
Cc:        cic@CSNET-SH.ARPA
Subject:   gateway confusion
Folks,

If your connections to hosts on CSNET-PDN seem a bit strained this week,
here's why: the core gateways are confused about it, and will point you
in the wrong direction, then tell you that you can't get there from here.

If you are on the ARPAnet, please tell your host to get to 192.5.58 though
10.4.0.5.  If not, or if you cannot change your routing tables, please
send mail through csnet-relay using either <@csnet-relay.arpa:dbj@rice.arpa>
or dbj%rice@csnet-relay.arpa (to use a prime victim as an example).

To the XNI people: please route your outgoing mail through csnet-relay for
the duration (ie, tcp-ip%nic@csnet-relay).

The gateway team is working on it, after being dragged unceremoniously out
of bed (this is a BBN holiday; I'm only here myself because of this).

Dennis Rockwell
CSNET Technical Staff

PS: the really bizarre thing is that RICE-NET is perfectly reachable; both
RICE-NET and CSNET-PDN are advertised by Paul Kirton's EGP running on
CSNET-RELAY.
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 85 10:27 EDT
From:      dca-pgs @ DDN1.ARPA
To:        LYNCH @ sri-kl.arpa
Cc:        tcp-ip @ sri-nic.arpa
Subject:   Re:  MAP Protocol

I heard that Unisoft was working on the NBS Transport
Protocol, to run under 4.2. I don't recall whether they
were involved in last year's NCC demo or not. 
Last handle I have for Unisoft is <unisoft!unisoft@Berkeley>;
also, they are located in Berkeley CA if anyone wants to
call them.

Anybody know if Wollongong is doing anything in this area?

Best,
-Pat Sullivan
 DCEC, Reston, VA.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 85 10:37 EDT
From:      dca-pgs @ DDN1.ARPA
To:        tcp-ip @ sri-nic.arpa, info-unix @ brl.arpa, telecom @ bbncca.arpa
Subject:   $946M NSA/AT&T Contract for 3BXX's

News of this came out in this week's MIS Week.
Anybody have a clue on what kind of networking (if any)
was specified for these 3B's? AT&T's attitude towards
TCP/IP et al has been somewhat unclear, but for a billion-
dollar contract, I'm sure they could do a lot of adapting.

Thanks,
Pat Sullivan
DCEC, Reston, VA.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jul-85 11:08:13 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   gateway confusion

From: Dennis Rockwell <drockwel@CSNET-SH.ARPA>

Folks,

If your connections to hosts on CSNET-PDN seem a bit strained this week,
here's why: the core gateways are confused about it, and will point you
in the wrong direction, then tell you that you can't get there from here.

If you are on the ARPAnet, please tell your host to get to 192.5.58 though
10.4.0.5.  If not, or if you cannot change your routing tables, please
send mail through csnet-relay using either <@csnet-relay.arpa:dbj@rice.arpa>
or dbj%rice@csnet-relay.arpa (to use a prime victim as an example).

To the XNI people: please route your outgoing mail through csnet-relay for
the duration (ie, tcp-ip%nic@csnet-relay).

The gateway team is working on it, after being dragged unceremoniously out
of bed (this is a BBN holiday; I'm only here myself because of this).

Dennis Rockwell
CSNET Technical Staff

PS: the really bizarre thing is that RICE-NET is perfectly reachable; both
RICE-NET and CSNET-PDN are advertised by Paul Kirton's EGP running on
CSNET-RELAY.

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jul-85 11:53:00 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  MAP Protocol

From: dca-pgs@DDN1.ARPA


I heard that Unisoft was working on the NBS Transport
Protocol, to run under 4.2. I don't recall whether they
were involved in last year's NCC demo or not. 
Last handle I have for Unisoft is <unisoft!unisoft@Berkeley>;
also, they are located in Berkeley CA if anyone wants to
call them.

Anybody know if Wollongong is doing anything in this area?

Best,
-Pat Sullivan
 DCEC, Reston, VA.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jul-85 12:34:58 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   46M NSA/AT&T Contract for 3BXX's

From: dca-pgs@DDN1.ARPA


News of this came out in this week's MIS Week.
Anybody have a clue on what kind of networking (if any)
was specified for these 3B's? AT&T's attitude towards
TCP/IP et al has been somewhat unclear, but for a billion-
dollar contract, I'm sure they could do a lot of adapting.

Thanks,
Pat Sullivan
DCEC, Reston, VA.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri 5 Jul 85 12:46:35-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        lewis@SRI-TSC.ARPA, mogul@SU-NAVAJO.ARPA
Cc:        sun!l5!gnu@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: tftp for bootstrap
	You mentioned the lack of error messages; TFTP already provides
them, and the bootstrap we run prints them.
-------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jul-85 13:15:26 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: lewis <lewis@sri-tsc>

We have been using a loader server for several years to load TIUs, BBN
and Jeff Mogul also use versions of it to load GWYs. In our user testbeds,
the same physical hardware is a multifunction box, depending on which
module is loaded. We have found that the users often complained that
the server was down, when in fact they specified improper file name
syntax. This caused us to come up with two changes.

There is a data base on the server hosts, which maps requestor's
internet IDs to load file names (TOPS20 or Unix pathnames, depending on
server).  Wildcards in the database for Internet IDs exist to shorten
the list.  A default load then retrieves the file found in the
database.  In addition, Internet IDs with or without wildcards can be
paired with another database file name, allowing separation of database
administration for different hosts and ranges of hosts. Alternatively,
the user can specify a file name to be loaded from the server.

The first change involves finding the file to boot. If the user specifies
any file, the database is not queried. To make it easier for the user
to remember how to specify file names, we now allow suffixes to be left
off and uppercase is converted to lower, and preceding blanks
( MYLOAD is myload.ext). In this case the default directory is searched.
If the file name requested begins with a system directory delimiter,
"<" on TOPS20 or "/" on Unix, the server takes the request literally,
for people who supposedly know what they want.

The second change, not implemented yet, is to return a text string to
indicate the status. Currently, if the file is not found, the only
perception the user has is the three minute timeout. The string packet
should probably be allowed asynchronously with loading progress.
It could report (file not found / illegal file name / file broken / etc.).

The servee code resides in about 6K bytes nonvolatile memory, and the
internet address is used as the database key for default booting.
Probably some mechanism for privacy/accounting should be considered.

-Mark Lewis

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jul-85 14:01:07 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	You mentioned the lack of error messages; TFTP already provides
them, and the bootstrap we run prints them.
-------

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jul 85 21:36:33 EDT
From:      Ron Natalie <ron@BRL.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ALMOST PUBLIC DOMAIN GATEWAY CODE
The BRL gateway code and it's related operating system LOS is available
for public FTP in the file arch/gw.tar on BRL-VGR.  This code is restricted
as government-owned.  Which means you can use it, spread it around, etc...,
but when it comes to charging money for it, there are some restrictions.
If anybody cares to know, send me a note.

The BRL gateway is a full IP gateway, supporting fragmentation, and all
IP options (such as they are).  It will run on any PDP-11 with memory
management.  We have sucessfully run it on PDP-11/34's and 11/70's as
well as LSI-11/23's.  Interfaces currently supported are IMPs on class
A or B networks, Ethernet with ARP using the Interlan boards, Proteon
V2LNI, DEC PCL-11B, and NSC Hyperchannel.  A rather customized EGP
exists to conform the idiosyncracies of the core gateway system.

Current shortcomings are:
	1.  Only one ETHERNET can currently be supported at a time.
	2.  No ICMP timestamp support.
	3.  Does not send ICMP redirects.
	4.  Device drivers do not currently turn of routes for dead
	    devices.
	5.  Documentation is sketchy, but is being revised.
	6.  Currently requires some media to boot off of (like floppies
		or RK05's).
	
I'd be willing to take back any bug fixes and/or (cough) enhancements,
provided that I could impose the same distribution requirements on them
as the rest of the code.

C'mon take that load off your VAX and  Hack Away

-Ron
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jul-85 22:20:39 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   ALMOST PUBLIC DOMAIN GATEWAY CODE

From: Ron Natalie <ron@BRL.ARPA>

The BRL gateway code and it's related operating system LOS is available
for public FTP in the file arch/gw.tar on BRL-VGR.  This code is restricted
as government-owned.  Which means you can use it, spread it around, etc...,
but when it comes to charging money for it, there are some restrictions.
If anybody cares to know, send me a note.

The BRL gateway is a full IP gateway, supporting fragmentation, and all
IP options (such as they are).  It will run on any PDP-11 with memory
management.  We have sucessfully run it on PDP-11/34's and 11/70's as
well as LSI-11/23's.  Interfaces currently supported are IMPs on class
A or B networks, Ethernet with ARP using the Interlan boards, Proteon
V2LNI, DEC PCL-11B, and NSC Hyperchannel.  A rather customized EGP
exists to conform the idiosyncracies of the core gateway system.

Current shortcomings are:
	1.  Only one ETHERNET can currently be supported at a time.
	2.  No ICMP timestamp support.
	3.  Does not send ICMP redirects.
	4.  Device drivers do not currently turn of routes for dead
	    devices.
	5.  Documentation is sketchy, but is being revised.
	6.  Currently requires some media to boot off of (like floppies
		or RK05's).
	
I'd be willing to take back any bug fixes and/or (cough) enhancements,
provided that I could impose the same distribution requirements on them
as the rest of the code.

C'mon take that load off your VAX and  Hack Away

-Ron

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Jul 85 17:25:04 edt
From:      BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To:        dca-pgs@DDN1.ARPA, info-unix@BRL.ARPA, tcp-ip@SRI-NIC.ARPA, telecom@BBNCCA.ARPA
Subject:   Re:  $946M NSA/AT&T Contract for 3BXX's
Here's a note (in full) that I just sent out to INFO-3B which may
shed some light on all this:

---------------



THE WOLLONGONG GROUP
NEWS BUREAU (i guess now that UPI is in trouble...:-)

For Immediate release (05/03/85)

		 WOLLONGONG SIGNS AGREEMENT WITH AT&T

PALO ALTO, Calif. -- To expand communications  through  AT&T  computers,
The  Wollongong  Group  and  AT&T  have  signed an agreement under which
Wollongong  will  provide  its  standard  networking  product   for   3B
supermicro and supermini computer under UNIX System V.

"Wollongong's  software  products  will have the required Department of
Defense standard  interface  services  for  3B  users,"  said  David  J.
Preston,   director   of  marketing  and  sales  for  Wollongong.  Among
capabilities to be provided are:

	--File transfer (FTP)
	--Electronic mail (SMTP)
	--Virtual terminal (TELNET).

"As a result, 3B users will be able to communicate over a  multitude  of
networks,"  said  Preston,  including  Ethernet  (trademarked  by  Xerox
Corporation), ARPANET, MILNET, the defense Data Network,  point-to-point
nets, and custom-designed networking systems.

"Delivering  this  advanced  standard of networking software to the UNIX
System marketplace is an important step in AT&T's program  to  become  a
significant   industry   supplier   of   high-quality,  state-of-the-art
computing and communication  systems,"  stated  JoAnne  Miller,  product
manager of 3B Networking Software. " This product family is another step
in AT&T's overall strategy of continuing to provide and  support  system
capabilities with the special advantage of adherence to current software
standards," Miller continued.

				 # # #

In what I am sure is a completely unrelated article from today's
WSJ (7/1) page 6 col 6:

AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK

NEW  YORK  -  American Telephone & Telegraph Co.'s new computer contract
with the Defense Department's National Security Agency is  broader  than
previously announced.

Government officials and sources close to the bidding said the agreement
includes  software  development  and  sales  of  computer  networks  and
accessories.   Earlier, the agency's officials said the contract, valued
at as much as $946  million  through  1988,  covered  mainly  sales  and
service  of  as  many as 250 minicomputers of AT&T's 3B line, introduced
last year.

An NSA spokesman said the intelligence agency increased its estimate  of
how many minicomputers it will buy under the contract to as many as 325.

The  spokesman said final bidding was between AT&T and Digital Equipment
Corp.  Sources  said  the  decision  was   based   more   on   technical
considerations  than  on cost. International Business Machines Corp. was
eliminated earlier, a source said.

(that's all of it, Yow, my fingers hurt)

	-Barry Shein, Boston University

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Jul-85 21:49:59 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  46M NSA/AT&T Contract for 3BXX's

From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>

Here's a note (in full) that I just sent out to INFO-3B which may
shed some light on all this:

---------------



THE WOLLONGONG GROUP
NEWS BUREAU (i guess now that UPI is in trouble...:-)

For Immediate release (05/03/85)

		 WOLLONGONG SIGNS AGREEMENT WITH AT&T

PALO ALTO, Calif. -- To expand communications  through  AT&T  computers,
The  Wollongong  Group  and  AT&T  have  signed an agreement under which
Wollongong  will  provide  its  standard  networking  product   for   3B
supermicro and supermini computer under UNIX System V.

"Wollongong's  software  products  will have the required Department of
Defense standard  interface  services  for  3B  users,"  said  David  J.
Preston,   director   of  marketing  and  sales  for  Wollongong.  Among
capabilities to be provided are:

	--File transfer (FTP)
	--Electronic mail (SMTP)
	--Virtual terminal (TELNET).

"As a result, 3B users will be able to communicate over a  multitude  of
networks,"  said  Preston,  including  Ethernet  (trademarked  by  Xerox
Corporation), ARPANET, MILNET, the defense Data Network,  point-to-point
nets, and custom-designed networking systems.

"Delivering  this  advanced  standard of networking software to the UNIX
System marketplace is an important step in AT&T's program  to  become  a
significant   industry   supplier   of   high-quality,  state-of-the-art
computing and communication  systems,"  stated  JoAnne  Miller,  product
manager of 3B Networking Software. " This product family is another step
in AT&T's overall strategy of continuing to provide and  support  system
capabilities with the special advantage of adherence to current software
standards," Miller continued.

				 # # #

In what I am sure is a completely unrelated article from today's
WSJ (7/1) page 6 col 6:

AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK

NEW  YORK  -  American Telephone & Telegraph Co.'s new computer contract
with the Defense Department's National Security Agency is  broader  than
previously announced.

Government officials and sources close to the bidding said the agreement
includes  software  development  and  sales  of  computer  networks  and
accessories.   Earlier, the agency's officials said the contract, valued
at as much as $946  million  through  1988,  covered  mainly  sales  and
service  of  as  many as 250 minicomputers of AT&T's 3B line, introduced
last year.

An NSA spokesman said the intelligence agency increased its estimate  of
how many minicomputers it will buy under the contract to as many as 325.

The  spokesman said final bidding was between AT&T and Digital Equipment
Corp.  Sources  said  the  decision  was   based   more   on   technical
considerations  than  on cost. International Business Machines Corp. was
eliminated earlier, a source said.

(that's all of it, Yow, my fingers hurt)

	-Barry Shein, Boston University

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Jul-85 21:49:59 EDT
From:      ihnp4!ihnp1!packard!Postmaster@Berkeley (Mail Delivery Subsystem)
To:        ihnp4!ucbvax!tcp-ip@Berkeley, Postmaster@Berkeley
Subject:   Returned mail: User unknown
   ----- Transcript of session follows -----
Postmaster... aliased to  ggr
ggr... aliased to  nomad!ggr
ihnp1!archimedes,ihnp1!unicorn... Connecting to ihnp1.dk...
220 ihnp1.ATT.UUCP Sendmail 4.12/9-Jan-85 ready at 9 Jul 85 10:17:30 CDT (Tue)
>>> HELO py/garage/packard.DK
250 ihnp1.ATT.UUCP Hello py/garage/packard.DK, pleased to meet you
>>> MAIL From:<packard!ihnp4!ucbvax!tcp-ip>
250 <packard!ihnp4!ucbvax!tcp-ip>... Sender ok
>>> RCPT To:<unicorn>
550 /usr/lib/uucp/mail/unicorn... Can't create output: Permission denied
ihnp1!unicorn... User unknown
>>> RCPT To:<archimedes>
550 /usr/lib/uucp/mail/archimedes... Can't create output: Permission denied
ihnp1!archimedes... User unknown
>>> QUIT
221 ihnp1.ATT.UUCP closing connection
packard!ihnp1!ihnp4!ucbvax!tcp-ip... duplicate suppressed

   ----- Unsent message follows -----
Date: Sat, 6-Jul-85 21:49:59 EDT
From: ucbvax.ARPA!tcp-ip
Subject: Re:  46M NSA/AT&T Contract for 3BXX's
Message-Id: <8837@ucbvax.ARPA>
Received: by py/garage/packard.DK; 8507091519
Errors-To: Postmaster
Sender: ihnp4!ucbvax!tcp-ip
Newsgroups: fa.tcp-ip
Organization: University of California at Berkeley
Apparently-To: ihnp1!unicorn
Apparently-To: ihnp1!archimedes

From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>

Here's a note (in full) that I just sent out to INFO-3B which may
shed some light on all this:

---------------



THE WOLLONGONG GROUP
NEWS BUREAU (i guess now that UPI is in trouble...:-)

For Immediate release (05/03/85)

		 WOLLONGONG SIGNS AGREEMENT WITH AT&T

PALO ALTO, Calif. -- To expand communications  through  AT&T  computers,
The  Wollongong  Group  and  AT&T  have  signed an agreement under which
Wollongong  will  provide  its  standard  networking  product   for   3B
supermicro and supermini computer under UNIX System V.

"Wollongong's  software  products  will have the required Department of
Defense standard  interface  services  for  3B  users,"  said  David  J.
Preston,   director   of  marketing  and  sales  for  Wollongong.  Among
capabilities to be provided are:

	--File transfer (FTP)
	--Electronic mail (SMTP)
	--Virtual terminal (TELNET).

"As a result, 3B users will be able to communicate over a  multitude  of
networks,"  said  Preston,  including  Ethernet  (trademarked  by  Xerox
Corporation), ARPANET, MILNET, the defense Data Network,  point-to-point
nets, and custom-designed networking systems.

"Delivering  this  advanced  standard of networking software to the UNIX
System marketplace is an important step in AT&T's program  to  become  a
significant   industry   supplier   of   high-quality,  state-of-the-art
computing and communication  systems,"  stated  JoAnne  Miller,  product
manager of 3B Networking Software. " This product family is another step
in AT&T's overall strategy of continuing to provide and  support  system
capabilities with the special advantage of adherence to current software
standards," Miller continued.

				 # # #

In what I am sure is a completely unrelated article from today's
WSJ (7/1) page 6 col 6:

AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK

NEW  YORK  -  American Telephone & Telegraph Co.'s new computer contract
with the Defense Department's National Security Agency is  broader  than
previously announced.

Government officials and sources close to the bidding said the agreement
includes  software  development  and  sales  of  computer  networks  and
accessories.   Earlier, the agency's officials said the contract, valued
at as much as $946  million  through  1988,  covered  mainly  sales  and
service  of  as  many as 250 minicomputers of AT&T's 3B line, introduced
last year.

An NSA spokesman said the intelligence agency increased its estimate  of
how many minicomputers it will buy under the contract to as many as 325.

The  spokesman said final bidding was between AT&T and Digital Equipment
Corp.  Sources  said  the  decision  was   based   more   on   technical
considerations  than  on cost. International Business Machines Corp. was
eliminated earlier, a source said.

(that's all of it, Yow, my fingers hurt)

	-Barry Shein, Boston University
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 1985 1808-PDT (Sunday)
From:      sun!l5!gnu@Berkeley (John Gilmore)
To:        imagen!geof@Berkeley, mogul@navajo.ARPA, tcp-ip@sri-nic.ARPA
Subject:   Re: tftp for bootstrap
I personally don't see much point in using tftp as a boot protocol
UNLESS it will talk to existing servers.  We might as well use our
existing "nd" protocol if the only thing it will ever talk to is
other Suns.

The responses I've gotten tend strongly toward the "we did it kinda
that way and it has worked for N years" type of stories, which are OK
but not much help.  I guess what I'm looking for is a good reason to
boot with TFTP (nobody has yet said "we did it another way and are
really sorry"), and some help in designing the protocol above TFTP (the
file name, how we find the server), to let it interoperate with other
Internet machines with minimal or no effort.  It seems like the war
stories all describe schemes where a custom boot server exists (maybe
running TFTP but not the way it's spec'd for everybody, eg odd port #,
odd file types).

Can I focus this discussion to answer a specific question?  What does
YOUR system's TFTP server do with a file name in a RRQ which does not have
any pathname delimiters?  Reply to me (sun!gnu@Berkeley.arpa) and I'll
summarize to the list.
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7-Jul-85 21:50:25 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: sun!l5!gnu@BERKELEY (John Gilmore)

I personally don't see much point in using tftp as a boot protocol
UNLESS it will talk to existing servers.  We might as well use our
existing "nd" protocol if the only thing it will ever talk to is
other Suns.

The responses I've gotten tend strongly toward the "we did it kinda
that way and it has worked for N years" type of stories, which are OK
but not much help.  I guess what I'm looking for is a good reason to
boot with TFTP (nobody has yet said "we did it another way and are
really sorry"), and some help in designing the protocol above TFTP (the
file name, how we find the server), to let it interoperate with other
Internet machines with minimal or no effort.  It seems like the war
stories all describe schemes where a custom boot server exists (maybe
running TFTP but not the way it's spec'd for everybody, eg odd port #,
odd file types).

Can I focus this discussion to answer a specific question?  What does
YOUR system's TFTP server do with a file name in a RRQ which does not have
any pathname delimiters?  Reply to me (sun!gnu@Berkeley.arpa) and I'll
summarize to the list.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Monday,  8 Jul 1985 11:24-PDT
From:      imagen!geof@su-shasta.arpa
To:        sun!l5!gnu@su-shasta.arpa
Cc:        shasta!tcp-ip@sri-nic.ARPA
Subject:   Re: tftp for bootstrap

I must confess that my comments should really be in conjunction with
Noel Chiappa's, since we are referring to the same set of TFTP
implementations.  I worked on some of the TFTP implementations while I
was at MIT.

My last message should only be read in context -- I agree that TFTP is
no better a protocol than most others for bootloading, except insofar as
it is possible to use other server implementations of TFTP.

It is not necessary to modify a TFTP server from its "vanilla" state to
make it useable for bootloading.  The modifications that were done at
MIT mostly were because some machines had TFTP has their only file
transfer protocol (specifically, the UPDATE mode).

The MIT implementations of TFTP all met spec (I presume they all still
do), and few had hidden features.  All ran on port 69.  Some efforts
were occasionally made to make sure that the implementations at MIT and
ISI were able to interconnect.  File names which were received were
handed by the server to the operating system, and interpreted in the
security and naming contexts of the server.  As additional security
measures:
	- all servers refused to overwrite existing files
	- the servers on Tops-20 and Multics were sufficiently isolated
	  from a security point of view that the server had (by default)
	  very little access to most user's files and directories.  On
	  multics, the server had to be explicitly permitted to access
	  a portion of the directory tree.
	- on berkeley Unix, the server explicitly tested protections to
	  verify that global read (or write) access existed where it 
	  was needed. This was necessary because the server had to run
	  as root to be able to access socket 69, so our initial
	  attempts to just have the server attempt to open the file and
	  let the OS apply some default set of protections wouldn't work
	  (interesting how in this case a security feature turned out
	  to be a security bug).
On most of the machines, the server would also reject any file transfer
for which no directory was specified (the exception was the alto
implementation, because there were no directories to speak of).  On
Tops-20, a device or directory spec had to be specified, but it was not
necessary to specify both.

For purposes of bootloading, a special directory was set up on each
machine.  The name of the directory was configured into the
gateways, as was each machine's internet address.  For reasons of code
size, the bootloader was typically only able to use one interface. 
However, the gateways were able to boot through each other, so
bootloading was possible from a wide variety of machines.

Since gateway code was different for each gateway, the boot files for
each gateway were named by concatenating the address of the gateway
together.  As Noel pointed out, this is easy to keep track of if you
assign three letters to each byte for decimal or octal number
(alternately, use hex).  When booting, the gateway sent a read request
to each host for a file whose name was the concatenation of the prefix
for that host and the internet address of the gateway, unparsed as an
octal string with three digits for each byte.  The transfer mode was
mode "image." The intent of mode "image" is that a file which is
transferred to a host using it and then transferred back ends up with
the same bits in it (perhaps a few more tacked onto the end); it is
perfect for bootloading.  We simply distributed the boot-code using
TFTP mode image (with a little telnet fudging to delete the original
first, see below) from the source, and were confident that it would be
read back correctly.  This worked on Alto's, Unices, Tops-20, and
Multics (the latter two used different ways of storing the Image files
- Tops-20 used 8-bit bytes with 4 bits of each 36 bit word wasted, and
multics stored the bits sequentially in 36-bit words, ignoring word
boundaries).

The obvious way to use TFTP for bootloading is to have the gateway send
a read request to every host in the list at once, and to accept the
first response (and eventually reject any other responses).  This is
analogous to a broadcast request for booting.  I'm not sure if the
gateway did this in practise, or just tried the hosts in sequence.

So, in summary, TFTP is a good bootloading protocol, without
modification:
	- It supports a pseudo-broadcast mode of booting request.
	- It has a transfer mode that works.
	- It is fast enough.
	- It is simple (the original TFTP bootloader fit into 2Kb of
	  ROM).
	- It is an internet protocol (you can boot through gateways -
	  for a while at MIT we had two gateways booting off a network
	  which had no other hosts on it.  Each booted through the
	  other.  Worked for weeks until the power flickered one day...
	  then we had to get out the old serial-line downloader).
Problems:
	- You have to derive an Internet address for the host to be
	  able to use an internet protocol to boot it.  On an ethernet
	  this is more of a problem.

	- You have to store both the names of the boot directories on
	  each boot-host and the internet addresses of the boot hosts
	  (in practise, there was only one boot rom that
	  had all the hosts and directories in it; each gateway could
	  not access some of the hosts in its table).
	  This problem is minimized in a homogeneous environment, since
	  the name of the directory can be the same everywhere.

	- It is an Internet protocol, so that broadcast is not a
	  "native" mode of using it.  If your nodes implement internet
	  broadcast (I guess sun's still use host number 0 for
	  broadcast, like the vaxen do...) you could theoretically use
	  it, although as Noel points out, there are advantages to being
	  able to boot through a gateway when necessary.

One compromise position might be to use a broadcast scheme to get the
booting information into the host, then use TFTP to boot the host. 
This would have the effect of compartmentalizing the nonstandard code 
in the system, and would add a more minor restriction to booting a
host.  Or use a "breath of life" scheme.  Have a host periodically
broadcast the booting information on the network in question, and have
the bootloader just wait for the promiscuous packet to arrive.  The
advantage of this scheme is that you don't have to have any broadcasting
booters on the local net -- they can use directed broadcast to send
the breath of life packets.

- Geof
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 85 11:08 EDT
From:      ddn-usaf @ DDN1.ARPA
To:        tcp-ip @ sri-nic.arpa
Cc:        ddn-usaf @ DDN1.ARPA
Subject:   take me off your mailing list
please remove my name from the tcp-ip mailing list.

thank you,
mike allen/ddn-usaf@ddn1

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 12:23:44 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   take me off your mailing list

From: ddn-usaf@DDN1.ARPA

please remove my name from the tcp-ip mailing list.

thank you,
mike allen/ddn-usaf@ddn1

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1985 1633-PDT (Monday)
From:      Bill Croft <croft@safe>
To:        sun!l5!gnu@Berkeley (John Gilmore)
Cc:        tcp-ip@sri-nic.ARPA, croft@safe
Subject:   Re: tftp for bootstrap
John,

I guess what I would like to see in your new SUN Microsystems boot
proms (and adopted as an internet standard) is a TWO PHASE boot:

	(1) The 'server location / address assignment' phase could use a
	simple UDP broadcast packet exchange.  This exchange allows the
	booting client to locate boot servers by name.  The same protocol
	can also be used to assign an IP address to the client, given
	his ethernet address.  A sample packet exchange of such a protocol is
	shown below.

	(2) The second phase corresponds to the TFTP file transfer of
	the load image, given that the client knows his IP address,
	the servers IP address, and the file name.   Optionally the
	client may also load through gateways if he knows a default
	gateway address.

The boot is split into these two phases because the first is more volitile
and likely to change than the second.  Given that there are many TFTP
'boot/load servers' already running in the internet, it would be 
great to be able to utilize this resource.  I could imagine that your
boot code would have several entry points.  The default 'power up' boot
might go through both phases.  However a manual entry point would allow
the user to begin just the second phase, by supplying the IP addresses
and pathname string mentioned above.  Further, if the hardware had an
EAPROM capability, a 'default' second phase boot could be completed
automatically, if the person wished to make that setup option.

Note that both phases of this booting use ONLY INTERNET protocols.  This
is in contrast to the proposed RFC903 "A Reverse Address Resolution
Protocol".  RFC903 proposes that we use a new ethernet link type (not ARP,
but RARP) to allow a client to find his own IP address, given his ethernet
address.  But RFC903 can only be implemented with kernel modifications;  e.g.
by using the 'CMU packet filter' kernel code, or some new (as yet
unwritten and unstandardized) IOCTL interface to the kernel to load this
RARP information from the boot servers.

Instead what you can do is have the first phase server BROADCAST his
reply to the requesting client.  This is only one more broadcast than
the RFC903 case, but it now allows all the boot server processes to
be simple UDP servers at user level with no kernel changes.  Even if
you did find a way to modify the kernel for RFC903, how are you going
to get these mods out to all the different UNIX box companies?  What
about booting from TOPS20?  Etc.  I think the advantages are overwhelming
for restricting the boot protocol to use only IP/UDP.


EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT

BOOTREQUEST packet from diskless client to server:

	IP DST: 255.255.255.255
	IP SRC: 0.0.0.0			[i.e. I don't know it yet]
	PROTO: UDP
	PORT: bootport
	----- packet data is:
	OPCODE: BOOTREQUEST
	MY ETHERADDR: xx xx xx xx xx xx
	FILENAME: xxxxxx
	SERVERNAME: yyyyyy		[optional]

Then the boot server answers back, with a broadcast [only to this first
exchange] so that we neatly bypass all the ARP bootstraping problems.
After the client has his real IP address (and that of the server),
a normal TFTP file read occurs.  The client only accepts a BOOTACK with
a CLIENT'S ETHERADDR that matches his own.

BOOTACK packet from server to client:

	IP DST: 255.255.255.255
	IP SRC: server IP address
	PROTO: UDP
	PORT: bootport
	----- packet data is:
	OPCODE: BOOTACK
	CLIENT'S ETHERADDR: xx xx xx xx xx xx
	CLIENT'S IP ADDR: xx xx xx xx
	DEFAULT GATE ADDR: xx xx xx xx
	FILEVERSION: xx
	FILEDATE: xx

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 1985 17:45:57 PDT
From:      Stephen Casner <Casner@USC-ISIB.ARPA>
To:        mills@DCN6.ARPA
Cc:        gateway@BBN-UNIX.ARPA, egp-people@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA, Casner@USC-ISIB.ARPA
Subject:   Re: Plea for ICMP Timestamp support
Dave,
	In our EPOS operating system, we use a different technique for
the 60 Hz clock.  Rather than adding the approximate fraction 2/3 to a
fractional extension of the accumulator, we use a modulo-3 counter to
add an extra 1 to the accumulator on 2 out of every 3 cycles.  For the
example of a millisecond clock, 17 is added on the first 2 out of 3
cycles and 16 is added on the third cycle.  (In EPOS we actually keep a
48-bit clock of 40 microsecond ticks, but the principle is the same.)

	The advantage of this method is that it is exact rather than
having an error of .000005 ms per 60 Hz tick or about 1 ms per hour.
The number of instructions is about the same with either technique.
Here is a code segment for the PDP11:

	DEC	TRICYC		; Is this the third of three cycles?
	BPL	1$		; No - just update time
	MOV	#2,TRICYC	; Yes - reset the modulo-three counter
	ADD	#INCTIM,UPTML	; Update time less 2/3 fraction to adjust
	BR	2$		;  for the two extra 1/3 fraction

1$:	ADD	#INCTIM+1,UPTML	; Update time including 1/3 fraction extra
2$:	ADC	UPTMM		; Carry the update out through 32 bits

The BR 2$ can be eliminated by replicating code if that is practical.

							-- Steve
-------
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 16:25:49 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: imagen!geof@su-shasta.arpa


I must confess that my comments should really be in conjunction with
Noel Chiappa's, since we are referring to the same set of TFTP
implementations.  I worked on some of the TFTP implementations while I
was at MIT.

My last message should only be read in context -- I agree that TFTP is
no better a protocol than most others for bootloading, except insofar as
it is possible to use other server implementations of TFTP.

It is not necessary to modify a TFTP server from its "vanilla" state to
make it useable for bootloading.  The modifications that were done at
MIT mostly were because some machines had TFTP has their only file
transfer protocol (specifically, the UPDATE mode).

The MIT implementations of TFTP all met spec (I presume they all still
do), and few had hidden features.  All ran on port 69.  Some efforts
were occasionally made to make sure that the implementations at MIT and
ISI were able to interconnect.  File names which were received were
handed by the server to the operating system, and interpreted in the
security and naming contexts of the server.  As additional security
measures:
	- all servers refused to overwrite existing files
	- the servers on Tops-20 and Multics were sufficiently isolated
	  from a security point of view that the server had (by default)
	  very little access to most user's files and directories.  On
	  multics, the server had to be explicitly permitted to access
	  a portion of the directory tree.
	- on berkeley Unix, the server explicitly tested protections to
	  verify that global read (or write) access existed where it 
	  was needed. This was necessary because the server had to run
	  as root to be able to access socket 69, so our initial
	  attempts to just have the server attempt to open the file and
	  let the OS apply some default set of protections wouldn't work
	  (interesting how in this case a security feature turned out
	  to be a security bug).
On most of the machines, the server would also reject any file transfer
for which no directory was specified (the exception was the alto
implementation, because there were no directories to speak of).  On
Tops-20, a device or directory spec had to be specified, but it was not
necessary to specify both.

For purposes of bootloading, a special directory was set up on each
machine.  The name of the directory was configured into the
gateways, as was each machine's internet address.  For reasons of code
size, the bootloader was typically only able to use one interface. 
However, the gateways were able to boot through each other, so
bootloading was possible from a wide variety of machines.

Since gateway code was different for each gateway, the boot files for
each gateway were named by concatenating the address of the gateway
together.  As Noel pointed out, this is easy to keep track of if you
assign three letters to each byte for decimal or octal number
(alternately, use hex).  When booting, the gateway sent a read request
to each host for a file whose name was the concatenation of the prefix
for that host and the internet address of the gateway, unparsed as an
octal string with three digits for each byte.  The transfer mode was
mode "image." The intent of mode "image" is that a file which is
transferred to a host using it and then transferred back ends up with
the same bits in it (perhaps a few more tacked onto the end); it is
perfect for bootloading.  We simply distributed the boot-code using
TFTP mode image (with a little telnet fudging to delete the original
first, see below) from the source, and were confident that it would be
read back correctly.  This worked on Alto's, Unices, Tops-20, and
Multics (the latter two used different ways of storing the Image files
- Tops-20 used 8-bit bytes with 4 bits of each 36 bit word wasted, and
multics stored the bits sequentially in 36-bit words, ignoring word
boundaries).

The obvious way to use TFTP for bootloading is to have the gateway send
a read request to every host in the list at once, and to accept the
first response (and eventually reject any other responses).  This is
analogous to a broadcast request for booting.  I'm not sure if the
gateway did this in practise, or just tried the hosts in sequence.

So, in summary, TFTP is a good bootloading protocol, without
modification:
	- It supports a pseudo-broadcast mode of booting request.
	- It has a transfer mode that works.
	- It is fast enough.
	- It is simple (the original TFTP bootloader fit into 2Kb of
	  ROM).
	- It is an internet protocol (you can boot through gateways -
	  for a while at MIT we had two gateways booting off a network
	  which had no other hosts on it.  Each booted through the
	  other.  Worked for weeks until the power flickered one day...
	  then we had to get out the old serial-line downloader).
Problems:
	- You have to derive an Internet address for the host to be
	  able to use an internet protocol to boot it.  On an ethernet
	  this is more of a problem.

	- You have to store both the names of the boot directories on
	  each boot-host and the internet addresses of the boot hosts
	  (in practise, there was only one boot rom that
	  had all the hosts and directories in it; each gateway could
	  not access some of the hosts in its table).
	  This problem is minimized in a homogeneous environment, since
	  the name of the directory can be the same everywhere.

	- It is an Internet protocol, so that broadcast is not a
	  "native" mode of using it.  If your nodes implement internet
	  broadcast (I guess sun's still use host number 0 for
	  broadcast, like the vaxen do...) you could theoretically use
	  it, although as Noel points out, there are advantages to being
	  able to boot through a gateway when necessary.

One compromise position might be to use a broadcast scheme to get the
booting information into the host, then use TFTP to boot the host. 
This would have the effect of compartmentalizing the nonstandard code 
in the system, and would add a more minor restriction to booting a
host.  Or use a "breath of life" scheme.  Have a host periodically
broadcast the booting information on the network in question, and have
the bootloader just wait for the promiscuous packet to arrive.  The
advantage of this scheme is that you don't have to have any broadcasting
booters on the local net -- they can use directed broadcast to send
the breath of life packets.

- Geof

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 85 17:31:22 EDT (Mon)
From:      ihnp4!ihnp1!bentley!drew@Berkeley (R. Drew Davis)
Subject:   Drew is on vacation thru 7/14/85
This is a recording...

Your mail has been received and will be held for me.  (This automatic
reply program sometimes does strange things, so if you didn't mail to
me, please disregard this message.  Perhaps someone else mailed a news
article of yours to me for my attention).

I am on vacation from 7/4/85 until 7/14/85.  If you
have something urgent, you can contact Wyatt Chen.
He has my delegation for the time that I will be away.  He can be reached on
(201)981-2318 or via mail to packard!ysc.  His office is PY2H335.

If you need to reach me personally, I can be found at home until 7/6.
After that, I'll be far, far away until the evening of 7/13 when I return
from the sunny shores of the Detroit vicinity.

Drew
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 17:49:00 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Plea for ICMP Timestamp support

From: mills@dcn6.arpa

Folks,

This is a plea to the gateway implementors to incorporate ICMP Timestamp
messages (cf. RFC-792) in their implementations. The reason for this timely
passion is to facilitate experiments I am running to determine the feasability
of synchronizing clocks across the Internet. The motivation for this is to
synchonize data-base updates and cache timeouts, as well as determine one-way
delays and other performance parameters.

To my knowledge, the only Internet players now implementing "standard"
(millisecond) ICMP Timestamps are the fuzzballs and some Unix systems,
including some 4.2bsd and C/70 sites. Unfortunately, the Sun clock seems to
wander badly, often over ten seconds over the course of the day. The BBN
gateways do respond to ICMP Timestamp messages, but not in millisecond units.
A C/70 in Germany appears to run slow by 50/60, which is hardly surprising.

The following implementation hints may serve to provoke interest in bringing
up an ICMP Timestamp service. Assuming some sort of line-frequency or
crystal-controlled hardware clock is available, it is very simple to implement
an interrupt routine that updates a double-word (32 bits) by a number of
milliseconds equal to the clock interval. For 50-Hz (European) mains or
crystal clocks that can be set to interrupt at a multiple of one millisecond,
a 32-bit accumulator suffices; however, for 60-Hz (US) mains, an additional 16
bits of precision is neccessary for the fractional part.

Just to save you some keystrokes, in the case of 60-Hz systems, the magic
number of milliseconds, expressed as a 32-bit quantity in two 16-bit words, is
16 in the high-order 16 bits (integer part) and 43691 in the low-order 16 bits
(fraction part). You should also roll over the clock at 24 hours, which in
milliseconds expressed as a 32-bit quantity in two 16-bit words, is 1318 in
the high-order 16 bits and 23552 in the low-order 16 bits.

It is not necessary that the clock be synchronized to some external reference,
since corrections can be computed remotely. In this case the high-order bit of
the 32-bit timestamp returned in the ICMP Timestamp Reply should be set to
one. If you attempt to synchronize the clock to a local reference, such as an
operator command, I suggest you not disturb the clock accumulator itself, but
use an additional 32-bit quantity that is added (with interrupts disabled!)
modulo-24 hours to the clock accumulator before passing to the application
level. In this case the high-order bit of the timestamp should be set to zero.

I promise to reach out and tickle any implementation that manages this magic
and report my finidngs. If there is interest in tickling fuzzballs, I will
suggest appropriate targets upon individual request. I would expecially like
to compare line frequency stability between the four regional power grids in
(1) Quebec, (2) most of Texas, (3) west of the Rockies and (4) east of the
Rockies, as well as overseas. The goal is to assess whether the rate of phase
change between the grids is sufficiently small to assume reliable clocks can
be achieved with relatively infrequent broadcast corrections.

Dave
-------

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      08 Jul 85 17:50:31 EDT (Mon)
From:      tmallory@bbnccv
To:        mills@dcn6.ARPA
Cc:        gateway@bbn-unix.ARPA, egp-people@bbn-unix.ARPA, tcp-ip@sri-nic.ARPA, tmallory@bbnccv
Subject:   Re: Plea for ICMP Timestamp support
Dave,

Have you considered the alternative approach of including the time unit
with the icmp time-stamp rather than forcing conversion to milliseconds
which seems a little arbitrary?  You would then have some idea of the
granularity of the clock ticks you are comparing.  (Perhaps a self-defining
message using x.409?)  A 24-hour rollover seems to be a reasonable request.

Tracy
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      08 Jul 85 18:35:53 EDT (Mon)
From:      Dennis Rockwell <drockwel@CSNET-SH.ARPA>
To:        mills@DCN6.ARPA
Cc:        gateway@BBN-UNIX.ARPA, egp-people@BBN-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Plea for ICMP Timestamp support
One thing to note about the 4.2 timestamp reply (as distributed): it is
computed assuming no leap-time other than whole days.  It takes the UNIX
time, which is measured from midnight UT (15 years ago), divides by one day,
and uses the remainder. So, for instance, the recent leap-second is
basically ignored.

Of course, if you look at it the other way, we've moved the zero point by
the leap-time since zero.

Of course, this makes no practical difference to most of us, since clocks
among our machines (all in the same room) are normally different by as much
as five minutes.  I suppose that this is what Dave is proposing to remedy?

Dave, feel free to poke CSNET-RELAY, CSNET-SH, and CSNET-DEV.  For real
thrills, poke 192.5.58.5, which is CSNET-DEV's PDN address.  Expect to lose
the first packet per five minutes, at least for a while yet.

Dennis Rockwell
CSNET Technical Staff
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 18:55:27 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Plea for ICMP Timestamp support

From: tmallory@bbnccv

Dave,

Have you considered the alternative approach of including the time unit
with the icmp time-stamp rather than forcing conversion to milliseconds
which seems a little arbitrary?  You would then have some idea of the
granularity of the clock ticks you are comparing.  (Perhaps a self-defining
message using x.409?)  A 24-hour rollover seems to be a reasonable request.

Tracy

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 19:56:45 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Plea for ICMP Timestamp support

From: Dennis Rockwell <drockwel@CSNET-SH.ARPA>

One thing to note about the 4.2 timestamp reply (as distributed): it is
computed assuming no leap-time other than whole days.  It takes the UNIX
time, which is measured from midnight UT (15 years ago), divides by one day,
and uses the remainder. So, for instance, the recent leap-second is
basically ignored.

Of course, if you look at it the other way, we've moved the zero point by
the leap-time since zero.

Of course, this makes no practical difference to most of us, since clocks
among our machines (all in the same room) are normally different by as much
as five minutes.  I suppose that this is what Dave is proposing to remedy?

Dave, feel free to poke CSNET-RELAY, CSNET-SH, and CSNET-DEV.  For real
thrills, poke 192.5.58.5, which is CSNET-DEV's PDN address.  Expect to lose
the first packet per five minutes, at least for a while yet.

Dennis Rockwell
CSNET Technical Staff

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 20:48:08 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: Bill Croft <croft@safe>

John,

I guess what I would like to see in your new SUN Microsystems boot
proms (and adopted as an internet standard) is a TWO PHASE boot:

	(1) The 'server location / address assignment' phase could use a
	simple UDP broadcast packet exchange.  This exchange allows the
	booting client to locate boot servers by name.  The same protocol
	can also be used to assign an IP address to the client, given
	his ethernet address.  A sample packet exchange of such a protocol is
	shown below.

	(2) The second phase corresponds to the TFTP file transfer of
	the load image, given that the client knows his IP address,
	the servers IP address, and the file name.   Optionally the
	client may also load through gateways if he knows a default
	gateway address.

The boot is split into these two phases because the first is more volitile
and likely to change than the second.  Given that there are many TFTP
'boot/load servers' already running in the internet, it would be 
great to be able to utilize this resource.  I could imagine that your
boot code would have several entry points.  The default 'power up' boot
might go through both phases.  However a manual entry point would allow
the user to begin just the second phase, by supplying the IP addresses
and pathname string mentioned above.  Further, if the hardware had an
EAPROM capability, a 'default' second phase boot could be completed
automatically, if the person wished to make that setup option.

Note that both phases of this booting use ONLY INTERNET protocols.  This
is in contrast to the proposed RFC903 "A Reverse Address Resolution
Protocol".  RFC903 proposes that we use a new ethernet link type (not ARP,
but RARP) to allow a client to find his own IP address, given his ethernet
address.  But RFC903 can only be implemented with kernel modifications;  e.g.
by using the 'CMU packet filter' kernel code, or some new (as yet
unwritten and unstandardized) IOCTL interface to the kernel to load this
RARP information from the boot servers.

Instead what you can do is have the first phase server BROADCAST his
reply to the requesting client.  This is only one more broadcast than
the RFC903 case, but it now allows all the boot server processes to
be simple UDP servers at user level with no kernel changes.  Even if
you did find a way to modify the kernel for RFC903, how are you going
to get these mods out to all the different UNIX box companies?  What
about booting from TOPS20?  Etc.  I think the advantages are overwhelming
for restricting the boot protocol to use only IP/UDP.


EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT

BOOTREQUEST packet from diskless client to server:

	IP DST: 255.255.255.255
	IP SRC: 0.0.0.0			[i.e. I don't know it yet]
	PROTO: UDP
	PORT: bootport
	----- packet data is:
	OPCODE: BOOTREQUEST
	MY ETHERADDR: xx xx xx xx xx xx
	FILENAME: xxxxxx
	SERVERNAME: yyyyyy		[optional]

Then the boot server answers back, with a broadcast [only to this first
exchange] so that we neatly bypass all the ARP bootstraping problems.
After the client has his real IP address (and that of the server),
a normal TFTP file read occurs.  The client only accepts a BOOTACK with
a CLIENT'S ETHERADDR that matches his own.

BOOTACK packet from server to client:

	IP DST: 255.255.255.255
	IP SRC: server IP address
	PROTO: UDP
	PORT: bootport
	----- packet data is:
	OPCODE: BOOTACK
	CLIENT'S ETHERADDR: xx xx xx xx xx xx
	CLIENT'S IP ADDR: xx xx xx xx
	DEFAULT GATE ADDR: xx xx xx xx
	FILEVERSION: xx
	FILEDATE: xx

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 22:54:40 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Plea for ICMP Timestamp support

From: Stephen Casner <Casner@USC-ISIB.ARPA>

Dave,
	In our EPOS operating system, we use a different technique for
the 60 Hz clock.  Rather than adding the approximate fraction 2/3 to a
fractional extension of the accumulator, we use a modulo-3 counter to
add an extra 1 to the accumulator on 2 out of every 3 cycles.  For the
example of a millisecond clock, 17 is added on the first 2 out of 3
cycles and 16 is added on the third cycle.  (In EPOS we actually keep a
48-bit clock of 40 microsecond ticks, but the principle is the same.)

	The advantage of this method is that it is exact rather than
having an error of .000005 ms per 60 Hz tick or about 1 ms per hour.
The number of instructions is about the same with either technique.
Here is a code segment for the PDP11:

	DEC	TRICYC		; Is this the third of three cycles?
	BPL	1$		; No - just update time
	MOV	#2,TRICYC	; Yes - reset the modulo-three counter
	ADD	#INCTIM,UPTML	; Update time less 2/3 fraction to adjust
	BR	2$		;  for the two extra 1/3 fraction

1$:	ADD	#INCTIM+1,UPTML	; Update time including 1/3 fraction extra
2$:	ADC	UPTMM		; Carry the update out through 32 bits

The BR 2$ can be eliminated by replicating code if that is practical.

							-- Steve
-------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jul-85 23:36:28 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Drew is on vacation thru 7/14/85

From: ihnp4!ihnp1!bentley!drew@BERKELEY (R. Drew Davis)

This is a recording...

Your mail has been received and will be held for me.  (This automatic
reply program sometimes does strange things, so if you didn't mail to
me, please disregard this message.  Perhaps someone else mailed a news
article of yours to me for my attention).

I am on vacation from 7/4/85 until 7/14/85.  If you
have something urgent, you can contact Wyatt Chen.
He has my delegation for the time that I will be away.  He can be reached on
(201)981-2318 or via mail to packard!ysc.  His office is PY2H335.

If you need to reach me personally, I can be found at home until 7/6.
After that, I'll be far, far away until the evening of 7/13 when I return
from the sunny shores of the Detroit vicinity.

Drew

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jul 85 23:38:42 edt
From:      dual!mordor!seismo!rochester!ur-laser!tomk@Berkeley (Tom Kessler)
To:        dual!ucbvax!tcp-ip@Berkeley
Subject:   Re:  46M NSA/AT&T Contract for 3BXX's
Gee now if twg could only make there uucp link work...

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      08-Jul-85 20:34:56-UT
From:      mills@dcn6.arpa
To:        gateway@bbn-unix.arpa, egp-people@bbn-unix.arpa, tcp-ip@sri-nic.arpa
Subject:   Plea for ICMP Timestamp support
Folks,

This is a plea to the gateway implementors to incorporate ICMP Timestamp
messages (cf. RFC-792) in their implementations. The reason for this timely
passion is to facilitate experiments I am running to determine the feasability
of synchronizing clocks across the Internet. The motivation for this is to
synchonize data-base updates and cache timeouts, as well as determine one-way
delays and other performance parameters.

To my knowledge, the only Internet players now implementing "standard"
(millisecond) ICMP Timestamps are the fuzzballs and some Unix systems,
including some 4.2bsd and C/70 sites. Unfortunately, the Sun clock seems to
wander badly, often over ten seconds over the course of the day. The BBN
gateways do respond to ICMP Timestamp messages, but not in millisecond units.
A C/70 in Germany appears to run slow by 50/60, which is hardly surprising.

The following implementation hints may serve to provoke interest in bringing
up an ICMP Timestamp service. Assuming some sort of line-frequency or
crystal-controlled hardware clock is available, it is very simple to implement
an interrupt routine that updates a double-word (32 bits) by a number of
milliseconds equal to the clock interval. For 50-Hz (European) mains or
crystal clocks that can be set to interrupt at a multiple of one millisecond,
a 32-bit accumulator suffices; however, for 60-Hz (US) mains, an additional 16
bits of precision is neccessary for the fractional part.

Just to save you some keystrokes, in the case of 60-Hz systems, the magic
number of milliseconds, expressed as a 32-bit quantity in two 16-bit words, is
16 in the high-order 16 bits (integer part) and 43691 in the low-order 16 bits
(fraction part). You should also roll over the clock at 24 hours, which in
milliseconds expressed as a 32-bit quantity in two 16-bit words, is 1318 in
the high-order 16 bits and 23552 in the low-order 16 bits.

It is not necessary that the clock be synchronized to some external reference,
since corrections can be computed remotely. In this case the high-order bit of
the 32-bit timestamp returned in the ICMP Timestamp Reply should be set to
one. If you attempt to synchronize the clock to a local reference, such as an
operator command, I suggest you not disturb the clock accumulator itself, but
use an additional 32-bit quantity that is added (with interrupts disabled!)
modulo-24 hours to the clock accumulator before passing to the application
level. In this case the high-order bit of the timestamp should be set to zero.

I promise to reach out and tickle any implementation that manages this magic
and report my finidngs. If there is interest in tickling fuzzballs, I will
suggest appropriate targets upon individual request. I would expecially like
to compare line frequency stability between the four regional power grids in
(1) Quebec, (2) most of Texas, (3) west of the Rockies and (4) east of the
Rockies, as well as overseas. The goal is to assess whether the rate of phase
change between the grids is sufficiently small to assume reliable clocks can
be achieved with relatively infrequent broadcast corrections.

Dave
-------
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jul-85 00:58:11 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Plea for ICMP Timestamp support

From: mills@dcn6.arpa



Tracy,

Several years ago we chatted up the timestamp issues and ended up with a
number of proposals (see old RFCs). One of the conclusions was that simple,
grumpy gateways could participate with only the barest bones of code and
with only minimal protocolmanship. We could recook those conclusions
handily (an x.409 IP option?!), but not without shaking the dust off the
ICMP spec. Notwithstanding the above, the experience with our local-net
algorithms suggests a much more important issue is the sender's estimate
of the intrinsic accuracy of his clock, whether derived from power mains,
local radio clock or second-hand from a UPS with a free-running 59.8-Hz
oscillator.

Dave
-------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      09-Jul-85 03:05:42-UT
From:      mills@dcn6.arpa
To:        tmallory@bbnccv, mills@dcn6.ARPA, gateway@bbn-unix.ARPA, egp-people@bbn-unix.ARPA, tcp-ip@sri-nic.ARPA, N@DCN6.ARPA
Subject:   Re: Plea for ICMP Timestamp support


Tracy,

Several years ago we chatted up the timestamp issues and ended up with a
number of proposals (see old RFCs). One of the conclusions was that simple,
grumpy gateways could participate with only the barest bones of code and
with only minimal protocolmanship. We could recook those conclusions
handily (an x.409 IP option?!), but not without shaking the dust off the
ICMP spec. Notwithstanding the above, the experience with our local-net
algorithms suggests a much more important issue is the sender's estimate
of the intrinsic accuracy of his clock, whether derived from power mains,
local radio clock or second-hand from a UPS with a free-running 59.8-Hz
oscillator.

Dave
-------
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jul-85 12:18:27 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Tweaking clocks

From: mills@dcn6.arpa

Folks,

My apologies to some of you how might be getting three copies of the Clockwatchers
Gazette. I intended to send the following reply to a recent message to the whole
list, but it seems to have been swallowed. Herewith the reply:

Steve,

The method I proposed involves adding a fractional quantity approximately
equivalent to 2/3 of a millisecond 60 times a second. The fractional quantity,
expressed as a 16-bit integer, has a low-order bit that toggles at about a
001*2-^16 = 15-nanosecond period. Thus, the accumulated error after 60 ticks
is about 0.9 microseconds, in other words a residual systematic error of 0.9
ppm, and that compares favorably with just about any crystal oscillator you
are likely to afford. If allowed to accumulate uncorrected, however, the error
after one hour would be about 3.2 milliseconds, after one day 80 milliseconds
and after one year 30 seconds.

According to an interview with our local power bullies, we should expect the
(Eastern) 60-Hz power-grid frequency to wander over a .025-Hz band (over +-400
ppm) with daily extremes of +-3 to +-6 seconds in absolute time offsets. The
fuzzball timekeeping algorithms have to yank the phase of the local clock
accordingly in response to corrections broadcast on the local net, which makes
the 0.9 ppm systematic error pale in the dust.

While your method does have the elegance of precision, it does not lend itself
to synchonization techniques which involve incremental phase adjustments, such
as we use in the futzoballs. It also does not lend itself to convenient
reconfiguration for oddball clocks and national frequencies. As you point out,
either the method you suggest or mine costs about the same in time and code.

The bottom line is, if you want short-term precision and are willing to
correct your clock reasonably often, like once per day, than use a crystal
clock. If you can tolerate daily variations of +-3 to +-6 seconds but don't
want to correct your clock at all, then use your techniqe and a
mains-frequency clock. If you are stuck with a mains-frequency clock and want
to synchronize with other clocks, then use my technique. If you are stuck on a
UPS with a mains-frequency clock, as some of my friends are, don't bother.

Dave
-------

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      09 Jul 85 13:30:31 EST (Tue)
From:      Christopher A Kent <cak@Purdue.EDU>
To:        Bill Croft <croft@su-safe.arpa>
Cc:        sun!l5!gnu@ucb-vax.arpa (John Gilmore), tcp-ip@sri-nic.arpa
Subject:   Re: tftp for bootstrap
Bill,

Your protocol sounds really nice, except that IP broadcasting doesn't
exist. 

Maybe this will provide the grease to get the wheels in motion again.

chris
----------
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jul-85 13:15:42 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  46M NSA/AT&T Contract for 3BXX's

From: dual!mordor!seismo!rochester!ur-laser!tomk@BERKELEY (Tom Kessler)

Gee now if twg could only make there uucp link work...

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jul 85 14:05:24 edt
From:      ukma!david@anl-mcs (David Herron, NPR Lover)
To:        anlams!tcp-ip@Berkeley (tcp-ip@ucbvax.ARPA)
Subject:   Re: 46M NSA/AT&T Contract for 3BXX's
They signed a contract with The Woologong Group to provide their
TCP/IP software for 3B machines.  (This was announced at the same
time).

David Herron
cbosgd!ukma!david
ukma!david@anl-mcs.arpa
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jul-85 14:37:38 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Returned mail: User unknown

From: ihnp4!ihnp1!packard!Postmaster@BERKELEY (Mail Delivery Subsystem)

   ----- Transcript of session follows -----
Postmaster... aliased to  ggr
ggr... aliased to  nomad!ggr
ihnp1!archimedes,ihnp1!unicorn... Connecting to ihnp1.dk...
220 ihnp1.ATT.UUCP Sendmail 4.12/9-Jan-85 ready at 9 Jul 85 10:17:30 CDT (Tue)
>>> HELO py/garage/packard.DK
 250 ihnp1.ATT.UUCP Hello py/garage/packard.DK, pleased to meet you
>>> MAIL From:<packard!ihnp4!ucbvax!tcp-ip>
 250 <packard!ihnp4!ucbvax!tcp-ip>... Sender ok
>>> RCPT To:<unicorn>
550 /usr/lib/uucp/mail/unicorn... Can't create output: Permission denied
ihnp1!unicorn... User unknown
>>> RCPT To:<archimedes>
550 /usr/lib/uucp/mail/archimedes... Can't create output: Permission denied
ihnp1!archimedes... User unknown
>>> QUIT
221 ihnp1.ATT.UUCP closing connection
packard!ihnp1!ihnp4!ucbvax!tcp-ip... duplicate suppressed

   ----- Unsent message follows -----
Date: Sat, 6-Jul-85 21:49:59 EDT
From: ucbvax.ARPA!tcp-ip
Subject: Re:  46M NSA/AT&T Contract for 3BXX's
Message-Id: <8837@ucbvax.ARPA>
Received: by py/garage/packard.DK; 8507091519
Errors-To: Postmaster
Sender: ihnp4!ucbvax!tcp-ip
Newsgroups: fa.tcp-ip
Organization: University of California at Berkeley
Apparently-To: ihnp1!unicorn
Apparently-To: ihnp1!archimedes

From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>

Here's a note (in full) that I just sent out to INFO-3B which may
shed some light on all this:

---------------



THE WOLLONGONG GROUP
NEWS BUREAU (i guess now that UPI is in trouble...:-)

For Immediate release (05/03/85)

		 WOLLONGONG SIGNS AGREEMENT WITH AT&T

PALO ALTO, Calif. -- To expand communications  through  AT&T  computers,
The  Wollongong  Group  and  AT&T  have  signed an agreement under which
Wollongong  will  provide  its  standard  networking  product   for   3B
supermicro and supermini computer under UNIX System V.

"Wollongong's  software  products  will have the required Department of
Defense standard  interface  services  for  3B  users,"  said  David  J.
Preston,   director   of  marketing  and  sales  for  Wollongong.  Among
capabilities to be provided are:

	--File transfer (FTP)
	--Electronic mail (SMTP)
	--Virtual terminal (TELNET).

"As a result, 3B users will be able to communicate over a  multitude  of
networks,"  said  Preston,  including  Ethernet  (trademarked  by  Xerox
Corporation), ARPANET, MILNET, the defense Data Network,  point-to-point
nets, and custom-designed networking systems.

"Delivering  this  advanced  standard of networking software to the UNIX
System marketplace is an important step in AT&T's program  to  become  a
significant   industry   supplier   of   high-quality,  state-of-the-art
computing and communication  systems,"  stated  JoAnne  Miller,  product
manager of 3B Networking Software. " This product family is another step
in AT&T's overall strategy of continuing to provide and  support  system
capabilities with the special advantage of adherence to current software
standards," Miller continued.

				 # # #

In what I am sure is a completely unrelated article from today's
WSJ (7/1) page 6 col 6:

AT&T CONTRACT WITH U.S. INCLUDES SOFTWARE WORK

NEW  YORK  -  American Telephone & Telegraph Co.'s new computer contract
with the Defense Department's National Security Agency is  broader  than
previously announced.

Government officials and sources close to the bidding said the agreement
includes  software  development  and  sales  of  computer  networks  and
accessories.   Earlier, the agency's officials said the contract, valued
at as much as $946  million  through  1988,  covered  mainly  sales  and
service  of  as  many as 250 minicomputers of AT&T's 3B line, introduced
last year.

An NSA spokesman said the intelligence agency increased its estimate  of
how many minicomputers it will buy under the contract to as many as 325.

The  spokesman said final bidding was between AT&T and Digital Equipment
Corp.  Sources  said  the  decision  was   based   more   on   technical
considerations  than  on cost. International Business Machines Corp. was
eliminated earlier, a source said.

(that's all of it, Yow, my fingers hurt)

	-Barry Shein, Boston University

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jul-85 16:44:59 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: Christopher A Kent <cak@Purdue.EDU>

Bill,

Your protocol sounds really nice, except that IP broadcasting doesn't
exist. 

Maybe this will provide the grease to get the wheels in motion again.

chris
----------

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      09-Jul-85 15:03:00-UT
From:      mills@dcn6.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Tweaking clocks
Folks,

My apologies to some of you how might be getting three copies of the Clockwatchers
Gazette. I intended to send the following reply to a recent message to the whole
list, but it seems to have been swallowed. Herewith the reply:

Steve,

The method I proposed involves adding a fractional quantity approximately
equivalent to 2/3 of a millisecond 60 times a second. The fractional quantity,
expressed as a 16-bit integer, has a low-order bit that toggles at about a
001*2-^16 = 15-nanosecond period. Thus, the accumulated error after 60 ticks
is about 0.9 microseconds, in other words a residual systematic error of 0.9
ppm, and that compares favorably with just about any crystal oscillator you
are likely to afford. If allowed to accumulate uncorrected, however, the error
after one hour would be about 3.2 milliseconds, after one day 80 milliseconds
and after one year 30 seconds.

According to an interview with our local power bullies, we should expect the
(Eastern) 60-Hz power-grid frequency to wander over a .025-Hz band (over +-400
ppm) with daily extremes of +-3 to +-6 seconds in absolute time offsets. The
fuzzball timekeeping algorithms have to yank the phase of the local clock
accordingly in response to corrections broadcast on the local net, which makes
the 0.9 ppm systematic error pale in the dust.

While your method does have the elegance of precision, it does not lend itself
to synchonization techniques which involve incremental phase adjustments, such
as we use in the futzoballs. It also does not lend itself to convenient
reconfiguration for oddball clocks and national frequencies. As you point out,
either the method you suggest or mine costs about the same in time and code.

The bottom line is, if you want short-term precision and are willing to
correct your clock reasonably often, like once per day, than use a crystal
clock. If you can tolerate daily variations of +-3 to +-6 seconds but don't
want to correct your clock at all, then use your techniqe and a
mains-frequency clock. If you are stuck with a mains-frequency clock and want
to synchronize with other clocks, then use my technique. If you are stuck on a
UPS with a mains-frequency clock, as some of my friends are, don't bother.

Dave
-------
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jul-85 03:24:48 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: 46M NSA/AT&T Contract for 3BXX's

From: ukma!david@anl-mcs (David Herron, NPR Lover)

They signed a contract with The Woologong Group to provide their
TCP/IP software for 3B machines.  (This was announced at the same
time).

David Herron
cbosgd!ukma!david
ukma!david@anl-mcs.arpa

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 1985 1008-PDT (Wednesday)
From:      Bill Croft <croft@safe>
To:        David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, cak@purdue, John Gilmore <sun!l5!gnu@UCB-VAX.ARPA>, croft@safe
Subject:   Re: tftp for bootstrap
----
>Date: 09 Jul 85 13:30:31 EST (Tue)
>From: Christopher A Kent <cak@Purdue.EDU>
>
>Your protocol sounds really nice, except that IP broadcasting doesn't exist. 
>
Well it is implemented (perhaps non-standardly) in many Berkeley UNIXes.  
I hope that 4.3BSD implements the recommendations made by 
Jeff Mogul in RFC919/922.
Those RFCs use various forms of an IP address consisting of 'all ones'
or mostly ones to represent the broadcast address.

----
>Date: Wed, 10 Jul 85 08:45 EDT
>From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
>
>A more general scheme for this (actually, getting the IP address), which
>unfortunately requires implementing a slightly new protocol set is to
>implement inverse ARP (most servers can use existing forward ARP tables;
>
Dave, my argument was that it would be best to implement the first
phase protocol as ONLY an IP/UDP protocol.  This way the server can be
a user-level process (on UNIX, Multics, TOPS20, etc.) without requiring
kernel/operating system mods necessary for the "reverse ARP solution".
The authors of RFC903 DID implement 'reverse ARP' here at Stanford,
but it required using the 'CMU packet filter' kernel code to allow
a user-level server process to access arbitrary ethernet link level
packet types.  Any 'reverse ARP' scheme is going to require kernel
mods;  given that there are many different kernels out there now,
with each source maintained by different organizations, a boot
protocol that does not require kernel modifications I think is
an overwhelming advantage.

In addition, the protocol I illustrated provided several other pieces
of information that "reverse ARP" lacks:  (1) it allows server specification
by name, instead of just address;  (2) it returns IP addresses of
both the client and of gateways on the cable, to allow cross-net booting;
(3) it returns 'qualified' filename / version / date information.
Item #3 allows the client to specify a generic name in the bootrequest
(e.g. 'unix') and then the bootreply from the server could contain
a qualified name based upon database lookups at the server, indexed by
the client's hardware address.  For example, the person performing the
boot may ask to 'boot unix';  the bootreply returned from the server
may contain the qualified pathname '/usr/boot/vmunix123';  the second
phase boot (TFTP) then does a transfer of this new name.

>Why 255.255.255.255.  Shouldn't this be "CLIENT'S IP ADDR"?
>
In the first phase, since the client DOESNT KNOW his IP address yet,
if the server sent the reply to the client's (new) IP address, the
server's ARP module would be unable to discover the client's hardware
address.  That is why the server must broadcast this bootreply
packet.  I claim the slight extra overhead of this extra broadcast
is well worth it, since it allows our first phase server to use
only existing IP/UDP transmission (instead of implementing new
ethernet link types in the kernel).
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jul 85 08:45 EDT
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        Bill Croft <croft@SU-SAFE.ARPA>, John Gilmore <sun!l5!gnu@UCB-VAX.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: tftp for bootstrap
    Date:  8 Jul 1985 1633-PDT (Monday)
    From: Bill Croft <croft@safe>

    John,

    I guess what I would like to see in your new SUN Microsystems boot
    proms (and adopted as an internet standard) is a TWO PHASE boot:

	    (1) The 'server location / address assignment' phase could use a
	    simple UDP broadcast packet exchange.  This exchange allows the
	    booting client to locate boot servers by name.  The same protocol
	    can also be used to assign an IP address to the client, given
	    his ethernet address.  A sample packet exchange of such a protocol is
	    shown below.

A more general scheme for this (actually, getting the IP address), which
unfortunately requires implementing a slightly new protocol set is to
implement inverse ARP (most servers can use existing forward ARP tables;
with a full backup in the file system).  That is, instead of saying
"What's your Ethernet address" it says "What's my protocol address."  We
almost did this at MIT, but the need didn't come up.  If anybody is
really interested I can try to find the full description (it's pretty
trivial; just take ARP and rearrange a few fields).

    EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT

    BOOTREQUEST packet from diskless client to server:

	    IP DST: 255.255.255.255
	    IP SRC: 0.0.0.0			[i.e. I don't know it yet]
	    PROTO: UDP
	    PORT: bootport
	    ----- packet data is:
	    OPCODE: BOOTREQUEST
	    MY ETHERADDR: xx xx xx xx xx xx
	    FILENAME: xxxxxx
	    SERVERNAME: yyyyyy		[optional]

    Then the boot server answers back, with a broadcast [only to this first
    exchange] so that we neatly bypass all the ARP bootstraping problems.
    After the client has his real IP address (and that of the server),
    a normal TFTP file read occurs.  The client only accepts a BOOTACK with
    a CLIENT'S ETHERADDR that matches his own.

    BOOTACK packet from server to client:

	    IP DST: 255.255.255.255
Why 255.255.255.255.  Shouldn't this be "CLIENT'S IP ADDR"?
	    IP SRC: server IP address
	    PROTO: UDP
	    PORT: bootport
	    ----- packet data is:
	    OPCODE: BOOTACK
	    CLIENT'S ETHERADDR: xx xx xx xx xx xx
	    CLIENT'S IP ADDR: xx xx xx xx
	    DEFAULT GATE ADDR: xx xx xx xx
	    FILEVERSION: xx
	    FILEDATE: xx



-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jul-85 12:22:05 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    Date:  8 Jul 1985 1633-PDT (Monday)
    From: Bill Croft <croft@safe>

    John,

    I guess what I would like to see in your new SUN Microsystems boot
    proms (and adopted as an internet standard) is a TWO PHASE boot:

	    (1) The 'server location / address assignment' phase could use a
	    simple UDP broadcast packet exchange.  This exchange allows the
	    booting client to locate boot servers by name.  The same protocol
	    can also be used to assign an IP address to the client, given
	    his ethernet address.  A sample packet exchange of such a protocol is
	    shown below.

A more general scheme for this (actually, getting the IP address), which
unfortunately requires implementing a slightly new protocol set is to
implement inverse ARP (most servers can use existing forward ARP tables;
with a full backup in the file system).  That is, instead of saying
"What's your Ethernet address" it says "What's my protocol address."  We
almost did this at MIT, but the need didn't come up.  If anybody is
really interested I can try to find the full description (it's pretty
trivial; just take ARP and rearrange a few fields).

    EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT

    BOOTREQUEST packet from diskless client to server:

	    IP DST: 255.255.255.255
	    IP SRC: 0.0.0.0			[i.e. I don't know it yet]
	    PROTO: UDP
	    PORT: bootport
	    ----- packet data is:
	    OPCODE: BOOTREQUEST
	    MY ETHERADDR: xx xx xx xx xx xx
	    FILENAME: xxxxxx
	    SERVERNAME: yyyyyy		[optional]

    Then the boot server answers back, with a broadcast [only to this first
    exchange] so that we neatly bypass all the ARP bootstraping problems.
    After the client has his real IP address (and that of the server),
    a normal TFTP file read occurs.  The client only accepts a BOOTACK with
    a CLIENT'S ETHERADDR that matches his own.

    BOOTACK packet from server to client:

	    IP DST: 255.255.255.255
Why 255.255.255.255.  Shouldn't this be "CLIENT'S IP ADDR"?
	    IP SRC: server IP address
	    PROTO: UDP
	    PORT: bootport
	    ----- packet data is:
	    OPCODE: BOOTACK
	    CLIENT'S ETHERADDR: xx xx xx xx xx xx
	    CLIENT'S IP ADDR: xx xx xx xx
	    DEFAULT GATE ADDR: xx xx xx xx
	    FILEVERSION: xx
	    FILEDATE: xx

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Wed 10 Jul 85 23:28:23-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        sun!l5!gnu@UCB-VAX.ARPA, imagen!geof@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: tftp for bootstrap
	We DO use existing, completely vanilla, TFTP servers. We use
TFTP as a file transfer only; figuring out which hosts to use and
what the filename is is done by some other path. For us, that path
is hardwired information. I understand that you might not like this
way of determining that information, but it has its advantages when
it comes to gateways. I don't think you should mess with TFTP to
add some special function; build some separate mechanism to do that,
and leave TFTP to be what I designed it as; a very simple file transfer
mechanism.
		Noel
-------
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Wed 10 Jul 85 23:40:38-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        croft@SU-SAFE.ARPA, sun!l5!gnu@UCB-VAX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: tftp for bootstrap
	Bill:

	Your suggestion is excellent. I must admit that I was originally
in favor of RARP (which was a Stanford production) since it seemed to
avoid muddying the protocol layers (i.e. avoided using IP at a stage
when it didn't know its IP address). However, as you point out, there
are valid practical reasons for using UDP.
	Also, let's not lose track of the EAROM option! This is needed
on non-broadcast networks, where you need some non-volatile storage
to store the basic information you need to run the TFTP. Maybe all
the Suns ever built will go on broadcast nets, but not everyone will
have that luxury.

	Noel
-------
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jul 85 07:59:15 edt
From:      Craig smelser <smelser%wang-inst.csnet@csnet-relay.ARPA>
To:        tcp-ip%ucbvax.CSNET@CSNET-RELAY.ARPA
Subject:   TCP/IP certification - anyone do it?
I would like to certify a TCP/IP transport.  Are there any 
companies or agencies that provide this kind of service?  Does anyone
out there have any experiences that would prove helpful to me.  Please respond
by mail.   Thanks in advance...

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jul 85 11:00:56 pdt
From:      Bill Croft <croft@safe>
To:        croft@safe, dcp@scrc-quabbin, tcp-ip@sri-nic
Subject:   Re: tftp for bootstrap
Dave,

That is a good point, if the server sending the 'bootreply' packet
has the kernel hooks to allow him to fill in an ARP table entry
'by hand', then the server CAN send the packet to the client's
new IP address.  I will mention this point in the RFC I am preparing.
However if such kernel hooks are missing from a particular operating
system, broadcasting the bootreply (as I mentioned earlier) is the
only way to get the packet out the door.
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jul 85 13:29:34 PDT
From:      tencati@jpl-vlsi.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Arpanet from Holland?

One of my users needs to get back to my machine from the netherlands.

He was told that SEISMO has an arpanet computer.  The only SEISMO I know of
is a uucp node.

Does anyone know how a user in Holland or Manchester, England could use 
TELNET and get back to an ARPAnet node?   Are there computers that act as
gateways?  I do not know which computer in Europe he will be using (by name).

Thanks for the help.

Ron Tencati
JPL-VLSI.ARPA

(My mailer may have munged the return address in the header)

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jul 85 12:56 EDT
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        Bill Croft <croft@SU-SAFE.ARPA>, David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA, cak@PURDUE.ARPA, John Gilmore <sun!l5!gnu@UCB-VAX.ARPA>
Subject:   Re: tftp for bootstrap
    Date: 10 Jul 1985 1008-PDT (Wednesday)
    From: Bill Croft <croft@safe>

    >Why 255.255.255.255.  Shouldn't this be "CLIENT'S IP ADDR"?
    >
    In the first phase, since the client DOESNT KNOW his IP address yet,
    if the server sent the reply to the client's (new) IP address, the
    server's ARP module would be unable to discover the client's hardware
    address.  That is why the server must broadcast this bootreply
    packet. 
Nope.  Recall that the user end already told the server end what the
Ethernet address is (otherwise how could the server backtranslate that
into an IP address?).  Therefore, it /should/ be a trivial matter to add
this into the ARP tables so it goes direct to the user end.

Anyway, a better argument against my proposal is that it requires the
user and server to be on the same cable.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jul-85 16:32:20 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: Bill Croft <croft@safe>

Dave,

That is a good point, if the server sending the 'bootreply' packet
has the kernel hooks to allow him to fill in an ARP table entry
'by hand', then the server CAN send the packet to the client's
new IP address.  I will mention this point in the RFC I am preparing.
However if such kernel hooks are missing from a particular operating
system, broadcasting the bootreply (as I mentioned earlier) is the
only way to get the packet out the door.

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jul-85 16:46:41 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: Bill Croft <croft@safe>

----
>Date: 09 Jul 85 13:30:31 EST (Tue)
>From: Christopher A Kent <cak@Purdue.EDU>
>
>Your protocol sounds really nice, except that IP broadcasting doesn't exist. 
>
Well it is implemented (perhaps non-standardly) in many Berkeley UNIXes.  
I hope that 4.3BSD implements the recommendations made by 
Jeff Mogul in RFC919/922.
Those RFCs use various forms of an IP address consisting of 'all ones'
or mostly ones to represent the broadcast address.

----
>Date: Wed, 10 Jul 85 08:45 EDT
>From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
>
>A more general scheme for this (actually, getting the IP address), which
>unfortunately requires implementing a slightly new protocol set is to
>implement inverse ARP (most servers can use existing forward ARP tables;
>
Dave, my argument was that it would be best to implement the first
phase protocol as ONLY an IP/UDP protocol.  This way the server can be
a user-level process (on UNIX, Multics, TOPS20, etc.) without requiring
kernel/operating system mods necessary for the "reverse ARP solution".
The authors of RFC903 DID implement 'reverse ARP' here at Stanford,
but it required using the 'CMU packet filter' kernel code to allow
a user-level server process to access arbitrary ethernet link level
packet types.  Any 'reverse ARP' scheme is going to require kernel
mods;  given that there are many different kernels out there now,
with each source maintained by different organizations, a boot
protocol that does not require kernel modifications I think is
an overwhelming advantage.

In addition, the protocol I illustrated provided several other pieces
of information that "reverse ARP" lacks:  (1) it allows server specification
by name, instead of just address;  (2) it returns IP addresses of
both the client and of gateways on the cable, to allow cross-net booting;
(3) it returns 'qualified' filename / version / date information.
Item #3 allows the client to specify a generic name in the bootrequest
(e.g. 'unix') and then the bootreply from the server could contain
a qualified name based upon database lookups at the server, indexed by
the client's hardware address.  For example, the person performing the
boot may ask to 'boot unix';  the bootreply returned from the server
may contain the qualified pathname '/usr/boot/vmunix123';  the second
phase boot (TFTP) then does a transfer of this new name.

>Why 255.255.255.255.  Shouldn't this be "CLIENT'S IP ADDR"?
>
In the first phase, since the client DOESNT KNOW his IP address yet,
if the server sent the reply to the client's (new) IP address, the
server's ARP module would be unable to discover the client's hardware
address.  That is why the server must broadcast this bootreply
packet.  I claim the slight extra overhead of this extra broadcast
is well worth it, since it allows our first phase server to use
only existing IP/UDP transmission (instead of implementing new
ethernet link types in the kernel).

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 1985 20:53 PST
From:      Art Berggreen <ART@ACC>
To:        tcp-ip@sri-nic
Subject:   RE: TCP/IP certification

DCA (Defense Communications Agency) is setting up a certification
system for protocols used with the DDN (Defense Data Network),
including TCP/IP.  I don't believe the TCP/IP testing is very
far along, but they should be contacted for details.

				"Art Berggreen"<Art@ACC.ARPA>

------
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jul-85 21:56:25 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Arpanet from Holland?

From: tencati@jpl-vlsi.arpa


One of my users needs to get back to my machine from the netherlands.

He was told that SEISMO has an arpanet computer.  The only SEISMO I know of
is a uucp node.

Does anyone know how a user in Holland or Manchester, England could use 
TELNET and get back to an ARPAnet node?   Are there computers that act as
gateways?  I do not know which computer in Europe he will be using (by name).

Thanks for the help.

Ron Tencati
JPL-VLSI.ARPA

(My mailer may have munged the return address in the header)

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jul-85 22:08:08 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   TCP/IP certification - anyone do it?

From: Craig smelser <smelser%wang-inst.csnet@csnet-relay.ARPA>

I would like to certify a TCP/IP transport.  Are there any 
companies or agencies that provide this kind of service?  Does anyone
out there have any experiences that would prove helpful to me.  Please respond
by mail.   Thanks in advance...

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jul-85 23:05:13 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: tftp for bootstrap

From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    Date: 10 Jul 1985 1008-PDT (Wednesday)
    From: Bill Croft <croft@safe>

    >Why 255.255.255.255.  Shouldn't this be "CLIENT'S IP ADDR"?
    >
    In the first phase, since the client DOESNT KNOW his IP address yet,
    if the server sent the reply to the client's (new) IP address, the
    server's ARP module would be unable to discover the client's hardware
    address.  That is why the server must broadcast this bootreply
    packet. 
Nope.  Recall that the user end already told the server end what the
Ethernet address is (otherwise how could the server backtranslate that
into an IP address?).  Therefore, it /should/ be a trivial matter to add
this into the ARP tables so it goes direct to the user end.

Anyway, a better argument against my proposal is that it requires the
user and server to be on the same cable.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13-Jul-85 00:39:41 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   RE: TCP/IP certification

From: Art Berggreen <ART@ACC>


DCA (Defense Communications Agency) is setting up a certification
system for protocols used with the DDN (Defense Data Network),
including TCP/IP.  I don't believe the TCP/IP testing is very
far along, but they should be contacted for details.

				"Art Berggreen"<Art@ACC.ARPA>

------

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Jul 85 14:31 EDT
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        ART@ACC.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   RE: TCP/IP certification
    Date: 12 Jul 1985 20:53 PST
    From: Art Berggreen <ART@ACC>


    DCA (Defense Communications Agency) is setting up a certification
    system for protocols used with the DDN (Defense Data Network),
    including TCP/IP.  I don't believe the TCP/IP testing is very
    far along, but they should be contacted for details.

I'm curious to know what happens when somebody fails certification.
What happens when the certification tests discover Unix sending
blatently wrong FTP and SMTP reply codes?  What happens when a system
does not handle overlapping segments (either correctly or at all)?
[There were a lot of these, many now fixed.]  What happens when the
TCP/IP is a product with a development to field time on the order of
months?


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13-Jul-85 15:00:39 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   RE: TCP/IP certification

From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    Date: 12 Jul 1985 20:53 PST
    From: Art Berggreen <ART@ACC>


    DCA (Defense Communications Agency) is setting up a certification
    system for protocols used with the DDN (Defense Data Network),
    including TCP/IP.  I don't believe the TCP/IP testing is very
    far along, but they should be contacted for details.

I'm curious to know what happens when somebody fails certification.
What happens when the certification tests discover Unix sending
blatently wrong FTP and SMTP reply codes?  What happens when a system
does not handle overlapping segments (either correctly or at all)?
[There were a lot of these, many now fixed.]  What happens when the
TCP/IP is a product with a development to field time on the order of
months?

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Mon 15 Jul 85 12:00:34-PDT
From:      Vivian Neou <Vivian@SRI-NIC.ARPA>
To:        tcp-ip-tenex@SRI-NIC.ARPA, tcp-ip-vms@SRI-NIC.ARPA, tcp-ip-unix@SRI-NIC.ARPA, tcp-ip-tops20@SRI-NIC.ARPA
Subject:   Discontinuation of these lists
Due to the low volume of traffic (one message per month at the most),
I am going to discontinue moderation of the specialized TCP-IP mailing
lists.  If you would like to be on the main TCP-IP mailing list please
send a message to TCP-IP-REQUEST@SRI-NIC.

Vivian Neou
VIVIAN@SRI-NIC
-------
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jul 85 14:22:32 edt
From:      Craig smelser <smelser%wang-inst.csnet@csnet-relay.ARPA>
To:        tcp-ip%ucbvax.CSNET@CSNET-RELAY.ARPA
Subject:   TCP/IP Training available?

Anyone know of courses specializing in the implementation of TCP/IP and their
related applications?  Please mail your response to me, and I'll post them to
the net.  Thanks in advance...

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jul-85 01:16:50 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   TCP/IP Training available?

From: Craig smelser <smelser%wang-inst.csnet@csnet-relay.ARPA>


Anyone know of courses specializing in the implementation of TCP/IP and their
related applications?  Please mail your response to me, and I'll post them to
the net.  Thanks in advance...

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      16 July 1985 1129-PDT (Tuesday)
From:      stanonik@nprdc.arpa (Ron Stanonik)
To:        unix-wizards@brl-tgr, tcp-ip@sri-nic
Subject:   4.2bsd/rlogin/source port choices
4.2bsd/rlogin's use of reserved ports for user authentication
seemed the cause of a little problem here.  While a user was
rlogin'ed from a sun to a vax, the sun crashed.  After the sun
rebooted the user was unable to rlogin to the vax (connection
timed out?), apparently because the vax still thought the previous
connection from the sun was established, and the sun was trying
to reuse the same reserved port.  (rlogin chooses the source port
from the first available port starting at 1023, working downward.)
Of course killing the login on the vax marked the connection closed
and cleared up the problem, but there must be a better/nonmanual
way.  Have we've overlooked a 4.2bsd mod which allows rlogin or
the tcp's to sort this out?

Thanks,

Ron Stanonik
stanonik@nprdc
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tuesday, 16 Jul 1985 16:32-PDT
From:      imagen!geof@su-shasta.ARPA
To:        shasta!stanonik@nprdc.ARPA (Ron Stanonik)
Cc:        shasta!unix-wizards@brl-tgr, shasta!tcp-ip@sri-nic
Subject:   Re: 4.2bsd/rlogin/source port choices

The TCP source port for rlogin should be chosen in a manner that makes
it unlikely for the same port to be reused twice in a row.  "Twice in a
row" includes the possibility that the ports will be chosen before and
after crashes, so a RAM counter is inappropriate.  4.2's apparent
method of grabbing closest port below 1024 that is not currently used
tends to choose the same port twice in a row with high probability in a
number of cases.  This algorithm is not suitable for choosing TCP port
numbers (Gosh, I hope the kernel does a better job!).

A better technique is to generate some random number in the right range
of ports each time a port number is needed, and regenerate another if
you fail.  A simple expediency is to use the low-order bits of a
millisecond clock.  A user process on Unix (with a one-second clock)
might use:

	long now;

	time(&now);
	sleep(1);
	port = htons( (now + getpid()) % 512) + 512 );

to get a number in the range [512,1024), or

	port = htons( (now + getpid()) | 0x8000 );

to get a port number in the "temporary" range.

- Geof
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jul 85 14:46:41 EDT
From:      dgibson@NSWC-OAS.ARPA
To:        tcp-ip-request@sri-nic
I am looking for some ideas as to why the following display appeared.
When trying to telnet to a micro class workstation from a VAX 
the message "no buffer space" appeared. I could not find that string 
in any of the code in source. The Vax runs Berkeley 4.2 TCP/IP and 
the workstation uses UNET's version of TCP/IP. 
The workstation is connected via an RS232 line over an LAN using the 
slattach command.
Can someone shed some light on this, point me in the right direction?
   Thanks Denise
   dgibson@nswc-oas

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jul-85 15:31:41 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   4.2bsd/rlogin/source port choices

From: stanonik@nprdc.arpa (Ron Stanonik)

4.2bsd/rlogin's use of reserved ports for user authentication
seemed the cause of a little problem here.  While a user was
rlogin'ed from a sun to a vax, the sun crashed.  After the sun
rebooted the user was unable to rlogin to the vax (connection
timed out?), apparently because the vax still thought the previous
connection from the sun was established, and the sun was trying
to reuse the same reserved port.  (rlogin chooses the source port
from the first available port starting at 1023, working downward.)
Of course killing the login on the vax marked the connection closed
and cleared up the problem, but there must be a better/nonmanual
way.  Have we've overlooked a 4.2bsd mod which allows rlogin or
the tcp's to sort this out?

Thanks,

Ron Stanonik
stanonik@nprdc

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 1985 20:32:36 EDT
From:      Anita Skelton <anita@EDN-UNIX.ARPA>
To:        tcp-ip at sri-nic.arpa
Subject:   RDP
Does anyone have any public domain Reliable Data Protocol code --
preferably Unix-based and in C?


-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jul-85 20:49:07 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: 4.2bsd/rlogin/source port choices

From: imagen!geof@su-shasta.ARPA


The TCP source port for rlogin should be chosen in a manner that makes
it unlikely for the same port to be reused twice in a row.  "Twice in a
row" includes the possibility that the ports will be chosen before and
after crashes, so a RAM counter is inappropriate.  4.2's apparent
method of grabbing closest port below 1024 that is not currently used
tends to choose the same port twice in a row with high probability in a
number of cases.  This algorithm is not suitable for choosing TCP port
numbers (Gosh, I hope the kernel does a better job!).

A better technique is to generate some random number in the right range
of ports each time a port number is needed, and regenerate another if
you fail.  A simple expediency is to use the low-order bits of a
millisecond clock.  A user process on Unix (with a one-second clock)
might use:

	long now;

	time(&now);
	sleep(1);
	port = htons( (now + getpid()) % 512) + 512 );

to get a number in the range [512,1024), or

	port = htons( (now + getpid()) | 0x8000 );

to get a port number in the "temporary" range.

- Geof

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jul-85 21:38:34 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   RDP

From: Anita Skelton <anita@EDN-UNIX.ARPA>

Does anyone have any public domain Reliable Data Protocol code --
preferably Unix-based and in C?

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jul 85 01:22:25 EDT
From:      Jon L. Spear <JSPEAR@MIT-MC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        JSPEAR@MIT-MC.ARPA
Subject:   How to connect a VAX/VMS 780 to MILNET?
We (Air Force Weapons Lab) have an IMP with only a PDP 11/50 that can sometimes
be depended upon to run FTP, but would like to improve the situation by
connecting a VAX/VMS machine to the IMP.  This 780 will be the gateway to
MILNET for a local network that we are trying to implement very soon
(broadband backbone with Ethernet subnets).  My questions:

1) What is the recommended way to physically connect a 780 to MILNET?

2) I have heard that VAX/VMS TCP/IP can be bought from Wollengong or gotten
from Tektronix and one other place who's name escapes me for minimal cost
(with minimal support).  Is there a recommended software package for TCP/IP?

3) What is the policy (current and anticipated) for X.25 connections to
MILNET/ARPANET, and should this be considered for our VAX?

(Please reply directly to me as I am not (yet) on the mailing list)

Thanks, Jon

---
Capt Jon Spear
JSpear@MIT-MC
AFWL/NTCTS Kirtland AFB, NM 87117-6008
(505)846-0582, av246-0582
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jul-85 02:16:05 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   How to connect a VAX/VMS 780 to MILNET?

From: Jon L. Spear <JSPEAR@MIT-MC.ARPA>

We (Air Force Weapons Lab) have an IMP with only a PDP 11/50 that can sometimes
be depended upon to run FTP, but would like to improve the situation by
connecting a VAX/VMS machine to the IMP.  This 780 will be the gateway to
MILNET for a local network that we are trying to implement very soon
(broadband backbone with Ethernet subnets).  My questions:

1) What is the recommended way to physically connect a 780 to MILNET?

2) I have heard that VAX/VMS TCP/IP can be bought from Wollengong or gotten
from Tektronix and one other place who's name escapes me for minimal cost
(with minimal support).  Is there a recommended software package for TCP/IP?

3) What is the policy (current and anticipated) for X.25 connections to
MILNET/ARPANET, and should this be considered for our VAX?

(Please reply directly to me as I am not (yet) on the mailing list)

Thanks, Jon

---
Capt Jon Spear
JSpear@MIT-MC
AFWL/NTCTS Kirtland AFB, NM 87117-6008
(505)846-0582, av246-0582

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jul 85 04:29:06 edt
From:      chris@columbia.arpa (Chris Maio)
To:        tcp-ip@sri-nic.arpa
Subject:   subnets for 4.2bsd
Does anyone have the necessary modifications to 4.2bsd to allow it to
do subnet routing?   I'd like to connect 3 or 4 ethernets and an imp to
a dedicated 11/750 running 4.2bsd networking code, and allow the ethernets
to appear contiguous as far as the host ip implementations are concerned,
by doing arp rebroadcasts and subnet routing in the gateway.  I know that
4.2bsd makes for a slow gateway, but until we find the money for a faster
gateway it'll have to do.  Does anyone have the code to do this?  Thanks.

- Chris
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jul-85 05:33:56 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   subnets for 4.2bsd

From: chris@columbia.arpa (Chris Maio)

Does anyone have the necessary modifications to 4.2bsd to allow it to
do subnet routing?   I'd like to connect 3 or 4 ethernets and an imp to
a dedicated 11/750 running 4.2bsd networking code, and allow the ethernets
to appear contiguous as far as the host ip implementations are concerned,
by doing arp rebroadcasts and subnet routing in the gateway.  I know that
4.2bsd makes for a slow gateway, but until we find the money for a faster
gateway it'll have to do.  Does anyone have the code to do this?  Thanks.

- Chris

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jul 85 6:19:13 EDT
From:      Bob Walsh <walsh@BBN-LABS-B.ARPA>
To:        Anita Skelton <anita@EDN-UNIX.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  RDP

I wrote the first implementation of RDP about a year ago now.  It runs
on some of our local VAXes and Butterfly Multiprocessors.  I am currently
working with Berkeley to get it released as a part of Berkeley 4.3BSD
UNIX.  The following is the standard response I sent out a year ago.

	--------


Sorry if you've already received some of this information, but as a
result of the interest generated by RDP I figured I'd collect everyone's
name and whip up a standard response.

The Reliable Datagram Protocol (RDP) is described in RFC 908.
Request For Comment documents may be obtained from the Network Information
Center at SRI.  The protocol specification is undergoing a little
change as a result of my work implementing it for 4.2 BSD on the VAX
and as a result of some work bringing it up on other devices here at
BBN.  Therefore, RFC 908 will not reflect the final version of RDP.

	> No changes have been made so far.  They seem to be on
	> a back burner (that may be turned off) until there is more
	> extensive experience with the protocol.

For example, port numbers will be 16 instead of 8 bits.  Some discussion
is also going on with reference to the checksumming algorithm, which is
sensitive to the byte ordering of the host.  The RFC also needs sections
better describing the acknowledgement, buffering, and flow control strategies
that the specifiers had in mind and the whys behind them so that diverse
implementations will work well together.

	> port numbers are still 8 bits.  The checksum is still as
	> described in the RFC.

Currently, the VAX code has worked since July 4 and has been used to bounce
packets off goonhilly-echo for days at a time.  (Goonhilly-echo is a good
test of a protocol implementation since it involves crossing several networks,
including a satellite net.  As a result, packet loss and sequencing code gets
well exercised.)  I don't think we'll make it generally available until the
specification is agreed upon after all input and testing has occured.  This
probably won't happen until at least September '84.

	> We're trying to avoid making tapes and verifying UNIX
	> licenses.  It would also be nice if it were easy to
	> integrate.  As a result, its going into 4.3BSD, which
	> should be released in the coming months.

Though the specification specifies downloading and debugging as applications
that will use RDP, the protocol is not limited to such.  BBN will be using RDP
in some distributed systems.  To my knowledge, no work has been done on
LDP (Loading and Debugging protocol) for the VAX.

	> Work for debugging the Butterfly remotely through an
	> LDP server is far along.  (LDP is meant to run over RDP).
	> However that work is separate.

Questions about how the work will be distributed should go to Rob Gurwitz
(ARPA address gurwitz@bbn).  I worry about the implementation and protocol
issues, and Rob administrates the project and deals with policy stuff like
code availability.

bob walsh
ARPA:  walsh@bbn-labs-b
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jul-85 07:24:30 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  RDP

From: Bob Walsh <walsh@BBN-LABS-B.ARPA>


I wrote the first implementation of RDP about a year ago now.  It runs
on some of our local VAXes and Butterfly Multiprocessors.  I am currently
working with Berkeley to get it released as a part of Berkeley 4.3BSD
UNIX.  The following is the standard response I sent out a year ago.

	--------


Sorry if you've already received some of this information, but as a
result of the interest generated by RDP I figured I'd collect everyone's
name and whip up a standard response.

The Reliable Datagram Protocol (RDP) is described in RFC 908.
Request For Comment documents may be obtained from the Network Information
Center at SRI.  The protocol specification is undergoing a little
change as a result of my work implementing it for 4.2 BSD on the VAX
and as a result of some work bringing it up on other devices here at
BBN.  Therefore, RFC 908 will not reflect the final version of RDP.

	> No changes have been made so far.  They seem to be on
	> a back burner (that may be turned off) until there is more
	> extensive experience with the protocol.

For example, port numbers will be 16 instead of 8 bits.  Some discussion
is also going on with reference to the checksumming algorithm, which is
sensitive to the byte ordering of the host.  The RFC also needs sections
better describing the acknowledgement, buffering, and flow control strategies
that the specifiers had in mind and the whys behind them so that diverse
implementations will work well together.

	> port numbers are still 8 bits.  The checksum is still as
	> described in the RFC.

Currently, the VAX code has worked since July 4 and has been used to bounce
packets off goonhilly-echo for days at a time.  (Goonhilly-echo is a good
test of a protocol implementation since it involves crossing several networks,
including a satellite net.  As a result, packet loss and sequencing code gets
well exercised.)  I don't think we'll make it generally available until the
specification is agreed upon after all input and testing has occured.  This
probably won't happen until at least September '84.

	> We're trying to avoid making tapes and verifying UNIX
	> licenses.  It would also be nice if it were easy to
	> integrate.  As a result, its going into 4.3BSD, which
	> should be released in the coming months.

Though the specification specifies downloading and debugging as applications
that will use RDP, the protocol is not limited to such.  BBN will be using RDP
in some distributed systems.  To my knowledge, no work has been done on
LDP (Loading and Debugging protocol) for the VAX.

	> Work for debugging the Butterfly remotely through an
	> LDP server is far along.  (LDP is meant to run over RDP).
	> However that work is separate.

Questions about how the work will be distributed should go to Rob Gurwitz
(ARPA address gurwitz@bbn).  I worry about the implementation and protocol
issues, and Rob administrates the project and deals with policy stuff like
code availability.

bob walsh
ARPA:  walsh@bbn-labs-b

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Wednesday, 17 Jul 1985 11:10-PDT
From:      imagen!geof@su-shasta.ARPA
To:        shasta!root%bu-cs.UUCP@harvard.ARPA
Cc:        shasta!tcp-ip@sri-nic.ARPA
Subject:   Re: 4.2bsd/rlogin/source port choices

The choices that I suggested are all things that I have done in
implementations of various protocols (which need to choose port numbers
for the same reason TCP does), and that have worked well.  I personally
think that low bits of clocks are more random than pseudo-random number
generators.  To get a really random number from a PRNG, you have to
seed it with a random number (egg or chicken?).  The obvious thing to
do is seed the PRNG with the clock.  Hmm....  why don't you just use
the clock...?

Using a clock also makes sense from a more theoretical point of view.
In most situations the times at which connection requests are made are
much more like independent random variables than anything else that a
program can get its hands on.  Especially when you have a fast clock.

Of course, any choice of port is actually put inside of a loop which
makes sure that the port is Currently unique.  You can't be sure of not
choosing the same port twice Sequentially unless you have hardware that
is stable across system crashes (hey, the clock is more likely to fit
that criterion than anything else, isn't it...?).  If "portChoice()"
chooses a port number using whatever algorithm you have in mind (but
"1023" is probably not a good algorithm), then you need one of the
following program fragments (sometimes this fragment is embodied in the
kernel, which is an excellent idea):

	i := portChoice();
	while portInUse(i) do
		i := i + 1;

		or

	i := portChoice();
	while portInUse(i) do
		i := portChoice();

The one to use depends on the nature of you portChoice() procedure.  If
it is based on a one second clock, then maybe the first program
fragment is better.  If it is based on a microsecond clock, then the
two are probably equivalent, but I like the second better, perhaps for
irrational reasons.  In any event, if you have a good portChoice()
algorithm, you will almost never go through the loop more than once,
and if you often go through it more than twice, rewrite portChoice,
because it isn't working as it should.

- Geof
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jul-85 15:40:54 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: 4.2bsd/rlogin/source port choices

From: imagen!geof@su-shasta.ARPA


The choices that I suggested are all things that I have done in
implementations of various protocols (which need to choose port numbers
for the same reason TCP does), and that have worked well.  I personally
think that low bits of clocks are more random than pseudo-random number
generators.  To get a really random number from a PRNG, you have to
seed it with a random number (egg or chicken?).  The obvious thing to
do is seed the PRNG with the clock.  Hmm....  why don't you just use
the clock...?

Using a clock also makes sense from a more theoretical point of view.
In most situations the times at which connection requests are made are
much more like independent random variables than anything else that a
program can get its hands on.  Especially when you have a fast clock.

Of course, any choice of port is actually put inside of a loop which
makes sure that the port is Currently unique.  You can't be sure of not
choosing the same port twice Sequentially unless you have hardware that
is stable across system crashes (hey, the clock is more likely to fit
that criterion than anything else, isn't it...?).  If "portChoice()"
chooses a port number using whatever algorithm you have in mind (but
"1023" is probably not a good algorithm), then you need one of the
following program fragments (sometimes this fragment is embodied in the
kernel, which is an excellent idea):

	i := portChoice();
	while portInUse(i) do
		i := i + 1;

		or

	i := portChoice();
	while portInUse(i) do
		i := portChoice();

The one to use depends on the nature of you portChoice() procedure.  If
it is based on a one second clock, then maybe the first program
fragment is better.  If it is based on a microsecond clock, then the
two are probably equivalent, but I like the second better, perhaps for
irrational reasons.  In any event, if you have a good portChoice()
algorithm, you will almost never go through the loop more than once,
and if you often go through it more than twice, rewrite portChoice,
because it isn't working as it should.

- Geof

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 1985 00:19 PDT (Fri)
From:      Allan M. Schiffman <Schiffman@SRI-KL>
To:        tcp-ip at sri-nic
Subject:   Tektronix's TCP/IP for VMS?
I'm sure I've been told about this before, but what's the scoop
on Tektronix's implementaion of TCP/IP for VMS?  Is it available?
Is it any good?  Who do I contact?

Please reply to me directly.

Thanks,

-Allan
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jul-85 04:52:19 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Tektronix's TCP/IP for VMS?

From: Allan M. Schiffman <Schiffman@SRI-KL>

I'm sure I've been told about this before, but what's the scoop
on Tektronix's implementaion of TCP/IP for VMS?  Is it available?
Is it any good?  Who do I contact?

Please reply to me directly.

Thanks,

-Allan

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Fri 19 Jul 85 10:55:24-PDT
From:      Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   TCP/IP information available online

This is perhaps a good time to remind you that the file

	[SRI-NIC.ARPA]<NETINFO>TCP-IP-IMPLEMENTATIONS.TXT

is available with anonymous FTP and contains information on TCP
implementations for various systems. We encourage people to send
additions/corrections in the same format to NIC@SRI-NIC.ARPA.


Ole for the NIC
-------
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 85 11:35:42 EDT
From:      Roy <MARANTZ@RUTGERS.ARPA>
To:        Tops-20@SU-SCORE.ARPA, TCP-IP@SRI-NIC.ARPA
Cc:        Marantz@RUTGERS.ARPA
Subject:   TCP/UDP echo ...
Does anyone have user level code that will be an Echo user (UDP and/or
TCP)?  I have a server for UNIX and want a corresponding user program
for it.  I'd like it to run on 4.2BSD UNIX (Pyramid 90x and Sun),
Tops-20, VMS (Wollongon TCP software), and an IBM-PC running the MIT
TCP/IP code; but an willing to transport code if need be.  I'd also like
to be able to use the character generator (infinite source) and
character eater (infinite sink) services.  I want to test our network
(reachability) with this and also (if possible) get a measure of delays
between various machines and through various routes and some kind of
throughput figure.  Thanks for any help, pointers, whatever.  Please
feel free to pass this on to anyone who might be helpful.  I'll post a
summary of responses if someone wants them.

Roy
-------
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jul 85 12:50:06 CDT
From:      Jerry Morence <morence@Almsa-2>
To:        kovalcik@Mit-Multics.arpa
Cc:        tcp-ip@Sri-Nic.arpa
Subject:   more hyperchannel info


   Richard:

   Regarding your message dated Sun 30 Jun 85 19:18:05 PDT, subj: TCP/IP  on
   Hyperchannel.

   In ref. msg., you stated you had problems with  message  collision  which
   resulted in manual resets of the hyperchannel adapters.

   In three years of  operation  at  six  different  sites,  we  have  never
   experienced this problem.  Our traffic workload at each of these sites is
   measured in gigabytes on a daily basis.  We only use  A220/A222  adapters
   with  a  dead-man-timer  of  500 milliseconds.  Our hosts must be able to
   retrieve all messages in this time frame or the message could be lost.

   The A220/A222 adapters recognize when a buffer at a  destination  adapter
   is  full  and  report  back  to  our  software  that the message can't be
   delivered;  our software will requeue the message for  retry  within  one
   second.   This will continue until the destination buffer is freed either
   by the destination host retrieving the message or by  the  dead-man-timer
   causing   an  automatic  release  (and  potential  loss).   Our  software
   recognizes  when  the  dead-man-timer  has   expired   and   requests   a
   retransmission  from  the originator; the information for this request is
   contained within the message proper for the lost message which is held by
   the A220/A222 adapter in a separate buffer (there are eight of these type
   buffers).  In the case where our software on the send side may do a retry
   at   the   same  time  our  software  on  the  receive  side  requests  a
   retransmission,  our  software  detects  this  situation   and   prevents
   sending/receiving a duplicate.

   If an application crashes, our software recognizes this and takes  action
   to  quiesce all connections to the crashing application without impacting
   other connections in such a manner that facilitates recovery and does not
   demand termination of the connected applications.

   In all these years of production, we  have  never  needed  to  reset  the
   adapters,  we have never lost nor duplicated data, and we are achieving a
   minimum of 30 megabits per second of real data throughput.  In  the  near
   future,  we  will be experimenting with an A440 adapter, connecting a VAX
   780 to the Hyperchannel.  Maybe we will then experience the same problems
   you have been reporting.

   Regards,
   Jerry


-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jul-85 12:37:58 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   TCP/UDP echo ...

From: Roy <MARANTZ@RUTGERS.ARPA>

Does anyone have user level code that will be an Echo user (UDP and/or
TCP)?  I have a server for UNIX and want a corresponding user program
for it.  I'd like it to run on 4.2BSD UNIX (Pyramid 90x and Sun),
Tops-20, VMS (Wollongon TCP software), and an IBM-PC running the MIT
TCP/IP code; but an willing to transport code if need be.  I'd also like
to be able to use the character generator (infinite source) and
character eater (infinite sink) services.  I want to test our network
(reachability) with this and also (if possible) get a measure of delays
between various machines and through various routes and some kind of
throughput figure.  Thanks for any help, pointers, whatever.  Please
feel free to pass this on to anyone who might be helpful.  I'll post a
summary of responses if someone wants them.

Roy
-------

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jul-85 15:04:13 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   TCP/IP information available online

From: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>

SRI International: (415) 859-4536  Home: (415) 325-9427


This is perhaps a good time to remind you that the file

	[SRI-NIC.ARPA]<NETINFO>TCP-IP-IMPLEMENTATIONS.TXT

is available with anonymous FTP and contains information on TCP
implementations for various systems. We encourage people to send
additions/corrections in the same format to NIC@SRI-NIC.ARPA.


Ole for the NIC
-------

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jul-85 16:03:28 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   more hyperchannel info

From: Jerry Morence <morence@Almsa-2>



   Richard:

   Regarding your message dated Sun 30 Jun 85 19:18:05 PDT, subj: TCP/IP  on
   Hyperchannel.

   In ref. msg., you stated you had problems with  message  collision  which
   resulted in manual resets of the hyperchannel adapters.

   In three years of  operation  at  six  different  sites,  we  have  never
   experienced this problem.  Our traffic workload at each of these sites is
   measured in gigabytes on a daily basis.  We only use  A220/A222  adapters
   with  a  dead-man-timer  of  500 milliseconds.  Our hosts must be able to
   retrieve all messages in this time frame or the message could be lost.

   The A220/A222 adapters recognize when a buffer at a  destination  adapter
   is  full  and  report  back  to  our  software  that the message can't be
   delivered;  our software will requeue the message for  retry  within  one
   second.   This will continue until the destination buffer is freed either
   by the destination host retrieving the message or by  the  dead-man-timer
   causing   an  automatic  release  (and  potential  loss).   Our  software
   recognizes  when  the  dead-man-timer  has   expired   and   requests   a
   retransmission  from  the originator; the information for this request is
   contained within the message proper for the lost message which is held by
   the A220/A222 adapter in a separate buffer (there are eight of these type
   buffers).  In the case where our software on the send side may do a retry
   at   the   same  time  our  software  on  the  receive  side  requests  a
   retransmission,  our  software  detects  this  situation   and   prevents
   sending/receiving a duplicate.

   If an application crashes, our software recognizes this and takes  action
   to  quiesce all connections to the crashing application without impacting
   other connections in such a manner that facilitates recovery and does not
   demand termination of the connected applications.

   In all these years of production, we  have  never  needed  to  reset  the
   adapters,  we have never lost nor duplicated data, and we are achieving a
   minimum of 30 megabits per second of real data throughput.  In  the  near
   future,  we  will be experimenting with an A440 adapter, connecting a VAX
   780 to the Hyperchannel.  Maybe we will then experience the same problems
   you have been reporting.

   Regards,
   Jerry

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 1985 21:04:30 PDT
From:      POSTEL@USC-ISIF.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Protocol Testing

For information about protocol testing or certification for DDN contact:

Robert Philbrook

Philbrook@DDN1.ARPA

703-285-5035

--jon.
-------
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21-Jul-85 00:59:42 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Protocol Testing

From: POSTEL@USC-ISIF.ARPA


For information about protocol testing or certification for DDN contact:

Robert Philbrook

Philbrook@DDN1.ARPA

703-285-5035

--jon.
-------

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jul 85 12:19:41 PDT
From:      tencati@jpl-vlsi.arpa
To:        tcp-ip@sri-nic.arpa
Subject:   Problems with ACC's LHDH/ECU  HOST/IMP interfaces?
I am trying to trace down a problem JPL is having, and I would like to poll
the user community.

We are configured to our IMP via an ACC LHDH and ACC Error Correcting Unit
on the host-side of our arpanet connection, and another ECU which is connected
to the IMP at the other end.  

There are two computers (11/780's) configured this way.  The HOST/IMP
connection consists of about 30 miles of leased line from AT&T at 9600 baud on
one computer, and about a 5-mile microwave connection at 56Kb on the other
computer. 

We sporadically get "no buffer space" messages when we try to rwe try to run the network
code (telnet, ftp, mail, finger) on these VMS machines.  It appears that the
ECU's don't communicate with each other at times.  Pushing the RESET button on
either ECU does not force an "Interface Reset" message from the software. 
Bit-error tests over the link between the ECU's pass without errors.  We hook
the ECU's back up, and it won't work.  Rebooting the machine(s) does not help.  
Then, suddenly, magically, everything works again.  No clues... 

I've talked with ACC.  They don't have any ideas.  I've talked with Wollongong 
with the same result.

Does anyone running Kashtan beta-test or Wollongong on a VMS machine (V3.7 and 
up) have any similar experience, or better yet, a fix???  

I would like to collect information from all sites who use LHDH interfaces and
the ACC ECU's.  What is the interface between your host and IMP (Ethernet, 
leased line, microwave, other)?  How fast is the data connection?  Do you have
any "strange" things happen from time to time?   How do you clear them?

I would appreciate hearing from as many sites as I can.  Please send directly
to me.  If I get useful data, I will summarize it.  Maybe ACC and I can get to 
the bottom of this.

Thanks much,
   Ron Tencati
   TENCATI@JPL-VLSI.ARPA
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 1985 14:02-PDT
From:      the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>
To:        tcp-ip@NIC
Subject:   Interactive traffic punishment via MILNET?
For the last few months we have noticed a dreadful condition that
seems to strike with a good deal of regularity when using a
MILNET TAC to connect to an ARPANET Host.  The same thing also
happens when using a local network host gatwayed into the ARPANET
which in turn ends up at a MILNET TAC.

Specifically, this has to do with interactive "links" where two
users are TALKing to one another and there are single character
packets in both directions.  The symptom is that the person at
the TAC's output goes into molasses mode where they receive a
character from the host once every second or so.  This happens on
two different operating systems (Tenex and TOPS-20), and as i
said with directly connected ARPANET hosts as well as those
behind a local network gateway.

Any ideas was is exacerbating this situation?  Anyone else out
there experienced it?

g
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Wed 24 Jul 85 15:08:18-PDT
From:      LARSON@SRI-KL.ARPA
To:        Geoff@SRI-CSL.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interactive traffic punishment via MILNET?
  I published a discussion of this problem on the tops-20 mailing
list a month or two ago.  The situation seems to result from round
trip time estimates being calculated incorrectly.
  I have a 'fix' that seems to make things better.  It is installed
on SRI-KL.
	Alan
-------
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jul-85 18:14:18 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Interactive traffic punishment via MILNET?

From: the tty of Geoffrey S. Goodfellow <Geoff@SRI-CSL.ARPA>

For the last few months we have noticed a dreadful condition that
seems to strike with a good deal of regularity when using a
MILNET TAC to connect to an ARPANET Host.  The same thing also
happens when using a local network host gatwayed into the ARPANET
which in turn ends up at a MILNET TAC.

Specifically, this has to do with interactive "links" where two
users are TALKing to one another and there are single character
packets in both directions.  The symptom is that the person at
the TAC's output goes into molasses mode where they receive a
character from the host once every second or so.  This happens on
two different operating systems (Tenex and TOPS-20), and as i
said with directly connected ARPANET hosts as well as those
behind a local network gateway.

Any ideas was is exacerbating this situation?  Anyone else out
there experienced it?

g

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Wed 24 Jul 85 20:44:39-MDT
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        Geoff@SRI-CSL.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interactive traffic punishment via MILNET?
Welcome to the club.  This problem is with much more than links,
as just about anybody who does interactive character-at-a-time
traffic between MILNET and ARPANET has found out.  I've taken to
putting my TELNET into local echo mode and using the local line
editor to compose messages line at a time.  I don't even try to
do any editing across the gateways any more.

I believe BBN is doing some work on the problem.

-- Mark --
-------
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jul-85 19:51:31 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Interactive traffic punishment via MILNET?

From: LARSON@SRI-KL.ARPA

  I published a discussion of this problem on the tops-20 mailing
list a month or two ago.  The situation seems to result from round
trip time estimates being calculated incorrectly.
  I have a 'fix' that seems to make things better.  It is installed
on SRI-KL.
	Alan
-------

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 85 21:08:24 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tencati@JPL-VLSI.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Problems with ACC's LHDH/ECU  HOST/IMP interfaces?
We use a pair of ECU's between a DEC-20 and an IMP.  Both connections
are local host.  The ECU's are connected by a 9600 baud line from
ATT, using ATT modems.  The only strange things I have seen are
failures, almost always of the line.  We have had one ECU failure
in several years.
-------
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jul-85 22:04:39 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Problems with ACC's LHDH/ECU  HOST/IMP interfaces?

From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>

We use a pair of ECU's between a DEC-20 and an IMP.  Both connections
are local host.  The ECU's are connected by a 9600 baud line from
ATT, using ATT modems.  The only strange things I have seen are
failures, almost always of the line.  We have had one ECU failure
in several years.
-------

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jul-85 23:29:44 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Interactive traffic punishment via MILNET?

From: Mark Crispin <MRC@SIMTEL20.ARPA>

Welcome to the club.  This problem is with much more than links,
as just about anybody who does interactive character-at-a-time
traffic between MILNET and ARPANET has found out.  I've taken to
putting my TELNET into local echo mode and using the local line
editor to compose messages line at a time.  I don't even try to
do any editing across the gateways any more.

I believe BBN is doing some work on the problem.

-- Mark --
-------

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jul 85 23:40:33 EDT
From:      Martin Lee Schoffstall <schoff%rpi.csnet@csnet-relay.arpa>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        schoff%rpi.csnet@csnet-relay.arpa
Subject:   4.2bsd UNIX name server implementation

would anyone care to share their implementation?

marty
schoff%rpics@csnet-relay
seismo!rpics!schoff
(518) 271-2654

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu 25 Jul 85 00:19:57-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        MRC@SIMTEL20.ARPA, Geoff@SRI-CSL.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: Interactive traffic punishment via MILNET?
	It's not MILNET <-> ARPANet. I've been pissing and wailing
about this on MIT-XX since 1980; at that point traffic from my
machine to MIT-XX went in via a LAN connected to my machine and
a front end PDP11 on the 20; no 1822 nets at all.
	It still happens, although the configuration is a little
different now. There's still no ARPANET<->MILNET gateway, though.
It seems to happen whenever I type any distance ahead of the echoing.

	Noel
-------
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 01:21:35 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Interactive traffic punishment via MILNET?

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	It's not MILNET <-> ARPANet. I've been pissing and wailing
about this on MIT-XX since 1980; at that point traffic from my
machine to MIT-XX went in via a LAN connected to my machine and
a front end PDP11 on the 20; no 1822 nets at all.
	It still happens, although the configuration is a little
different now. There's still no ARPANET<->MILNET gateway, though.
It seems to happen whenever I type any distance ahead of the echoing.

	Noel
-------

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 02:19:39 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   4.2bsd UNIX name server implementation

From: Martin Lee Schoffstall <schoff%rpi.csnet@csnet-relay.arpa>


would anyone care to share their implementation?

marty
schoff%rpics@csnet-relay
seismo!rpics!schoff
(518) 271-2654

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 08:51:49 pdt
From:      ucdla%ucbtopaz.CC@Berkeley
To:        @sri-nic.arpa%ucbtopaz.CC@Berkeley, tcp-ip@sri-nic.ARPA
Subject:   A Noop Strategy for TCP

I am wondering if anyone has developed a strategy by which TCP can inquire
on the aliveness of connections on some regular interval (perhaps time
driven). A problem has occurred for us in TELNET where connections
abort or otherwise go away without being properly closed and our TELNET
never finds out about if there is no activity on the connection. The
INTERNET Implemation workbook suggests having TELNET negotiate some
meaningless option every so often as a way of finding out if the other
side is still there. This will fix our problem but I would like to fix it
in TCP if possible so that they same fix will apply to all higher level
protocols that use TCP without the need for them to do it themselves.
Comments and suggestions would be most welcome
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 08:56:22 pdt
From:      ucdla%ucbtopaz.CC@Berkeley
To:        tcp-ip@sri-nic.ARPA
Subject:   test

this is a test of the \berkeley unix mail facility since it is the first
time i am using it. plz disregard this note
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 08:46:12 edt
From:      cperry@mitre (Chris Perry)
To:        tcp-ip@sri-nic.ARPA
Subject:   New Name
Please add Raj Mishra's name (MISHRA@MITRE.ARPA) to
the TCP-IP mailing list.
Thanks.
Chris
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu 25 Jul 85 11:23:45-MDT
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        ucdla%ucbtopaz.CC@UCB-VAX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: A Noop Strategy for TCP
     Hear hear!  This is a great idea.  It is one thing to provide
connection continuation across a service interruption (a real win
on satellite links!) but it is quite another to keep an idle
connection around for days until the operator nukes it.

     I suggest using some sort of zero-window probing, and consider
the other end to be down if there is a no-reply condition or if the
hardware level (e.g. 1822) has a "host down" condition and reports
that (this slightly violates the modularity of TCP, but if you're
careful you can make it into some sort of "signal to TCP from
hardware level" which isn't too kludgy).  There should be a minimum
"keep time" for the connection to come back -- say 30 minutes to an
hour -- after which the host should discard the connection even if
it doesn't get a reset from the other host.

     If a host comes back from a service interruption without a
reload, it should immediately probe all its connections to see what
connections are still valid and immediately nuke all the ones which
don't answer or reset.
-------
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 09:25:26 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   New Name

From: cperry@mitre (Chris Perry)

Please add Raj Mishra's name (MISHRA@MITRE.ARPA) to
the TCP-IP mailing list.
Thanks.
Chris

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 12:28:34 PDT
From:      Rich Wales <wales@UCLA-LOCUS.ARPA>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Some sites STILL using non-domain nicknames
I originally posted the following to NAMEDROPPERS@SRI-NIC.ARPA -- but it
was suggested to me that many of the hosts in question might not have
any NAMEDROPPERS readers, and that I would be more likely to get to more
of the right people by posting to TCP-IP.

So -- with apologies to those of you who already saw this message on
NAMEDROPPERS, and/or those of you who have nothing to do with mail . . .

Quite a few sites are STILL sending out mail with old, non-domain-style
host names in the return addresses.  (E.g.:  "fred@PODUNK-CS" -- instead
of "fred@PODUNK-CS.ARPA", or maybe "fred@CS.PODUNK.EDU".)

Since these non-domain-style names are NEVER going to be included in
the new distributed domain data base, any host which has completed the
switch to the domain mechanism will no longer be able to reply to mail
whose return address bears one of these old names.

************************************************************************
*    QUICK CHECK:  If return addresses on your system don't have AT    *
*       LEAST ONE period after the at-sign, you have work to do.       *
************************************************************************

The following offenders were represented in the last week's worth of
mail received here at UCLA-LOCUS.ARPA:

  AERO2         CIT-VAX        ISI-VAXA      NRL-CSS       TOVE
  AIDS-UNIX     CVL            LBL-CSAM      NYU-CMCL2     UCI-ICSA
  ALMSA-2       GE-CRD         MARYLAND      RAND-UNIX     UCI-ICSD
  BERKELEY      GREGORIO       MIT-COMET     SRI-SPAM      UTAH-CS
  CIT-750       ISI-HOBGOBLIN  NCSC          SRI-UNIX

One or two of the above-listed sites account for a LOT of mail.

I suspect I will -- quite reluctantly -- end up hacking our outgoing
mailer daemon to add ".ARPA" to non-domain-style host names before
trying to look them up in the domain data base.

On principle, I shouldn't have to do this kind of thing . . .
and I don't really want to, because it's a Disgustingly Evil Hack . . .
and it won't even work all the time (e.g., GREGORIO.ARPA is bogus) . . .

. . . but as long as so many hosts continue to generate return addresses
that have no hope at all of working under the domain scheme, I see no
alternative if I am to continue to support a large (and frequently
naive) community of users who are totally unprepared to figure out what
to do if someone else's return address doesn't work.

One person suggested that I should modify my mail system to reject all
incoming mail with a non-domain-style host name in the return address.
While this might give the users of the offending hosts a little bit more
incentive to lean on their local mail gurus, it would also give the
disgruntled would-be recipients of such mail here at UCLA a little bit
more incentive to look for a silver platter to serve my head on!

I should mention, by the way, that I have been in touch with people at
Berkeley (one of the offending hosts listed above); they are aware of
the problem and are working on fixing their system.  Hopefully, then,
they will not show up on my "list" the next time I compile one.

-- 
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@UCLA-LOCUS.ARPA  -or-  wales@LOCUS.UCLA.EDU
	UUCP:   ...!(ihnp4,ucbvax)!ucla-cs!wales
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thursday, 25 Jul 1985 13:00-PDT
From:      imagen!geof@su-shasta.ARPA
To:        shasta!ucdla%ucbtopaz.CC@Berkeley
Cc:        shasta!tcp-ip@sri-nic.ARPA
Subject:   Re: A Noop Strategy for TCP

It seems that every now and then someone new brings up the topic of
keep-alives again.  I guess that I'll be the one (probably of many) to
answer this time.

TCP is a general purpose protocol, which is used over networks where
bandwidth is cheap and over networks where bandwidth is expensive. 
Since a major goal of the Internet protocol is to abstract the exact
nature of the network(s) in use, it is almost always impossible for a
host to know what networks a TCP connection is using (Indeed, the
connection may be using more than one set of networks).

The only way to verify that a TCP connection is working is to send a
packet over the connection.  On some networks, this costs money.  On
others it costs processing time in loaded gateways.  In short, it would
unacceptably expensive for TCP implementations that use SOME parts of
the Internet to probe the connection every so often just to verify that
the connection is still there.  Since an implementation has no way of
knowing what parts of the Internet it is using, this sort of probe was
left out of TCP-IP.

This means that probing the connection is left as a higher-level issue,
one that TCP explicitly does not deal with.  This is actually a good
idea for another reason.  Some protocols don't need to verify that an
idle connection is still around, because they always push data through
that connection.  Other implementations don't need to determine that
the connection has gone down until they are actually needed again.  For
example, a TAC never times out its TCP connection -- it relies on the
human user (which is always present) to decide for himself that the
connection is dead.

If you need to generate timeouts on your telnet programs, the place to
do it is within telnet itself.  Now you can understand why the telnet
specification suggests sending bogus option negotiations (the other
thing to do is to send AYT's, but some hosts do silly things with them,
like converting them into random control characters that are sent to an
application).

One more thing: at MIT we used to have problems with gateways crashing.
Sometimes (in the early days) a gateway would crash for ten or fifteen
minutes.  How elated were we that TCP does not send keep-alive probes,
since they would have determined (in their cleverness) that the
connection should have been reset, while we human users had higher level
information (Mr. Chiappa yelling down the hall) that the connection
would soon return to good health.

- Geof
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 12:37:20 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   A Noop Strategy for TCP

From: ucdla@ucbtopaz.CC


I am wondering if anyone has developed a strategy by which TCP can inquire
on the aliveness of connections on some regular interval (perhaps time
driven). A problem has occurred for us in TELNET where connections
abort or otherwise go away without being properly closed and our TELNET
never finds out about if there is no activity on the connection. The
INTERNET Implemation workbook suggests having TELNET negotiate some
meaningless option every so often as a way of finding out if the other
side is still there. This will fix our problem but I would like to fix it
in TCP if possible so that they same fix will apply to all higher level
protocols that use TCP without the need for them to do it themselves.
Comments and suggestions would be most welcome

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 13:22:00 EDT
From:      louie@umd5 (Louis Mamakos)
To:        tcp-ip@sri-nic
Subject:   Re:  A Noop Strategy for TCP
Please! Don't try to 'fix' TCP.  I don't want my TCP to generate network
traffic on an idle connection.  The TELNET protocol has a method to 
accomplish what you want;  send a TELNET NOOP control sequence, or
negotiate the timing mark option.

If your application cares about an idle connection, let it probe the remote
host.  
	
If you are running IP over an X.25 PDN where you pay by the packet, having
and idle TCP connection stay idle can save you real dollars.  I'm sure
the CSNET folks can talk to this issue.

Now, if I can just get the stupid user TELNET programs out there that
talk to my line-at-a-time Sperry system to send the CR-LF sequence instead
of just a LF to end the line.  The 4.2 BSD TELNET is a notable offender.

Louis A. Mamakos WA3YMH   University of Maryland, Computer Science Center
 Internet: louie@umd5.arpa
 UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 14:04 EDT
From:      "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA>
To:        ucdla%ucbtopaz.CC@UCB-VAX.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: A Noop Strategy for TCP
My recommendation is that you send out an unsolicited acknowledgement
every 5 minutes or so when there is no activity of any kind on the
connection.  Activity is defined as any traffic, incoming or outgoing.
Thus, in practice only one end of the connection will be pinging the
other, since the receipt of such an unsolicited acknowledgement would
constitute activity.  If the host at the other end of the connection has
crashed, there will be no response to the ping at the TCP level, and
most TCP implementations don't understand ICMP destination unreachable
messages anyway.  However, when the host comes back up, the unsolicited
ack will elicit a reset, aborting the half-connection.

If your TCP implements ICMP destination unreachable messages, you
probably don't want to actually reset a connection because of one unless
the destination remains unreachable for some period of time, such as the
transmission timeout.  Given a little time, IP routing may find another
route or the gateway may come back up.  Multics uses transmission
timeouts of typically one minute.

Pinging is in disrepute these days because of network loading which it
causes.  On the good side, you are only pinging connections which are in
the established state, and if the clocks of the system are not perfectly
in step (well, "clocks" is an oversimplification) and the packet
dropping rate is low, only one system will be doing the pinging every
ping interval.  If different timeouts are used based on whether the
activity was transmission or reception, the systems can take turns doing
the pinging.  The ping interval can be quite long, perhaps several
minutes, since it is not constrained to be less than a transmission
timeout interval.  On the bad side, you are pinging for each connection,
not just for each host or even first hop gateway.

The rationale for leaving the pinging to the next higher level protocol
(telnet negotiations) is that then only telnet connections will present
this additional load on the network.  I think this is a crock of your
least favorite substance.  This means that ANY protocol or application
which is potentially idle for long periods must reinvent this wheel.  I
think that any application with humans in the loop will require this,
and that most other applications (e.g., SMTP, FTP data connections,
finger) do not have TCP connections sitting idle in both directions for
extended periods of time anyway.  A reliable stream protocol should be
more reliable than TCP is at telling its clients that the connection has
gone away.

Most real TCP implementations have ways of passing this information
around.  For example, if the client is blocked on read it has to handle
an abort, and a telnet user has to be able to receive urgent data to
implement Interrupt Process, even though these mechanisms are not
formally part of the TCP spec.

Multics does not do this pinging (yet?), and I know of no implementation
which does.  Would anyone care to offer additional reasons why
implementations should NOT do this, and why the TCP spec shouldn't be
amended?
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 14:24:58 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   test

From: ucdla@ucbtopaz.CC


this is a test of the \berkeley unix mail facility since it is the first
time i am using it. plz disregard this note

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 15:35:13 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  A Noop Strategy for TCP

From: louie@umd5 (Louis Mamakos)

Please! Don't try to 'fix' TCP.  I don't want my TCP to generate network
traffic on an idle connection.  The TELNET protocol has a method to 
accomplish what you want;  send a TELNET NOOP control sequence, or
negotiate the timing mark option.

If your application cares about an idle connection, let it probe the remote
host.  
	
If you are running IP over an X.25 PDN where you pay by the packet, having
and idle TCP connection stay idle can save you real dollars.  I'm sure
the CSNET folks can talk to this issue.

Now, if I can just get the stupid user TELNET programs out there that
talk to my line-at-a-time Sperry system to send the CR-LF sequence instead
of just a LF to end the line.  The 4.2 BSD TELNET is a notable offender.

Louis A. Mamakos WA3YMH   University of Maryland, Computer Science Center
 Internet: louie@umd5.arpa
 UUCP: {seismo!umcp-cs, ihnp4!rlgvax}!cvl!umd5!louie

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 85 16:28:43 EDT (Thu)
From:      mgardner@BBNCC5.ARPA
To:        Mark Crispin <MRC@SIMTEL20.ARPA>
Cc:        Geoff@SRI-CSL.ARPA, tcp-ip@SRI-NIC.ARPA, mgardner@BBNCC5.ARPA
Subject:   Re: Interactive traffic punishment via MILNET?
BBN is well aware of the problems and are working on them.

--Marianne
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 16:47:12 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP

From: Mark Crispin <MRC@SIMTEL20.ARPA>

     Hear hear!  This is a great idea.  It is one thing to provide
connection continuation across a service interruption (a real win
on satellite links!) but it is quite another to keep an idle
connection around for days until the operator nukes it.

     I suggest using some sort of zero-window probing, and consider
the other end to be down if there is a no-reply condition or if the
hardware level (e.g. 1822) has a "host down" condition and reports
that (this slightly violates the modularity of TCP, but if you're
careful you can make it into some sort of "signal to TCP from
hardware level" which isn't too kludgy).  There should be a minimum
"keep time" for the connection to come back -- say 30 minutes to an
hour -- after which the host should discard the connection even if
it doesn't get a reset from the other host.

     If a host comes back from a service interruption without a
reload, it should immediately probe all its connections to see what
connections are still valid and immediately nuke all the ones which
don't answer or reset.
-------

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 16:47:34 EDT
From:      Bob Walsh <walsh@BBN-LABS-B.ARPA>
To:        ucdla%ucbtopaz.CC@UCB-VAX.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  A Noop Strategy for TCP

TCP is designed to provide a reliable transport layer.  It is NOT designed
to ensure application <-> application reliability.  Robustness of application
communication is the responsibility of the application.  Mechanisms have
been tried to solve this problem.

For example, the Berkeley 4.2BSD TCP periodically
sends a byte just beyond the window in an attempt to force an ack when the
connection is otherwise idle.   But not every system is a 4.2BSD host, and
what happens when it communicates with a generous implementation that
recognizes the high per packet overhead (interrupt processing, header checking,
and network resources) and buffers the incoming packet?  A garbage byte
may make its way in to the stream.  And yet, the receiving TCP has made no
mistake.

Don't try to change the protocol, or you may run into problems.
Interoperability is one of the benefits of standards.  The RDP protocol
specifiers recognized this problem and addressed it through the use of
NULL messages to which all implementations must respond.  They also
recognized that the application layer must be responsible for end to end
reliability and forced the developer to keep this in mind through RDP's
abrupt closing method.

bob walsh
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 17:01:36 EDT
From:      Ron Natalie <ron@BRL.ARPA>
To:        Louis Mamakos <louie@UMD5.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  A Noop Strategy for TCP
Actually the stupid 4.2 BSD telnet sends a CR-NUL at the end of line
which really isn't what the spec had in mind either.

-Ron
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 18:12:46 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP

From: "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA>

My recommendation is that you send out an unsolicited acknowledgement
every 5 minutes or so when there is no activity of any kind on the
connection.  Activity is defined as any traffic, incoming or outgoing.
Thus, in practice only one end of the connection will be pinging the
other, since the receipt of such an unsolicited acknowledgement would
constitute activity.  If the host at the other end of the connection has
crashed, there will be no response to the ping at the TCP level, and
most TCP implementations don't understand ICMP destination unreachable
messages anyway.  However, when the host comes back up, the unsolicited
ack will elicit a reset, aborting the half-connection.

If your TCP implements ICMP destination unreachable messages, you
probably don't want to actually reset a connection because of one unless
the destination remains unreachable for some period of time, such as the
transmission timeout.  Given a little time, IP routing may find another
route or the gateway may come back up.  Multics uses transmission
timeouts of typically one minute.

Pinging is in disrepute these days because of network loading which it
causes.  On the good side, you are only pinging connections which are in
the established state, and if the clocks of the system are not perfectly
in step (well, "clocks" is an oversimplification) and the packet
dropping rate is low, only one system will be doing the pinging every
ping interval.  If different timeouts are used based on whether the
activity was transmission or reception, the systems can take turns doing
the pinging.  The ping interval can be quite long, perhaps several
minutes, since it is not constrained to be less than a transmission
timeout interval.  On the bad side, you are pinging for each connection,
not just for each host or even first hop gateway.

The rationale for leaving the pinging to the next higher level protocol
(telnet negotiations) is that then only telnet connections will present
this additional load on the network.  I think this is a crock of your
least favorite substance.  This means that ANY protocol or application
which is potentially idle for long periods must reinvent this wheel.  I
think that any application with humans in the loop will require this,
and that most other applications (e.g., SMTP, FTP data connections,
finger) do not have TCP connections sitting idle in both directions for
extended periods of time anyway.  A reliable stream protocol should be
more reliable than TCP is at telling its clients that the connection has
gone away.

Most real TCP implementations have ways of passing this information
around.  For example, if the client is blocked on read it has to handle
an abort, and a telnet user has to be able to receive urgent data to
implement Interrupt Process, even though these mechanisms are not
formally part of the TCP spec.

Multics does not do this pinging (yet?), and I know of no implementation
which does.  Would anyone care to offer additional reasons why
implementations should NOT do this, and why the TCP spec shouldn't be
amended?

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 19:38:37 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Some sites STILL using non-domain nicknames

From: Rich Wales <wales@UCLA-LOCUS.ARPA>

I originally posted the following to NAMEDROPPERS@SRI-NIC.ARPA -- but it
was suggested to me that many of the hosts in question might not have
any NAMEDROPPERS readers, and that I would be more likely to get to more
of the right people by posting to TCP-IP.

So -- with apologies to those of you who already saw this message on
NAMEDROPPERS, and/or those of you who have nothing to do with mail . . .

Quite a few sites are STILL sending out mail with old, non-domain-style
host names in the return addresses.  (E.g.:  "fred@PODUNK-CS" -- instead
of "fred@PODUNK-CS.ARPA", or maybe "fred@CS.PODUNK.EDU".)

Since these non-domain-style names are NEVER going to be included in
the new distributed domain data base, any host which has completed the
switch to the domain mechanism will no longer be able to reply to mail
whose return address bears one of these old names.

************************************************************************
*    QUICK CHECK:  If return addresses on your system don't have AT    *
*       LEAST ONE period after the at-sign, you have work to do.       *
************************************************************************

The following offenders were represented in the last week's worth of
mail received here at UCLA-LOCUS.ARPA:

  AERO2         CIT-VAX        ISI-VAXA      NRL-CSS       TOVE
  AIDS-UNIX     CVL            LBL-CSAM      NYU-CMCL2     UCI-ICSA
  ALMSA-2       GE-CRD         MARYLAND      RAND-UNIX     UCI-ICSD
  BERKELEY      GREGORIO       MIT-COMET     SRI-SPAM      UTAH-CS
  CIT-750       ISI-HOBGOBLIN  NCSC          SRI-UNIX

One or two of the above-listed sites account for a LOT of mail.

I suspect I will -- quite reluctantly -- end up hacking our outgoing
mailer daemon to add ".ARPA" to non-domain-style host names before
trying to look them up in the domain data base.

On principle, I shouldn't have to do this kind of thing . . .
and I don't really want to, because it's a Disgustingly Evil Hack . . .
and it won't even work all the time (e.g., GREGORIO.ARPA is bogus) . . .

. . . but as long as so many hosts continue to generate return addresses
that have no hope at all of working under the domain scheme, I see no
alternative if I am to continue to support a large (and frequently
naive) community of users who are totally unprepared to figure out what
to do if someone else's return address doesn't work.

One person suggested that I should modify my mail system to reject all
incoming mail with a non-domain-style host name in the return address.
While this might give the users of the offending hosts a little bit more
incentive to lean on their local mail gurus, it would also give the
disgruntled would-be recipients of such mail here at UCLA a little bit
more incentive to look for a silver platter to serve my head on!

I should mention, by the way, that I have been in touch with people at
Berkeley (one of the offending hosts listed above); they are aware of
the problem and are working on fixing their system.  Hopefully, then,
they will not show up on my "list" the next time I compile one.

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

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 20:33:53 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Interactive traffic punishment via MILNET?

From: mgardner@BBNCC5.ARPA

BBN is well aware of the problems and are working on them.

--Marianne

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 22:48:45 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  A Noop Strategy for TCP

From: Bob Walsh <walsh@BBN-LABS-B.ARPA>


TCP is designed to provide a reliable transport layer.  It is NOT designed
to ensure application <-> application reliability.  Robustness of application
communication is the responsibility of the application.  Mechanisms have
been tried to solve this problem.

For example, the Berkeley 4.2BSD TCP periodically
sends a byte just beyond the window in an attempt to force an ack when the
connection is otherwise idle.   But not every system is a 4.2BSD host, and
what happens when it communicates with a generous implementation that
recognizes the high per packet overhead (interrupt processing, header checking,
and network resources) and buffers the incoming packet?  A garbage byte
may make its way in to the stream.  And yet, the receiving TCP has made no
mistake.

Don't try to change the protocol, or you may run into problems.
Interoperability is one of the benefits of standards.  The RDP protocol
specifiers recognized this problem and addressed it through the use of
NULL messages to which all implementations must respond.  They also
recognized that the application layer must be responsible for end to end
reliability and forced the developer to keep this in mind through RDP's
abrupt closing method.

bob walsh

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jul 85 23:00:27 edt
From:      dual!mordor!seismo!rochester!ritcv!tropix!rcm@Berkeley (Robert C. Moore)
To:        dual!ucbvax!tcp-ip@Berkeley
Subject:   Re: Tektronix's TCP/IP for VMS?
	Please forward what you hear on to me at:

	ihnp4!tropix!rcm

	We have a VMS 750 and a microVMS microVAX II which need to
talk to a sun and several homegrown unix systems.  So far, the 
25k from Wolongong seems too steep for words.  So they run DECNET,
and we run TCP.  A solution would be encouraging.

					thanks!

					Bob Moore
					Tropel

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jul-85 23:52:17 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP

From: imagen!geof@su-shasta.ARPA


It seems that every now and then someone new brings up the topic of
keep-alives again.  I guess that I'll be the one (probably of many) to
answer this time.

TCP is a general purpose protocol, which is used over networks where
bandwidth is cheap and over networks where bandwidth is expensive. 
Since a major goal of the Internet protocol is to abstract the exact
nature of the network(s) in use, it is almost always impossible for a
host to know what networks a TCP connection is using (Indeed, the
connection may be using more than one set of networks).

The only way to verify that a TCP connection is working is to send a
packet over the connection.  On some networks, this costs money.  On
others it costs processing time in loaded gateways.  In short, it would
unacceptably expensive for TCP implementations that use SOME parts of
the Internet to probe the connection every so often just to verify that
the connection is still there.  Since an implementation has no way of
knowing what parts of the Internet it is using, this sort of probe was
left out of TCP-IP.

This means that probing the connection is left as a higher-level issue,
one that TCP explicitly does not deal with.  This is actually a good
idea for another reason.  Some protocols don't need to verify that an
idle connection is still around, because they always push data through
that connection.  Other implementations don't need to determine that
the connection has gone down until they are actually needed again.  For
example, a TAC never times out its TCP connection -- it relies on the
human user (which is always present) to decide for himself that the
connection is dead.

If you need to generate timeouts on your telnet programs, the place to
do it is within telnet itself.  Now you can understand why the telnet
specification suggests sending bogus option negotiations (the other
thing to do is to send AYT's, but some hosts do silly things with them,
like converting them into random control characters that are sent to an
application).

One more thing: at MIT we used to have problems with gateways crashing.
Sometimes (in the early days) a gateway would crash for ten or fifteen
minutes.  How elated were we that TCP does not send keep-alive probes,
since they would have determined (in their cleverness) that the
connection should have been reset, while we human users had higher level
information (Mr. Chiappa yelling down the hall) that the connection
would soon return to good health.

- Geof

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1985 01:05-EDT
From:      CERF@USC-ISI.ARPA
To:        Geoff@SRI-CSL.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interactive traffic punishment via MILNET?
Geoff,

I wonder if it is possible that the Tenex and TOPS-20 or
the TAC TCP reacts to source quenches which are likely when
sending many short packets by throttling back on packet output
rate??

Vint
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1985 01:21-EDT
From:      CERF@USC-ISI.ARPA
To:        JSLove@MIT-MULTICS.ARPA
Cc:        ucdla%ucbtopaz.CC@UCB-VAX.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: A Noop Strategy for TCP

The design of TCP explicitly did NOT introduce an are-you-there
automatic facility. We reasoned that the process above the TCP
level did not care what the condition of the other end was until
it had some data to send. If the process sent data (or a request
or query or a task initiation etc.) then it MIGHT care about
response. Certainly in that case, TCP tries to send repeatedly
and reports back when it cannot get an ACK within the specified
amount of time.  Once the data is accepted (ACKED), only the
process using TCP knows when it should get impatient about getting
an answer. TCP certainly doesn't know.  

If the using process does have a time out after which in really
wants an answer, that is the right time for it to query the
other side (e.g. send a query at the protocol layer above TCP)
and find out what its condition is.

It is fair to argue about reinventing the wheel for each protocol
above TCP, but it was our thought at the time that each process
or application would have different levels of patience regarding
when to get nervous about not hearing a response. So we left out
that feature in TCP, not wanting to impose something arbitrary on
the next level of protocol up.

Vint Cerf
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jul-85 01:46:41 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Interactive traffic punishment via MILNET?

From: CERF@USC-ISI.ARPA

Geoff,

I wonder if it is possible that the Tenex and TOPS-20 or
the TAC TCP reacts to source quenches which are likely when
sending many short packets by throttling back on packet output
rate??

Vint

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jul-85 02:40:25 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP

From: CERF@USC-ISI.ARPA


The design of TCP explicitly did NOT introduce an are-you-there
automatic facility. We reasoned that the process above the TCP
level did not care what the condition of the other end was until
it had some data to send. If the process sent data (or a request
or query or a task initiation etc.) then it MIGHT care about
response. Certainly in that case, TCP tries to send repeatedly
and reports back when it cannot get an ACK within the specified
amount of time.  Once the data is accepted (ACKED), only the
process using TCP knows when it should get impatient about getting
an answer. TCP certainly doesn't know.  

If the using process does have a time out after which in really
wants an answer, that is the right time for it to query the
other side (e.g. send a query at the protocol layer above TCP)
and find out what its condition is.

It is fair to argue about reinventing the wheel for each protocol
above TCP, but it was our thought at the time that each process
or application would have different levels of patience regarding
when to get nervous about not hearing a response. So we left out
that feature in TCP, not wanting to impose something arbitrary on
the next level of protocol up.

Vint Cerf

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jul-85 04:34:54 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: Tektronix's TCP/IP for VMS?

From: dual!mordor!seismo!rochester!ritcv!tropix!rcm@BERKELEY (Robert C. Moore)

	Please forward what you hear on to me at:

	ihnp4!tropix!rcm

	We have a VMS 750 and a microVMS microVAX II which need to
talk to a sun and several homegrown unix systems.  So far, the 
25k from Wolongong seems too steep for words.  So they run DECNET,
and we run TCP.  A solution would be encouraging.

					thanks!

					Bob Moore
					Tropel

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Friday, 26 Jul 1985 11:56-PDT
From:      imagen!geof@su-shasta.ARPA
To:        shasta!TCP-IP@SRI-NIC.ARPA
Subject:   Re: A Noop Strategy for TCP - second level comments.

TCP gives higher level protocols the responsibility of probing the
foreign system.  I believe that the higher level protocols divide up
into the following three categories (this is in contrast to one comment
recently made on the list):
	1. Applications where the TCP connection is never idle.  
	   No problem.
	2. Applications where the TCP connection is idle but monitored
	   by a human user.  Give the user a method to probe the connection
	   (like telnet remote echo, or null probes), and you've solved
	   the problem.  Ultimately, every user has his or her own internal
	   timer that says how long he/she is willing to wait. 
	   E.g., User FTP, User Telnet
	3. Applicationes where the TCP connection is idle and are not
	   monitored by a human user.  Then the higher level protocol
	   needs to send probes so that it doesn't hand forever.  
	   E.g.: SMTP, Server Telnet, Server FTP

There is one point of commonality between 2 & 3:

	If a TCP connection is idle, it must always be possible for either
	side to send the other a probe.

I have believed this point for some time.  It is interesting that the
rule is broken by the most obvious example of [3] -- SMTP.  Between the
time a User SMTP finishes sending a message (it sends the ".") and the
time the server sends the response, the user is unable to send any data
down the TCP connection, but must wait for the server.  The TCP
connection is idle, and TCP (as we all know by now) doesn't probe the
connection.  If the server crashes, the user is left hanging forever.

The usual solution is a timeout.  But there is wide variance in both
the time that a system can tolerate a hung SMTP server and the time
that it legitimately takes a slow server to process a message.  So
timeouts will always be causing certain messages/server combinations
to reliably fail.  Not quite what you wanted for a supposedly
autonomous service.  The real fix is an SMTP-level probe.

The same problem is exhibited by XNS Courier, which requires that all
XNS sequenced packet protocol implementations implement keep-alive
probes (probes are permitted but not required by the spec).  Beware if
you implement Courier on top of TCP!

- Geof
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 1985 12:36:18 PDT
From:      POSTEL@USC-ISIF.ARPA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Protocol Testing

The protocol testing contact at DDN is now Chuck Ely.


@whois ely

; Accessing NICNAME server at SRI-NIC...

Ely, Charles A. (CAE1)                              cely@DDN1
   Defense Communications Agency
   DDN Program Management Office
   Code B617
   Washington, D.C. 20305
   Phone: (703) 285-5337 (AV) 356-5337
   MILNET TAC user
@
-------
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jul-85 13:26:34 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  A Noop Strategy for TCP

From: Ron Natalie <ron@BRL.ARPA>

Actually the stupid 4.2 BSD telnet sends a CR-NUL at the end of line
which really isn't what the spec had in mind either.

-Ron

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jul-85 23:33:45 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP - second level comments.

From: imagen!geof@su-shasta.ARPA


TCP gives higher level protocols the responsibility of probing the
foreign system.  I believe that the higher level protocols divide up
into the following three categories (this is in contrast to one comment
recently made on the list):
	1. Applications where the TCP connection is never idle.  
	   No problem.
	2. Applications where the TCP connection is idle but monitored
	   by a human user.  Give the user a method to probe the connection
	   (like telnet remote echo, or null probes), and you've solved
	   the problem.  Ultimately, every user has his or her own internal
	   timer that says how long he/she is willing to wait. 
	   E.g., User FTP, User Telnet
	3. Applicationes where the TCP connection is idle and are not
	   monitored by a human user.  Then the higher level protocol
	   needs to send probes so that it doesn't hand forever.  
	   E.g.: SMTP, Server Telnet, Server FTP

There is one point of commonality between 2 & 3:

	If a TCP connection is idle, it must always be possible for either
	side to send the other a probe.

I have believed this point for some time.  It is interesting that the
rule is broken by the most obvious example of [3] -- SMTP.  Between the
time a User SMTP finishes sending a message (it sends the ".") and the
time the server sends the response, the user is unable to send any data
down the TCP connection, but must wait for the server.  The TCP
connection is idle, and TCP (as we all know by now) doesn't probe the
connection.  If the server crashes, the user is left hanging forever.

The usual solution is a timeout.  But there is wide variance in both
the time that a system can tolerate a hung SMTP server and the time
that it legitimately takes a slow server to process a message.  So
timeouts will always be causing certain messages/server combinations
to reliably fail.  Not quite what you wanted for a supposedly
autonomous service.  The real fix is an SMTP-level probe.

The same problem is exhibited by XNS Courier, which requires that all
XNS sequenced packet protocol implementations implement keep-alive
probes (probes are permitted but not required by the spec).  Beware if
you implement Courier on top of TCP!

- Geof

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jul-85 00:16:54 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Protocol Testing

From: POSTEL@USC-ISIF.ARPA


The protocol testing contact at DDN is now Chuck Ely.


@whois ely

; Accessing NICNAME server at SRI-NIC...

Ely, Charles A. (CAE1)                              cely@DDN1
   Defense Communications Agency
   DDN Program Management Office
   Code B617
   Washington, D.C. 20305
   Phone: (703) 285-5337 (AV) 356-5337
   MILNET TAC user
@
-------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jul 85 01:48 EDT
From:      don.provan@CMU-CS-A.ARPA
To:        tcp-ip@sri-nic.arpa
Subject:   probing in TCP
The time I need to probe a connection most is not one of the three
mentioned.  That's when there was a user, but there isn't any more.
For example, an inbound Telnet connection will sit around tieing up
resources forever if the remote host goes down while nothing's
happening on the connection.  I implemented it as a general solution,
since I can't imagine a connection where that can't happen.  After
all, the connection is a TCP resource.  There's no way for me to
determine whether the TCP connection or the network links in use for
it are more valuable.  In fact, I only implemented probing because
TCP keep running out of connection blocks.

For the curious, I probe with spontaneous ACKs.
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jul-85 02:58:52 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   probing in TCP

From: don.provan@CMU-CS-A.ARPA

The time I need to probe a connection most is not one of the three
mentioned.  That's when there was a user, but there isn't any more.
For example, an inbound Telnet connection will sit around tieing up
resources forever if the remote host goes down while nothing's
happening on the connection.  I implemented it as a general solution,
since I can't imagine a connection where that can't happen.  After
all, the connection is a TCP resource.  There's no way for me to
determine whether the TCP connection or the network links in use for
it are more valuable.  In fact, I only implemented probing because
TCP keep running out of connection blocks.

For the curious, I probe with spontaneous ACKs.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jul 85 14:40:08 cdt
From:      ihnp4!uab!monty@Berkeley (Montgomery Bob)
To:        scbhq!sb6!akgua!whuxlm!whuxl!houxm!mtuxo!drutx!ihnp4!cbosgd!ucbvax!tcp-ip@Berkeley
Subject:   Re: test
  We hear you down in Alabama! Do you think it's a workin' ??

                                                       Bob

                                           Bob Montgomery
                                           Univ. of Ala/B'ham C&IS

arpanet: monty%uab@csnet-relay.arpa
  csnet: monty@uab
   uucp: {sb1...sb6,akgua}!scbhq!uabcs!monty
  phone: (205) 934-2213
 usmail: 115a Campbell Hall, 1300 University Boulevard, Birmingham, Al 35294




-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 85 18:04:38 EDT
From:      Charles Hedrick <HEDRICK@RUTGERS.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   subnet addresses
We have heard a rumor that some people consider subnet zero to be
illegal.  Since our current hosts are 128.6.0.x, and we are about to
need to move to subnetting, this is an obvious concern to us.  We
haven't seen this in the proposed subnet RFC, but it has shown up in
one piece of code that claimed to implement subnetting.  As I read
it, there is special meaning attached to
   0.0.0.0  - I don't know who I am
   0.0.0.x  - i.e. all bits under the subnet mask (network number 
	plus subnet number) are zero - I don't know what net I am on
   x.y.z.0  - I know what net I'm on, but not who I am
But I do not see any constraints on the subnet number itself.  Am I
missing something?
-------
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jul-85 18:51:45 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   subnet addresses

From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>

We have heard a rumor that some people consider subnet zero to be
illegal.  Since our current hosts are 128.6.0.x, and we are about to
need to move to subnetting, this is an obvious concern to us.  We
haven't seen this in the proposed subnet RFC, but it has shown up in
one piece of code that claimed to implement subnetting.  As I read
it, there is special meaning attached to
   0.0.0.0  - I don't know who I am
   0.0.0.x  - i.e. all bits under the subnet mask (network number 
	plus subnet number) are zero - I don't know what net I am on
   x.y.z.0  - I know what net I'm on, but not who I am
But I do not see any constraints on the subnet number itself.  Am I
missing something?
-------

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Jul-85 03:39:07 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: test

From: ihnp4!uab!monty@BERKELEY (Montgomery Bob)

  We hear you down in Alabama! Do you think it's a workin' ??

                                                       Bob

                                           Bob Montgomery
                                           Univ. of Ala/B'ham C&IS

arpanet: monty%uab@csnet-relay.arpa
  csnet: monty@uab
   uucp: {sb1...sb6,akgua}!scbhq!uabcs!monty
  phone: (205) 934-2213
 usmail: 115a Campbell Hall, 1300 University Boulevard, Birmingham, Al 35294

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1985 1150-PDT (Monday)
From:      Jeff Mogul <mogul@Navajo>
To:        Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: subnet addresses
My gut feeling is to side with Noel (zero subnet numbers are
illegal), but on reflection I am compelled to agree with
Jon (zero subnet numbers must be supported to preserve
compatibility.)  However, I suggest that we "strongly
recommend" against assigning new zero-numbered subnets.
I say this uneasily, because I can think of all sorts of
minor reasons why reserving zero is a good idea.

Note that on the issue of all-ones subnets (all bits in
the subnet field set), I think the need for broadcasting
support (whether or not all organizations intend to use it)
outweighs any compatibility argument -- especially as there
currently seem to be few hosts that would fall afoul of
a prohibition against all-ones subnet numbers.

-Jeff
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      29-Jul-85 12:38:18-PDT
From:      jbn@FORD-WDL1.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        jbn@FORD-WDL1.ARPA
Subject:   Re: special addresses
      Someone needs to nail this down.  The meaning of ``broadcast
addressing'' in IP space is not well defined at present, and needs
to be.  
      Incidentally, it is probably a bad idea to have special addresses
that only can be decoded after you know how many bits of subnet information
apply.  This applies to [0.0.0.x], [0.0.x.x], and [0.x.x.x], which seem
to be of marginal utility.

				Nagle
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon 29 Jul 85 12:47:08-MDT
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        JNC@MIT-XX.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   subnet addresses
Duh, what does this mean for class B 1822 networks?  The byte that
is normally used for a subnet is the host number on the IMP, e.g.
128.43.0.2 is DREA-XX, host 0 on IMP 2 of DRENET.

We could perhaps change the addressing of DRENET to swap those bytes,
so that DREA-XX would become 128.43.2.0.  It would be more logical
that way.  On the other hand, that sort of thinking would argue that
ARPANET and Milnet should also have a flag day and migrate from the
current net.host.local_port.IMP to net.IMP.host.local_port.

Basically, what I am saying is that I expect that no ban be placed
on class B addresses with 0 in the third octet.  What is done in the
subnet system is one thing, but it must NOT be made a rule outside
of it.
-------
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon 29 Jul 85 12:05:01-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: subnet addresses
	This is being discussed by the group that did the subnet change
to the IP architecture. The general feeling in that group is that subnet
'0' should be non-legal (i.e. reserved for future use). This follows
the precedent in the IP architecture where all 1's and all 0's either
have special meaning or are preserved. This restriction will probably
be in the extended subnet specification document (to appear soon).

	Noel
-------
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 12:57:20 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	This is being discussed by the group that did the subnet change
to the IP architecture. The general feeling in that group is that subnet
'0' should be non-legal (i.e. reserved for future use). This follows
the precedent in the IP architecture where all 1's and all 0's either
have special meaning or are preserved. This restriction will probably
be in the extended subnet specification document (to appear soon).

	Noel
-------

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1985 16:46:00 PDT
From:      POSTEL@USC-ISIF.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   special addresses

See the bottom of page 3 of RFC 943.

--jon.
-------
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1985 1718-PDT (Monday)
From:      Jeff Mogul <mogul@Navajo>
To:        "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: subnet addresses
	    I think there are as many sites with subnet FF in use as there
    are with 0. I don't see that migrating hosts out of the potential subnet
    0 before turning subnetting on is a big deal.

I count 6 hosts in the NIC host table with (for address A.B.C.D) any
of A, B, C, or D = 255.  One is MITRE, the other 5 are all at LBL.
Of course, there may be hosts not listed with the NIC, and there
may be collisions on other addresses if somebody uses subnet
fields which are not 8 bits wide, but there are clearly far more
hosts with all 0s than all 1s where subnet fields might go.

I'd vote with you for changing the host addresses (it isn't THAT
big a deal) to allow banning of all 0s subnet numbers, but I suspect
we'd lose the vote.

-Jeff
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Monday, 29 Jul 1985 17:19-PDT
From:      geof@su-shasta.arpa
To:        shasta!tcp-ip@SRI-NIC.ARPA
Subject:   Re: A Noop Strategy for TCP - second level comments.

Actually, a telnet SERVER is an example of an unmonitored network
service.  Class #3 was the number in my listing, I believe.  I left it
out of my examples because the telnet protocol has higher-level probing
in the form of NOOP negotiations.  Few telnet server programs actually
exercise this option, though.  Interpret my last message as a harangue
at them and other server implementations of this class.

When I see idle network connections on the system, I exercise them (and
exorcise them) by sending a terminal message to the idle user which
says "are you still there".  The negative response is that the user's
TCP connection times out (or -- usually -- gets reset) and the spurious
login goes away.  I guess a quick fix for a harried system
administrator who doesn't want to hack code (or can't -- not everyone
has sources these days) is to use /etc/cron to run a program once every
hour or so that just sends a useless message to every network login.  I
guess that you could send a "^A" or something that would tend not to be
visible, except for messing up an Emacs screen occasionally.

- Geof
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1985 1734-PDT (Monday)
From:      Jeff Mogul <mogul@Navajo>
To:        jbn@FORD-WDL1.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: special addresses
      Someone needs to nail this down.  The meaning of ``broadcast
    addressing'' in IP space is not well defined at present, and needs
    to be.  

Right.  How about taking as a starting point either RFC919, "Broadcasting
Internet Datagrams", or RFC922, "Broadcasting Internet Datagrams in
the Presence of Subnets".  The latter might be slightly out-of-synch
with the RFC940 scheme for subnetting, but the intelligent reader
will not miss the point.

There has been a thundering silence on the topic ever since I wrote
these RFCs last year.  Neither memo requires the use of broadcast
(something that some people failed to understand), but merely
specifies a mechanism to be used if desired.  Remember, "RFC"
stands for "Request for Comments".

      Incidentally, it is probably a bad idea to have special addresses
    that only can be decoded after you know how many bits of subnet
    information apply.  This applies to [0.0.0.x], [0.0.x.x], and
    [0.x.x.x], which seem to be of marginal utility.

You're mostly right.  The idea (see RFC917) is that the use of subnets
should be invisible outside the network.  Therefore, any "special"
address that requires such decoding must be used only within a single
network.  The only such address for which I can see a use is "broadcast
to a specific non-local subnet of this network".

The use of [0.0.0.x] et al in the "Information Request" ICMP suffers
from this decoding problem, and several others, and is one reason
why a group of us proposed the "Reverse Address Resolution Protocol"
(RFC903), to obviate this ICMP.
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 16:10:19 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   subnet addresses

From: Mark Crispin <MRC@SIMTEL20.ARPA>

Duh, what does this mean for class B 1822 networks?  The byte that
is normally used for a subnet is the host number on the IMP, e.g.
128.43.0.2 is DREA-XX, host 0 on IMP 2 of DRENET.

We could perhaps change the addressing of DRENET to swap those bytes,
so that DREA-XX would become 128.43.2.0.  It would be more logical
that way.  On the other hand, that sort of thinking would argue that
ARPANET and Milnet should also have a flag day and migrate from the
current net.host.local_port.IMP to net.IMP.host.local_port.

Basically, what I am saying is that I expect that no ban be placed
on class B addresses with 0 in the third octet.  What is done in the
subnet system is one thing, but it must NOT be made a rule outside
of it.
-------

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 1985 16:47-EDT
From:      CERF@USC-ISI.ARPA
To:        MRC@SIMTEL20.ARPA
Cc:        JNC@MIT-XX.ARPA, TCP-IP@SRI-NIC.ARPA
Subject:   Re: subnet addresses
Mark,

I'm with you on that point - to the extent that some of the
address formats encapsulate what turn out to be physical
addresses, we certainly cannot arbitrarily rule out the value
0 when it is a component of a valid embedded physical address.

Of course, had all the IP addresses been "logical" and mapped in
some fashion (who on earth would maintain the table???) then this
might be less a problem.

Vint
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 17:15:30 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: Jeff Mogul <mogul@Navajo>

My gut feeling is to side with Noel (zero subnet numbers are
illegal), but on reflection I am compelled to agree with
Jon (zero subnet numbers must be supported to preserve
compatibility.)  However, I suggest that we "strongly
recommend" against assigning new zero-numbered subnets.
I say this uneasily, because I can think of all sorts of
minor reasons why reserving zero is a good idea.

Note that on the issue of all-ones subnets (all bits in
the subnet field set), I think the need for broadcasting
support (whether or not all organizations intend to use it)
outweighs any compatibility argument -- especially as there
currently seem to be few hosts that would fall afoul of
a prohibition against all-ones subnet numbers.

-Jeff

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 18:12:03 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: CERF@USC-ISI.ARPA

Mark,

I'm with you on that point - to the extent that some of the
address formats encapsulate what turn out to be physical
addresses, we certainly cannot arbitrarily rule out the value
0 when it is a component of a valid embedded physical address.

Of course, had all the IP addresses been "logical" and mapped in
some fashion (who on earth would maintain the table???) then this
might be less a problem.

Vint

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 19:10:46 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: special addresses

From: jbn@FORD-WDL1.ARPA

      Someone needs to nail this down.  The meaning of ``broadcast
addressing'' in IP space is not well defined at present, and needs
to be.  
      Incidentally, it is probably a bad idea to have special addresses
that only can be decoded after you know how many bits of subnet information
apply.  This applies to [0.0.0.x], [0.0.x.x], and [0.x.x.x], which seem
to be of marginal utility.

				Nagle

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Mon 29 Jul 85 20:03:33-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        MRC@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA
Cc:        JNC@MIT-XX.ARPA
Subject:   Re: subnet addresses
	I don't see how this conflicts with what I said: there is some
possibility that the use of *subnet* 0 will be disallowed.
-------
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Mon 29 Jul 85 20:05:02-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        mogul@SU-NAVAJO.ARPA, HEDRICK@RUTGERS.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: subnet addresses
	I think there are as many sites with subnet FF in use as there
are with 0. I don't see that migrating hosts out of the potential subnet
0 before turning subnetting on is a big deal.
-------
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Mon 29 Jul 85 22:14:59-MDT
From:      Mark Crispin <MRC@SIMTEL20.ARPA>
To:        JNC@MIT-XX.ARPA
Cc:        mogul@SU-NAVAJO.ARPA, HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: subnet addresses
Damn it, if the network doesn't have subnets it should have whatever it
damned well wants to in its octets!!!  I would like to see you have
ARPANET and MILNET have a flag day...after all, they can have 0 in the
second and third octets.  Or are they exempt?

I know that a number of sites are host 0 on an IMP deliberately just so
the users can say @O <n> without dots, colons, slashes, whathaveyou.
-------
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 21:08:41 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   special addresses

From: POSTEL@USC-ISIF.ARPA


See the bottom of page 3 of RFC 943.

--jon.
-------

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 22:01:06 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	I don't see how this conflicts with what I said: there is some
possibility that the use of *subnet* 0 will be disallowed.
-------

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 22:49:38 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	I think there are as many sites with subnet FF in use as there
are with 0. I don't see that migrating hosts out of the potential subnet
0 before turning subnetting on is a big deal.
-------

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jul 85 23:01:50 EDT
From:      Mike Muuss <mike@BRL.ARPA>
To:        tencati@jpl-vlsi.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  Problems with ACC's LHDH/ECU HOST/IMP interfaces?
We have about 8 ECU links here, and no trouble that can't be cleared
by the RESET switch, at worst.

We run anywhere from 9600 baud to 480,000 baud, with most links
at 50,000 64,000 and 100,000 baud, and one each at 9600 and 480,000.

All operate as Distant Hosts.  Most connect to an ACC LH/DH-11,
the remainder connect to BBNCC C/70 computers.

My only observation so far is that when the 9600 baud link becomes
marginal, things work worse that I would have expected.  There may
be some timeouts in the ECUs which need tuned for link speed.

Another factor which is important:  For our hosts operating at the
end of ECU links, especially ones which go marginal, we turn off
RFNM counting in the software.  Even though TCP can handle dropped
packets, the IMP/HOST protocol (ISO layer 2) can NOT stand dropped
RFNM packets, and if this is happening to your host, it will "gum up"
and give "out of buffer space" messages.  On 4.2 BSD systems,
a "netstat -h" with values of 8 in the RFNM column indicate that
you have this problem.  I can supply C code patches for this
if you need it.
	-Mike
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jul-85 23:39:02 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: Jeff Mogul <mogul@Navajo>

	    I think there are as many sites with subnet FF in use as there
    are with 0. I don't see that migrating hosts out of the potential subnet
    0 before turning subnetting on is a big deal.

I count 6 hosts in the NIC host table with (for address A.B.C.D) any
of A, B, C, or D = 255.  One is MITRE, the other 5 are all at LBL.
Of course, there may be hosts not listed with the NIC, and there
may be collisions on other addresses if somebody uses subnet
fields which are not 8 bits wide, but there are clearly far more
hosts with all 0s than all 1s where subnet fields might go.

I'd vote with you for changing the host addresses (it isn't THAT
big a deal) to allow banning of all 0s subnet numbers, but I suspect
we'd lose the vote.

-Jeff

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jul-85 00:29:37 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: special addresses

From: Jeff Mogul <mogul@Navajo>

      Someone needs to nail this down.  The meaning of ``broadcast
    addressing'' in IP space is not well defined at present, and needs
    to be.  

Right.  How about taking as a starting point either RFC919, "Broadcasting
Internet Datagrams", or RFC922, "Broadcasting Internet Datagrams in
the Presence of Subnets".  The latter might be slightly out-of-synch
with the RFC940 scheme for subnetting, but the intelligent reader
will not miss the point.

There has been a thundering silence on the topic ever since I wrote
these RFCs last year.  Neither memo requires the use of broadcast
(something that some people failed to understand), but merely
specifies a mechanism to be used if desired.  Remember, "RFC"
stands for "Request for Comments".

      Incidentally, it is probably a bad idea to have special addresses
    that only can be decoded after you know how many bits of subnet
    information apply.  This applies to [0.0.0.x], [0.0.x.x], and
    [0.x.x.x], which seem to be of marginal utility.

You're mostly right.  The idea (see RFC917) is that the use of subnets
should be invisible outside the network.  Therefore, any "special"
address that requires such decoding must be used only within a single
network.  The only such address for which I can see a use is "broadcast
to a specific non-local subnet of this network".

The use of [0.0.0.x] et al in the "Information Request" ICMP suffers
from this decoding problem, and several others, and is one reason
why a group of us proposed the "Reverse Address Resolution Protocol"
(RFC903), to obviate this ICMP.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jul-85 01:16:58 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP - second level comments.

From: geof@su-shasta.arpa


Actually, a telnet SERVER is an example of an unmonitored network
service.  Class #3 was the number in my listing, I believe.  I left it
out of my examples because the telnet protocol has higher-level probing
in the form of NOOP negotiations.  Few telnet server programs actually
exercise this option, though.  Interpret my last message as a harangue
at them and other server implementations of this class.

When I see idle network connections on the system, I exercise them (and
exorcise them) by sending a terminal message to the idle user which
says "are you still there".  The negative response is that the user's
TCP connection times out (or -- usually -- gets reset) and the spurious
login goes away.  I guess a quick fix for a harried system
administrator who doesn't want to hack code (or can't -- not everyone
has sources these days) is to use /etc/cron to run a program once every
hour or so that just sends a useless message to every network login.  I
guess that you could send a "^A" or something that would tend not to be
visible, except for messing up an Emacs screen occasionally.

- Geof

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue 30 Jul 85 09:12:57-EDT
From:      "J. Noel Chiappa" <JNC@MIT-XX.ARPA>
To:        MRC@SIMTEL20.ARPA
Cc:        mogul@SU-NAVAJO.ARPA, HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA
Subject:   Re: subnet addresses
	Mark, I don't understand what you think you are disputing.
It is perfectly legal for any network *without subnets* to have 0's in
any part of the 'rest' field. Nobody ever said otherwise. I was only
discussing the case where subnets *were* in use.

	Noel
-------
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue 30 Jul 85 10:57:15-EDT
From:      Lixia Zhang <Lixia@MIT-XX.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Withholding Acks
Could  someone tell me if there is/are TCP imlementations that withhold
acknowledgment packets?
And if so, are they the majority?  and how do they do it?

(I've read rfc813 by Dave Clark on that topic, but I'd like to know
whether/how it is implemented.)

Many thanks.

Lixia

-------
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jul-85 11:35:44 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	Mark, I don't understand what you think you are disputing.
It is perfectly legal for any network *without subnets* to have 0's in
any part of the 'rest' field. Nobody ever said otherwise. I was only
discussing the case where subnets *were* in use.

	Noel
-------

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jul-85 20:03:53 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Withholding Acks

From: Lixia Zhang <Lixia@MIT-XX.ARPA>

Could  someone tell me if there is/are TCP imlementations that withhold
acknowledgment packets?
And if so, are they the majority?  and how do they do it?

(I've read rfc813 by Dave Clark on that topic, but I'd like to know
whether/how it is implemented.)

Many thanks.

Lixia

-------

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jul-85 21:30:29 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: subnet addresses

From: Mark Crispin <MRC@SIMTEL20.ARPA>

Damn it, if the network doesn't have subnets it should have whatever it
damned well wants to in its octets!!!  I would like to see you have
ARPANET and MILNET have a flag day...after all, they can have 0 in the
second and third octets.  Or are they exempt?

I know that a number of sites are host 0 on an IMP deliberately just so
the users can say @O <n> without dots, colons, slashes, whathaveyou.
-------

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31-Jul-85 05:29:18 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re:  Problems with ACC's LHDH/ECU HOST/IMP interfaces?

From: Mike Muuss <mike@BRL.ARPA>

We have about 8 ECU links here, and no trouble that can't be cleared
by the RESET switch, at worst.

We run anywhere from 9600 baud to 480,000 baud, with most links
at 50,000 64,000 and 100,000 baud, and one each at 9600 and 480,000.

All operate as Distant Hosts.  Most connect to an ACC LH/DH-11,
the remainder connect to BBNCC C/70 computers.

My only observation so far is that when the 9600 baud link becomes
marginal, things work worse that I would have expected.  There may
be some timeouts in the ECUs which need tuned for link speed.

Another factor which is important:  For our hosts operating at the
end of ECU links, especially ones which go marginal, we turn off
RFNM counting in the software.  Even though TCP can handle dropped
packets, the IMP/HOST protocol (ISO layer 2) can NOT stand dropped
RFNM packets, and if this is happening to your host, it will "gum up"
and give "out of buffer space" messages.  On 4.2 BSD systems,
a "netstat -h" with values of 8 in the RFNM column indicate that
you have this problem.  I can supply C code patches for this
if you need it.
	-Mike

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jul 85 07:07:22 cdt
From:      herb@wisc-rsch.arpa (Benington Herb)
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Remove

Please remove my box from the mailing list.  Thank you for all
the interesting and first-class services.

		Herb Benington
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31-Jul-85 09:04:39 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Remove

From: herb@wisc-rsch.arpa (Benington Herb)


Please remove my box from the mailing list.  Thank you for all
the interesting and first-class services.

		Herb Benington

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jul 85 12:52 EDT
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        Lixia Zhang <Lixia@MIT-XX.ARPA>, tcp-ip@SRI-NIC.ARPA
Subject:   Withholding Acks
    Date: Tue 30 Jul 85 10:57:15-EDT
    From: Lixia Zhang <Lixia@MIT-XX.ARPA>

    Could  someone tell me if there is/are TCP imlementations that withhold
    acknowledgment packets?
    And if so, are they the majority?  and how do they do it?

    (I've read rfc813 by Dave Clark on that topic, but I'd like to know
    whether/how it is implemented.)

The Symbolics implementation for 3600s sets a flag in a connection
saying "send an ack when you get a chance."  Therefore, we do withhold
ACKs in a sense.  

If by withholding acks you are thinking about avoiding silly-window
syndrome, that is NOT withholding acks, that is withholding window
enlargments.  Our implementation does that too.  I think just about
every implementation does these days.  It isn't hard.  (It's a bit
easier if you deal with limit sequence numbers instead of base+count,
since limits stay constant while base increases and count decreases, and
just makes my brain hurt making sure they increase/decrease by the same
amount...)

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jul 85 12:54 EDT
From:      David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
To:        Mark Crispin <MRC@SIMTEL20.ARPA>, J. Spencer Love <JSLove@MIT-MULTICS.ARPA>, Louis Mamakos <louie@UMD5.ARPA>, Bob Walsh <walsh@BBN-LABS-B.ARPA>, CERF@USC-ISI.ARPA, don.provan@CMU-CS-A.ARPA, ucdla%ucbtopaz.CC@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: A Noop Strategy for TCP
Folks, we've been through this before, and there is the following large
comment in the TCP implementation I wrote for Symbolics:

	  ;; Very important note:  This does NOT, and is not intended to,
	  ;; ensure the other side of the connection is alive.  We are
	  ;; not asking for any positive confirmation that this ack was
	  ;; received.  What this IS for is to generate a RESET from the
	  ;; foreign host if the connection is known to be dead.  This
	  ;; issue was discussed on the TCP-IP@SRI-NIC mailing list from
	  ;; 22 Nov 83 and lasting for a few days.
	  ;; This mechanism is also used for the "zero window probe".
	  (send-ack-for-tcb tcb (get-tcp-segment tcb t) :idle-probe))

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31-Jul-85 15:27:05 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Re: A Noop Strategy for TCP

From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

Folks, we've been through this before, and there is the following large
comment in the TCP implementation I wrote for Symbolics:

	  ;; Very important note:  This does NOT, and is not intended to,
	  ;; ensure the other side of the connection is alive.  We are
	  ;; not asking for any positive confirmation that this ack was
	  ;; received.  What this IS for is to generate a RESET from the
	  ;; foreign host if the connection is known to be dead.  This
	  ;; issue was discussed on the TCP-IP@SRI-NIC mailing list from
	  ;; 22 Nov 83 and lasting for a few days.
	  ;; This mechanism is also used for the "zero window probe".
	  (send-ack-for-tcb tcb (get-tcp-segment tcb t) :idle-probe))

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jul 85 20:20:44 CDT
From:      mknox@ut-ngp.ARPA (mknox)
To:        tcp-ip@sri-nic.ARPA
Subject:   X.25 implementation needed

There is a project underway to implement a number of protocols on a high-
performance 68000-based network box.  In the interim what is needed is
a version of X.25 (and HDLC LAPB, for that matter) which can be used
until the final version is ready.

Can anyone point me towards a reasonable PORTABLE version, either in C
or 68000 assembly code?  Public domain is obviously desirable (mostly
from the standpoint of getting it quickly), but pointers to commercial
versions would also be appreciated.

				tnx
					MKNOX@UT-NGP.ARPA

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jul 85 20:44:34 EDT
From:      louie@trantor.arpa (Louis A. Mamakos)
To:        tcp-ip@sri-nic.ARPA
Subject:   Beta release announcement for Sperry 1100 TCP/IP software
A beta-test release of the IP/TCP-1100 package is now available from
the University of Maryland.  IP/TCP-1100 is DoD standard IP and TCP
networking software for the Sperry 1100 series mainframes.  It includes
the standard servers for TELNET, FTP and SMTP.  Client programs for
TELNET and an SMTP mailer are also included.  The client FTP program is
not yet ready for release.  In addition, client and user MDQS programs
are included to communicate with their peers on UNIX hosts.  MDQS is
a network based queuing system developed at BRL.  An electronic mail
system for the Sperry is also supplied as part of the package.

The package will run on 1100/80, 1100/80A, 1100/60 with EIS, 1100/70 with
EIS and 1100/90 systems.  It will not run on 1110, 1108, 1100/10, 1100/20
or 1100/40 systems.  OS1100 version 38R5 or later is required.

The only network interfaces currently in use are a simple bytestuffing
sync driver for a GCS CTS STD or CTMC CTM 6.  This is used to talk to
one of Dave Mills' fuzzball systems.  The other uses the Front End Handler
feature of the EXEC to connect a Word channel to a UNIBUS word channel
interface.  The board is custom hardware developed at NOSC.  Drivers for
4.2 and 4.3 BSD are available.  A driver for the DCP is not provided.

The software *is* a beta release;  the documentation is not complete, and
some network and Sperry 1100 wizardary will be required.  The software is
available on an as-is basis, with no support provided or implied.  So much
for the disclamers.  For details in obtaining the package, send mail to

       <louie@trantor.arpa>  or
       <louie@umd5.arpa>

The price is free;  you send me a tape, and I send it back to you with
the software and documentation (such as it is).  If you find bugs, I'd
be glad to hear about them (even more glad if a fix is included), but I
cannot make any promises about fixing the bugs in a timely fashon.

Louis A. Mamakos
Computer Science Center
University of Maryland
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31-Jul-85 22:36:56 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   X.25 implementation needed

From: mknox@ut-ngp.ARPA (mknox)


There is a project underway to implement a number of protocols on a high-
performance 68000-based network box.  In the interim what is needed is
a version of X.25 (and HDLC LAPB, for that matter) which can be used
until the final version is ready.

Can anyone point me towards a reasonable PORTABLE version, either in C
or 68000 assembly code?  Public domain is obviously desirable (mostly
from the standpoint of getting it quickly), but pointers to commercial
versions would also be appreciated.

				tnx
					MKNOX@UT-NGP.ARPA

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1-Aug-85 01:24:51 EDT
From:      tcp-ip@ucbvax.ARPA
To:        fa.tcp-ip
Subject:   Withholding Acks

From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    Date: Tue 30 Jul 85 10:57:15-EDT
    From: Lixia Zhang <Lixia@MIT-XX.ARPA>

    Could  someone tell me if there is/are TCP imlementations that withhold
    acknowledgment packets?
    And if so, are they the majority?  and how do they do it?

    (I've read rfc813 by Dave Clark on that topic, but I'd like to know
    whether/how it is implemented.)

The Symbolics implementation for 3600s sets a flag in a connection
saying "send an ack when you get a chance."  Therefore, we do withhold
ACKs in a sense.  

If by withholding acks you are thinking about avoiding silly-window
syndrome, that is NOT withholding acks, that is withholding window
enlargments.  Our implementation does that too.  I think just about
every implementation does these days.  It isn't hard.  (It's a bit
easier if you deal with limit sequence numbers instead of base+count,
since limits stay constant while base increases and count decreases, and
just makes my brain hurt making sure they increase/decrease by the same
amount...)

END OF DOCUMENT