The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 09:39:52 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Peak User Estimate


    Based on some envelope calculations, described below, I estimate
that the peak number of simultaneous users is 10% of the potential
users.  Is this estimate in accord with your experience?

    The system I use here at MITRE is a VAX 8600 running Ultrix.  I have
recently had occasion to be interested in the peak number of
simultaneous users as a percentage of the number of possible users.  
So, on 24 March, I copied the /usr/users file and found 551 entries,
some of which had not logged-in since 1985!  Recognizing that some user
accounts simply forward mail to another system, I deleted every entry
whose last login was 28 February, or earlier.  That left 191 users that
had logged-in at least once during the period 1-24 March.

    Over the past several months I have, at unplanned intervals, run the
Unix "who" command that lists all logged-in users.  The usual response
is 10 to 15 users; very rarely does the number equal or exceed 20.  The
estimate made above follows from this data.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 10:15:00 EST
From:      GBELING@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   IP over x.25

hello collegues, 
we are running here a connection to the arpanet using the PTT's datex-p 
(i.e. x.25) as a transatlantic transport medium. To do so we have 
connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams 
into x.25-packets. 
Up to some time ago this worked fairly well and reliable and fast (up to 
2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway 
in boston. 
Since heavy congestion occurs in the arpa/milnet we have a special poroblem:
If for some reason the x.25 virtual connection is idle for 2 minutes 
the van-gateway closes the connection and cannot reopen it: we have to 
do this because we have to pay the x.25 charges. 
In the case that we are reading data from the other side and have acked 
all segments properly the connection is broken and our TCP has to wait 
until the user timeout cancels the (tcp) connection on our side - what 
the far-end tcp does we do not know. This happens sometimes when the far 
tcp does not do retransmissions or so slowly that in the intermediate time 
x.25 cuts us off.
Ip is developed for the case that the underlying connection is a permannt 
available one i.e. no open or close needed !
If we look to the protocol suite properly there is no way to signal the 
broken x.25 connection to the user of telnet so that he can react. therefore 
we think of to reopen the x.25 VC automatically when the other side closes it. 
this has the disadvantage that we reopen it also when the tcp-connection 
has finished because x.25 does not know something about tcp-connections. 
The peculiar problem is that we have to pay for each OPEN of a VC (and 
afterwards for the time it is open: 5pfg for each open, 15pfg per minute).
The problem will become even more complicated when several tcp-connections 
are multiplexed onto one x.25-virtual circuit or there are several x.25 
VCs open at the same time. 
How did others solve the problem to reopen broken x.25VCs when a tcp-connection
to close the connection?
thanks gerd beling
  

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 10:15-EST
From:      GBELING@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   IP over x.25
hello collegues, 
we are running here a connection to the arpanet using the PTT's datex-p 
(i.e. x.25) as a transatlantic transport medium. To do so we have 
connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams 
into x.25-packets. 
Up to some time ago this worked fairly well and reliable and fast (up to 
2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway 
in boston. 
Since heavy congestion occurs in the arpa/milnet we have a special poroblem:
If for some reason the x.25 virtual connection is idle for 2 minutes 
the van-gateway closes the connection and cannot reopen it: we have to 
do this because we have to pay the x.25 charges. 
In the case that we are reading data from the other side and have acked 
all segments properly the connection is broken and our TCP has to wait 
until the user timeout cancels the (tcp) connection on our side - what 
the far-end tcp does we do not know. This happens sometimes when the far 
tcp does not do retransmissions or so slowly that in the intermediate time 
x.25 cuts us off.
Ip is developed for the case that the underlying connection is a permannt 
available one i.e. no open or close needed !
If we look to the protocol suite properly there is no way to signal the 
broken x.25 connection to the user of telnet so that he can react. therefore 
we think of to reopen the x.25 VC automatically when the other side closes it. 
this has the disadvantage that we reopen it also when the tcp-connection 
has finished because x.25 does not know something about tcp-connections. 
The peculiar problem is that we have to pay for each OPEN of a VC (and 
afterwards for the time it is open: 5pfg for each open, 15pfg per minute).
The problem will become even more complicated when several tcp-connections 
are multiplexed onto one x.25-virtual circuit or there are several x.25 
VCs open at the same time. 
How did others solve the problem to reopen broken x.25VCs when a tcp-connection
to close the connection?
thanks gerd beling
  
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 10:48:46 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: interesting new product I ran across

John,  Sounds like it has almost allof the features one could use!
But, as Billy Brackenridge would say:"
PRICE IS TECHNICAL INFORMATION.

So, let me know by the drop deadline and I'll order up a bunch.

Dan

PS.  I really hope you don't run out of those EBCDIC decoder rings...
-------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 10:48:46 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        John Romkey <ROMKEY@XX.LCS.MIT.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, pcip@LOUIE.UDEL.EDU, LYNCH@A.ISI.EDU
Subject:   Re: interesting new product I ran across
John,  Sounds like it has almost allof the features one could use!
But, as Billy Brackenridge would say:"
PRICE IS TECHNICAL INFORMATION.

So, let me know by the drop deadline and I'll order up a bunch.

Dan

PS.  I really hope you don't run out of those EBCDIC decoder rings...
-------
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Apr 87 09:25:57 +0000
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        Chris Perry <cperry@gateway.mitre.org>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: talking of and to gateways and bridges

Chris,

ROS stands for Remote OperationS, and REX stands for Remote
EXexcution. They are part of the ECMA (European Computer
Manufacturers Association) input to draft standards work on
distributed computing. REX is a Birrel & Nelson type
'minimum packet' transaction transport protocol, whilst ROS uses
ASN (Abstract Sysntax Notation) as a presentation layer to
to define call/reply/error messages and parameters and
to provide machine independance of call and reply parameter
representation. The ANSA (Advanced Network Systems
Architecture) research group have put a lot of work into their
design. The goal is to provide a system where code for client/server
model interactions may be generated automatically (RPC type
work), but to allow for other types of interaction too.

jon
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 17:40:49 EST
From:      rbbb@rice.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Mail "direct to machines"

narten@purdue.edu says:
> mailbox.  Presumably, as domain names get extended, we will be able to
> do that.  Any mail you send to a user can go directly to the machine
> where the his/her mailbox resides. No forwarding at the site would be
> needed.

I may misunderstand you, but how can you tell where my mailbox resides?
If you look at my "Message-Id", you might guess that you could send to
"rbbb@proserpina.rice.edu", and you would be wrong.

I read my mail at "titan.rice.edu", but you should just send it to
"rice.edu", and let it be forwarded to whereever I happen to currently
live.  It is difficult to propagate precise information about my
whereabouts to ALL the machines on our net, and much more difficult when
you consider that I am certainly not the only user here.  It is much much
simpler to have every machine except the one where my mailbox resides boot
my mail to "rice.edu", and let "rice.edu" forward it to my home.
Obviously, we take great pains to keep rice.edu up and running, but it is
no more vital than our gateway, our line to the IMP in Austin, or the IMP
itself.

I don't see how extended domain names will help this.

David

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 18:02:35 EST
From:      Crispin@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   totally cretinous domain lossage


     A major Internet mailing list failed today because the domain system is
broken for hosts in Norway.  Specifically, the hosts that were named
OSLO-VAX.ARPA and NTA-VAX.ARPA have IN-ADDR records on their host addresses
that return the names ifi.UIO.NO and tor.NTA.NO respectively.  However, the
domain system does not recognize either of the mumble.NO names!

     I sure to hell wish that organizations would coordinate their IN-ADDR
entries with their name entries.  Please don't tell me not to use IN-ADDR
entries -- I know it's a kludge and as soon as the developers of the TOPS-20
domain software give me a "translate name to fully-qualified domain name"
function I'll use it.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 01 Apr 87 10:31:41 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Remote access in Bitnet
(Caveat - This description is primarily for people who have no idea how
 Bitnet works.)

Greg,

The concept of remote access doesn't exist in Bitnet.  The protocols in
Bitnet are as follows:

1) One-way File Transfer - any user is allowed to send a file to any other
   user.  Since the file ends up in the destination users spool system
   (or some emulation thereof) there is no problem with access control.

2) Interactive Message - any user can send a one line message (max 160
   characters) to any other user.  All you need to know is the destination
   user and node.  If the user is not logged on or a link is down you are
   told so.

Based on these two primitives - Bitnet has built various other
pseudo-protocols.  From #1 above - we are able to do mail, list explosion,
computer conferencing, general file transfer.  From #2 above, Bitnet has
developed a CB (Chat) system.

By combined both of the basic primitives above, a file server can be set
up at any node that will trap incoming 'Interactive Messages' - which
contain a command and process the command and send the results back to the
user via the 'One-Way File Transfer' mechanism.  This method allows users
to sit at their machine and issue commands like DIR or LIST to some remote
file server and then issue some SEND commands to retrieve the files they
want.  There is no need in that case to do any sort of remote connect
(anonymous FTP).

Most servers (200+) in Bitnet also accept transactions via files or RFC822
mail.  Lately, various servers in Arpanet have decided that is also a 'clever'
thing to have, so we have things like archive-request@simtel20.arpa and
service@sri-nic.arpa popping up (I expect more before the end of th year).

So to answer your question:

> a remote file they own

They cannot access it.  Yup would be nice and that is just one reason why
Bitnet should convert to Tcp/Ip.  Incidentally, there is a program I
distribute in Bitnet that allows this remote access to a file the person
owns but it is a private convention.  The program runs as a task (and
therefore must be running when the remote user wants access to his/her files).
and the user needs to set up a remote access password.  It uses the
Interactive Message Primitive to send and receive data, and each command
you want executed on the remote host must be prefixed with your remote pswd.
Not as elegent as TELNET but when the entire concept of TELNET doesn't exist
it is the best one can do.

> a remote file they don't own, but is not protected

Only if the file is available via a remote file server can they access it.

> a remote file they don't own, but is protected

They can't access it.

Hope this helps.

Hank
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 20:31:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Stu,

one little observation. A single collision in your tapemobile would do
rather more damage than the typical collision on an ethernet.

Shows why putting all your bits in one packet isn't a good policy...

Vint

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 20:31-EST
From:      CERF@A.ISI.EDU
To:        GROSSMAN@SIERRA.STANFORD.EDU
Cc:        imagen!apolling!geof@DECWRL.DEC.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Station wagon full of bits
Stu,

one little observation. A single collision in your tapemobile would do
rather more damage than the typical collision on an ethernet.

Shows why putting all your bits in one packet isn't a good policy...

Vint
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 21:16:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

Bob,

just came across your message about the station wagon full of bits -
amazing! You and I had nearly the identical reaction as you'll see
when you read TCP-IP and catch my message [sometimes I think I should
read my mail backwards...].

Vint

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 21:16-EST
From:      CERF@A.ISI.EDU
To:        hinden@CCV.BBN.COM
Cc:        GROSSMAN@SIERRA.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Station wagon full of bits
Bob,

just came across your message about the station wagon full of bits -
amazing! You and I had nearly the identical reaction as you'll see
when you read TCP-IP and catch my message [sometimes I think I should
read my mail backwards...].

Vint
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 21:28:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Station wagon full of bits

One of the important features of X.25 and other packet-oriented services
(and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many
simultaneous virtual connections. The ISDN facilities will not replace
that functionality if level 3 is erased and only level 2 remains and
only supports a single connection at a time. ISDN does provide for a
packet mode interface which is basically a level 3 construct.

I do not see that the pt-pt 64 kb/s service from ISDN will render the
multi-connection modes of operation useless.

Vint

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 21:28-EST
From:      CERF@A.ISI.EDU
To:        mckee@MITRE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, m15368%mwvm@MITRE.ARPA
Subject:   Re: Station wagon full of bits
One of the important features of X.25 and other packet-oriented services
(and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many
simultaneous virtual connections. The ISDN facilities will not replace
that functionality if level 3 is erased and only level 2 remains and
only supports a single connection at a time. ISDN does provide for a
packet mode interface which is basically a level 3 construct.

I do not see that the pt-pt 64 kb/s service from ISDN will render the
multi-connection modes of operation useless.

Vint
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 21:32:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ICMP message caching

Steve,

there will be some howls, but I think the idea of ICMP caching to
be worth exploring. We are surely in agreement that the more knowledge 
you can obtain about the Internet condition, the better you can, at
the source, make decisions about traffic routing, retransmission,
attempts to set-up connections, etc.

I am sure this subject has come up before - some folks were uncomfortable
because it seemed to smack of protocol boundary crossing - Dave mIlls
mentioned a similar idea relative to caching such information th the
gateways, too.

Let's see what comments your notion uncovers!

Vint

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 21:32-EST
From:      CERF@A.ISI.EDU
To:        steve@BRILLIG.UMD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ICMP message caching
Steve,

there will be some howls, but I think the idea of ICMP caching to
be worth exploring. We are surely in agreement that the more knowledge 
you can obtain about the Internet condition, the better you can, at
the source, make decisions about traffic routing, retransmission,
attempts to set-up connections, etc.

I am sure this subject has come up before - some folks were uncomfortable
because it seemed to smack of protocol boundary crossing - Dave mIlls
mentioned a similar idea relative to caching such information th the
gateways, too.

Let's see what comments your notion uncovers!

Vint
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 21:36:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:      Tcp/Ip vs a store & forward network

Hank,

we didn't do it because I think we didn't think it was necessary
but that's because we started with just one network and tried to
extend the earlier services to the Internet. The mail forwarders
are really store/forward when you think about it. Also, you need
all the mechanisms for error reporting that the mail system has in
it to recover from failures.

Vint

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 21:36-EST
From:      CERF@A.ISI.EDU
To:        HANK%BARILVM.BITNET@WISCVM.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:      Tcp/Ip vs a store & forward network
Hank,

we didn't do it because I think we didn't think it was necessary
but that's because we started with just one network and tried to
extend the earlier services to the Internet. The mail forwarders
are really store/forward when you think about it. Also, you need
all the mechanisms for error reporting that the mail system has in
it to recover from failures.

Vint
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 21:44:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Steve (Kille),

I merely wanted to point out that you need something above the X.25
level to do recovery, if you care, after a reset.

Vint

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 21:44-EST
From:      CERF@A.ISI.EDU
To:        Steve.Kille@CS.UCL.AC.UK
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: GOSIP vs TCP/IP
Steve (Kille),

I merely wanted to point out that you need something above the X.25
level to do recovery, if you care, after a reset.

Vint
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Apr-87 21:58:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Peak User Estimate


10% represents a high usage rate. MCI Mail had 16000 users/VAX but only
a small % (0.5-1%) were ever trying to get on at once.

Vint

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1987 21:58-EST
From:      CERF@A.ISI.EDU
To:        mckee@MITRE.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Peak User Estimate

10% represents a high usage rate. MCI Mail had 16000 users/VAX but only
a small % (0.5-1%) were ever trying to get on at once.

Vint
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 01:21:33 EST
From:      chris@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   New source for Imagen laser printer memory boards.



	I, recently had the oppertunity to evaluate a memory board for
the Imagen IP/II processors.  Since this is the first I had heard of an
alternative source for Imagen memory I thought I'd share the info with 
the net.  The company's name is Kortex Systems and incase you want to
contact them their phone numbers are (415)-961-4411 or (415)-969-4053.
They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board
in our 8/300 and our 3320 Imagen printers, both printers sit on our 
local ether net.  In the past large jobs (100+ pages) would come out 
in reverse order and you would have to collilate the pages manually, 
with the 4 meg board in the system I couldn't find a listing large enough 
to use up all of the memory.  We used the board in both systems for a
week and saw no problems with it. The 4 Meg board retails for $1795 with 
discouts for non-profit and educational groups.  The last time I checked
the largest board Imagen sold was a 3 Meg one and it was going for $1900.

						Chris

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 07:29:28 EST
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Packet network reliability

> BBN gets around these two disadvantages at a cost.  The Milnet for instance
> is gettingvery large, very fast.   I don't know the formula for computing the
> amount of bandwidth required for the internal routing updates, but I would 
> suspect it would go up exponentially with the number of nodes(and connectivity
> of them).  If anybody knows the numbers I'd like to have them.

BBN C-30 based networks use an efficient flooding scheme to send routing
updates.  Each update crosses each link twice, the second time as a
robust acknowledgement.  Link overhead is therefore linear with the
number of nodes.

Better still, the algorithm they use to compute routes when a change
is received performs on the order of the average hop length of all
paths, estimated at log N/log(c-1) where N is number of nodes and
c is connectiviey.

See paper by John McQuillan, Ira Richer, and Eric Rosen, "The New
Routing Algorithm for the ARPANET," IEEE Transactions on Communications,
Vol. COM-28, No. 5, May 1980.


	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 07:57:04 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Bitnet protocols

I sent this yesterday and I never saw it come back so I have a feeling it
got lost on its way:

(Caveat - This description is primarily for people who have no idea how
 Bitnet works.)

Greg,

The concept of remote access doesn't exist in Bitnet.  The protocols in
Bitnet are as follows:

1) One-way File Transfer - any user is allowed to send a file to any other
   user.  Since the file ends up in the destination users spool system
   (or some emulation thereof) there is no problem with access control.

2) Interactive Message - any user can send a one line message (max 160
   characters) to any other user.  All you need to know is the destination
   user and node.  If the user is not logged on or a link is down you are
   told so.

Based on these two primitives - Bitnet has built various other
pseudo-protocols.  From #1 above - we are able to do mail, list explosion,
computer conferencing, general file transfer.  From #2 above, Bitnet has
developed a CB (Chat) system.

By combined both of the basic primitives above, a file server can be set
up at any node that will trap incoming 'Interactive Messages' - which
contain a command and process the command and send the results back to the
user via the 'One-Way File Transfer' mechanism.  This method allows users
to sit at their machine and issue commands like DIR or LIST to some remote
file server and then issue some SEND commands to retrieve the files they
want.  There is no need in that case to do any sort of remote connect
(anonymous FTP).

Most servers (200+) in Bitnet also accept transactions via files or RFC822
mail.  Lately, various servers in Arpanet have decided that is also a 'clever'
thing to have, so we have things like archive-request@simtel20.arpa and
service@sri-nic.arpa popping up (I expect more before the end of th year).

So to answer your question:

> a remote file they own

They cannot access it.  Yup would be nice and that is just one reason why
Bitnet should convert to Tcp/Ip.  Incidentally, there is a program I
distribute in Bitnet that allows this remote access to a file the person
owns but it is a private convention.  The program runs as a task (and
therefore must be running when the remote user wants access to his/her files).
and the user needs to set up a remote access password.  It uses the
Interactive Message Primitive to send and receive data, and each command
you want executed on the remote host must be prefixed with your remote pswd.
Not as elegent as TELNET but when the entire concept of TELNET doesn't exist
it is the best one can do.

> a remote file they don't own, but is not protected

Only if the file is available via a remote file server can they access it.

> a remote file they don't own, but is protected

They can't access it.

Hope this helps.

Hank

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1987 12:33:26 CST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        tsuchiya@MITRE-GATEWAY.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Packet network reliability
Paul,
  On the C/30 algorithm, I believe there are two occurences which can generate
an update.  One is the expiration of some timer which I've been told is 30 secs.
I seem to remember at one time the limit being around 15 secs.  
  The other occurence is in the case where a link is determined to be down.  I
made the assumption that as the total number of nodes and the connectivity
increases then the probability of link problems goes up.  Would it increase
linearly?  Would be an interesting study.
  I've always thought an interesting experiment would be to first determine an
estimated time for a routing update to propagate through the network.  Then
determine the time required for the Line Up-down Protocol to determine a link is
has either just went up or down and then generate the update.  Now place a few
unscrupulous individuals goegraphically widespread across the network on several
interswitch links.  Let these individual interupt the link at time T0 and 
then restore it at T0 + routing propagation time - LUP decision time.  How
much bandwidth could you forcibly use up with internal routing updates?
Ciao,
Darrel
-------
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 13:22:21 EST
From:      mfidelma@CC5.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   ICMP As A Diagnostic Tool?


It's been my observation that ICMP provides some useful functionality for
isolating and diagnosing internetwork problems - e.g. by timing pings, 
looking at what percentage of echos come back, source routing packets via
specific paths, route recording, etc.

It strikes me that the lack of similar functionality for the OSI world may
lead to an OSI internet in which significant classes of problems can not
be fault isolated. I find this a rather scary thought.

Does anybody have any comments, or better yet, examples of specific internet
problems in which ICMP was used for diagnostic purposes?

Miles Fidelman
BBN Communications
mfidelman@bbn.com

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      02 Apr 87 13:22:21 EST (Thu)
From:      "Miles R. Fidelman" <mfidelma@cc5.bbn.com>
To:        tcp-ip@sri-nic.ARPA
Subject:   ICMP As A Diagnostic Tool?

It's been my observation that ICMP provides some useful functionality for
isolating and diagnosing internetwork problems - e.g. by timing pings, 
looking at what percentage of echos come back, source routing packets via
specific paths, route recording, etc.

It strikes me that the lack of similar functionality for the OSI world may
lead to an OSI internet in which significant classes of problems can not
be fault isolated. I find this a rather scary thought.

Does anybody have any comments, or better yet, examples of specific internet
problems in which ICMP was used for diagnostic purposes?

Miles Fidelman
BBN Communications
mfidelman@bbn.com
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 13:33:26 EST
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Packet network reliability

Paul,
  On the C/30 algorithm, I believe there are two occurences which can generate
an update.  One is the expiration of some timer which I've been told is 30 secs.
I seem to remember at one time the limit being around 15 secs.  
  The other occurence is in the case where a link is determined to be down.  I
made the assumption that as the total number of nodes and the connectivity
increases then the probability of link problems goes up.  Would it increase
linearly?  Would be an interesting study.
  I've always thought an interesting experiment would be to first determine an
estimated time for a routing update to propagate through the network.  Then
determine the time required for the Line Up-down Protocol to determine a link is
has either just went up or down and then generate the update.  Now place a few
unscrupulous individuals goegraphically widespread across the network on several
interswitch links.  Let these individual interupt the link at time T0 and 
then restore it at T0 + routing propagation time - LUP decision time.  How
much bandwidth could you forcibly use up with internal routing updates?
Ciao,
Darrel
-------

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 13:45:46 EST
From:      jkh@VIOLET.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   My Broadcast

By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)

So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"

I will attempt to explain.

I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:

  ...

     Any of three fields can be empty, in which case it signifies
     a wild card.  Thus

                universal (,,)

     defines a group to which everyone belongs.  Field names that ...
  ...


Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.

Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.

Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?

All of this has raised some interesting points and problems.

1. Rwall will walk through your entire hosts file and blare at anyone
   and everyone if you use the (,,) wildcard group. Whether this is a bug
   or a feature, I don't know.

2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
   who you are as long as you're root (which is trivial to be, on a work-
   station), I have to wonder what other RPC services are open holes. We've
   managed to do some interesting, unauthorized, things with the YP service
   here at Berkeley, I wonder what the implications of this are.

3. Having a group called "broadcast" in your netgroup file (which is how
   it comes from sun) is just begging for some novice admin (or operator
   with root) to use it in the mistaken belief that he/she is getting to
   all the users. I am really surprised (as are many others) that this has
   taken this long to happen.

4. Killing rwall is not going to solve the problem. Any fool can write
   rwall, and just about any fool can get root priviledge on a Sun workstation.
   It seems that the place to fix the problem is on the receiving ends. The
   only other alternative would be to tighten up all the IMP gateways to
   forward packets only from "trusted" hosts. I don't like that at all,
   from a standpoint of reduced convenience and productivity. Also, since
   many places are adding hosts at a phenominal rate (ourselves especially),
   it would be hard to keep such a database up to date. Many perfectly well-
   behaved people would suffer for the potential sins of a few.


I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!

						Jordan Hubbard
						jkh@violet.berkeley.edu
						(ucbvax!jkh)

					Computer Facilities & Communications.
					U.C. Berkeley

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 13:48:51 EST
From:      usenet@JADE.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: jade!violet.berkeley.edu!jkh
From: jkh@violet.berkeley.edu (Jordan K. Hubbard)
Newsgroups: mod.protocols.tcp-ip
Subject: jkh annoys the net
Message-ID: <3011@jade.BERKELEY.EDU>
Date: 2 Apr 87 18:48:50 GMT
Sender: usenet@jade.BERKELEY.EDU
Reply-To: jkh@violet.berkeley.edu(Jordan K. Hubbard)
Organization: University of California, Berkeley
Lines: 95

By now, many of you have heard of (or seen) the broadcast message I sent to
the net two days ago. I have since received 743 messages and have
replied to every one (either with a form letter, or more personally
when questions were asked). The intention behind this effort was to
show that I wasn't interested in doing what I did maliciously or in
hiding out afterwards and avoiding the repercussions. One of the
people who received my message was Dennis Perry, the Inspector General
of the ARPAnet (in the Pentagon), and he wasn't exactly pleased.
(I hear his Interleaf windows got scribbled on)

So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my
screen??"

I will attempt to explain.

I head a small group here at Berkeley called the "Distributed Unix Group".
What that essentially means is that I come up with Unix distribution software
for workstations on campus. Part of this job entails seeing where some of
the novice administrators we're creating will hang themselves, and hopefully
prevent them from doing so. Yesterday, I finally got around to looking
at the "broadcast" group in /etc/netgroup which was set to "(,,)". It
was obvious that this was set up for rwall to use, so I read the documentation
on "netgroup" and "rwall". A section of the netgroup man page said:

  ...

     Any of three fields can be empty, in which case it signifies
     a wild card.  Thus

                universal (,,)

     defines a group to which everyone belongs.  Field names that ...
  ...


Now "everyone" here is pretty ambiguous. Reading a bit further down, one
sees discussion on yellow-pages domains and might be led to believe that
"everyone" was everyone in your domain. I know that rwall uses point-to-point
RPC connections, so I didn't feel that this was what they meant, just that
it seemed to be the implication.

Reading the rwall man page turned up nothing about "broadcasts". It doesn't
even specify the communications method used. One might infer that rwall
did indeed use actual broadcast packets.

Failing to find anything that might suggest that rwall would do anything
nasty beyond the bounds of the current domain (or at least up to the IMP),
I tried it. I knew that rwall takes awhile to do its stuff, so I left
it running and went back to my office. I assumed that anyone who got my
message would let me know.. Boy, was I right about that!
After the first few mail messages arrived from Purdue and Utexas, I begin
to understand what was really going on and killed the rwall. I mean, how
often do you expect to run something on your machine and have people
from Wisconsin start getting the results of it on their screens?

All of this has raised some interesting points and problems.

1. Rwall will walk through your entire hosts file and blare at anyone
   and everyone if you use the (,,) wildcard group. Whether this is a bug
   or a feature, I don't know.

2. Since rwall is an RPC service, and RPC doesn't seem to give a damn
   who you are as long as you're root (which is trivial to be, on a work-
   station), I have to wonder what other RPC services are open holes. We've
   managed to do some interesting, unauthorized, things with the YP service
   here at Berkeley, I wonder what the implications of this are.

3. Having a group called "broadcast" in your netgroup file (which is how
   it comes from sun) is just begging for some novice admin (or operator
   with root) to use it in the mistaken belief that he/she is getting to
   all the users. I am really surprised (as are many others) that this has
   taken this long to happen.

4. Killing rwall is not going to solve the problem. Any fool can write
   rwall, and just about any fool can get root priviledge on a Sun workstation.
   It seems that the place to fix the problem is on the receiving ends. The
   only other alternative would be to tighten up all the IMP gateways to
   forward packets only from "trusted" hosts. I don't like that at all,
   from a standpoint of reduced convenience and productivity. Also, since
   many places are adding hosts at a phenominal rate (ourselves especially),
   it would be hard to keep such a database up to date. Many perfectly well-
   behaved people would suffer for the potential sins of a few.


I certainly don't intend to do this again, but I'm very curious as to
what will happen as a result. A lot of people got wall'd, and I would think
that they would be annoyed that their machine would let someone from the
opposite side of the continent do such a thing!

						Jordan Hubbard
						jkh@violet.berkeley.edu
						(ucbvax!jkh)

					Computer Facilities & Communications.
					U.C. Berkeley

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 14:02:36 EST
From:      GROSSMAN@SIERRA.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  danger of bridges

In the absence of a Designated Router, DECnet endnodes (on an Ethernet)
will attempt to communicate by sending to the destination node's Ethernet
address.  This Ethernet address is computed from the node's DECnet host
number.  This is why all DECnet hosts on an Ethernet have funny addresses.

A DECnet Ethernet address looks like AA-00-04-00-XX-YY, where XX-YY is the
DECnet host number with the bytes swapped (don't shoot me, I'm just the
piano player).
			Stu Grossman
-------

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 15:19:00 EST
From:      bill@NRL-LCP.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Response to anti-bridge comments

> Date: Tue, 31 Mar 87 15:33:29 EST
> From: jas@monk.proteon.com (John A. Shriver)
> Subject: Response to anti-bridge comments
 
>           The very nature of bridges prevents you from doing load
> sharing (unless you manually program the filtering/forwarding
> databases, giving up the advantages of adaptive bridges).

I don't think it's anything intrinsic about a Bridge that would prevent
you from doing load sharing.  It's only a function of the current
Bridge software that this isn't currently possible.  One simple scheme
that I just happened to think of off the top of my head would involve
having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would
handle those Ethernet addresses which modulo 2**N matched its own
assigned Bridge number.  A hot spare could detect the failure of any
particular live Bridge, and take over for it.  One Bridge could be
designated to handle broadcast packets.  Does anyone know if such a
scheme or anything similar has been considered for doing load sharing
across Bridges?  It doesn't seem that it would be that difficult to
implement.

By the way, in practice, at least at our site, the level of traffic
through our Ethernet Bridges is nowhere near significant enough to
even start to worry about load sharing, and we have a fairly extensive
Ethernet based network in active use here at NRL.

>                                                            Gateways
> with multipath internal routing algorithms can do load sharing, look
> at BBN's PSN software using SPF on the ARPANET and MILNET.  Sooner or
> later, a network gets big enough and complicated enough that one
> migrates from bridges to routers.

Although Gateways/Routers COULD also do load sharing with appropriate
routing algorithms, it is my understanding that all of the current
Gateways, even those with SPF routing, DO NOT currently do any kind
of load sharing, and only understand and compute a single path to any
given destination.  I specifically asked this question at the TCP/IP
Interoperability Conference held just recently in Monterey, and that
was the answer I was given by someone involved with the SPF routing
Gateways.

> What the advocates are arguing about is where the line between bridges
> and routers is.

I think there are appropriate circumstances to use both Bridges and
Gateways/Routers.  The primary benefits that I see for using Bridges,
given the state of current technology, is ease of installation,
monitoring, and management, and the fact that they are protocol
transparent to the higher layer protocols.  In the future, they
will probably even be used to connect dissimilar technologies, such
as Ethernet and FDDI Fiber Optic networks.  But Gateways certainly
have their appropriate niche also, such as providing a higher degree
of isolation between the connected networks when this is desirable.

						-My first plunge

						-Bill Fink
						 bill@NRL-LCP
------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 87 15:19:00 EST
From:      <bill@nrl-lcp.arpa>
To:        "tcp-ip" <tcp-ip@nic>
Subject:   Re: Response to anti-bridge comments
> Date: Tue, 31 Mar 87 15:33:29 EST
> From: jas@monk.proteon.com (John A. Shriver)
> Subject: Response to anti-bridge comments

>           The very nature of bridges prevents you from doing load
> sharing (unless you manually program the filtering/forwarding
> databases, giving up the advantages of adaptive bridges).

I don't think it's anything intrinsic about a Bridge that would prevent
you from doing load sharing.  It's only a function of the current
Bridge software that this isn't currently possible.  One simple scheme
that I just happened to think of off the top of my head would involve
having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would
handle those Ethernet addresses which modulo 2**N matched its own
assigned Bridge number.  A hot spare could detect the failure of any
particular live Bridge, and take over for it.  One Bridge could be
designated to handle broadcast packets.  Does anyone know if such a
scheme or anything similar has been considered for doing load sharing
across Bridges?  It doesn't seem that it would be that difficult to
implement.

By the way, in practice, at least at our site, the level of traffic
through our Ethernet Bridges is nowhere near significant enough to
even start to worry about load sharing, and we have a fairly extensive
Ethernet based network in active use here at NRL.

>                                                            Gateways
> with multipath internal routing algorithms can do load sharing, look
> at BBN's PSN software using SPF on the ARPANET and MILNET.  Sooner or
> later, a network gets big enough and complicated enough that one
> migrates from bridges to routers.

Although Gateways/Routers COULD also do load sharing with appropriate
routing algorithms, it is my understanding that all of the current
Gateways, even those with SPF routing, DO NOT currently do any kind
of load sharing, and only understand and compute a single path to any
given destination.  I specifically asked this question at the TCP/IP
Interoperability Conference held just recently in Monterey, and that
was the answer I was given by someone involved with the SPF routing
Gateways.

> What the advocates are arguing about is where the line between bridges
> and routers is.

I think there are appropriate circumstances to use both Bridges and
Gateways/Routers.  The primary benefits that I see for using Bridges,
given the state of current technology, is ease of installation,
monitoring, and management, and the fact that they are protocol
transparent to the higher layer protocols.  In the future, they
will probably even be used to connect dissimilar technologies, such
as Ethernet and FDDI Fiber Optic networks.  But Gateways certainly
have their appropriate niche also, such as providing a higher degree
of isolation between the connected networks when this is desirable.

						-My first plunge

						-Bill Fink
						 bill@NRL-LCP
------
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 18:20:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ICMP As A Diagnostic Tool?


I "pinger and grease monkey of the year" award probably goes to DAve Mills
who has probably launched more pings in the Internet than any other player.

Vint

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 1987 18:20-EST
From:      CERF@A.ISI.EDU
To:        mfidelma@CC5.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ICMP As A Diagnostic Tool?

I "pinger and grease monkey of the year" award probably goes to DAve Mills
who has probably launched more pings in the Internet than any other player.

Vint
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 21:01:33 EST
From:      BOB@WARD.CS.WASHINGTON.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   ip subnets

I am trying to gather a bit of information about the use of subnets on
the internet.  Of all the sites on the internet that have been
assigned a class-B (class-A too, but there are not many of those)
network number, who uses subnets.  If you have a class-B network number,
I would like to ask you 2 questions:

1) Do you use subnets?  Why?
2) What type of link/physical layers do you run ip datagrams over?

Any responses would be greatly appreciated.  I will tabulate and post to
the net, if there is sufficient interest.  -thanks.

 -bob
-------

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Thu, 2-Apr-87 21:45:55 EST
From:      narten@PURDUE.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network

>     Presumably, as domain names get extended, we will be able to
>     do that.  Any mail you send to a user can go directly to the machine
>     where the his/her mailbox resides. No forwarding at the site would be
>     needed.

There is still a hole with current TCP mailers in that often mail
really travels an extra hop. That is, mail for janedoe@somewhere.edu
gets sent to the machine at "somewhere.edu", which after accepting the
mail, turns around and forwards it the machine the user reads mail on.
I would prefer an acknowledgement that mail has actually been placed
in the users mailbox, rather than just handing the mail to a
"reliable" delivering agent at the site.

Domain names were designed to handle lots more than just machine name
to IP address mappings. At some point, it will (hopefully) be possible
to register mailboxes in the system. That way, mail sent to
janedoe@somewhere.edu will not necessarily mean sending the mail to
"somewhere.edu". Rather, sendmail will find the real agent via
nameserver queries about "janedoe@somewhere.edu".  Now mail gets sent
directly to the machine where the user's mailbox resides, and now when
the mail is no longer in the sender's local queue, it really is in the
correct mailbox, and not still in transit somewhere.

Thomas

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Thu, 02 Apr 87 14:57:04 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Bitnet protocols
I sent this yesterday and I never saw it come back so I have a feeling it
got lost on its way:

(Caveat - This description is primarily for people who have no idea how
 Bitnet works.)

Greg,

The concept of remote access doesn't exist in Bitnet.  The protocols in
Bitnet are as follows:

1) One-way File Transfer - any user is allowed to send a file to any other
   user.  Since the file ends up in the destination users spool system
   (or some emulation thereof) there is no problem with access control.

2) Interactive Message - any user can send a one line message (max 160
   characters) to any other user.  All you need to know is the destination
   user and node.  If the user is not logged on or a link is down you are
   told so.

Based on these two primitives - Bitnet has built various other
pseudo-protocols.  From #1 above - we are able to do mail, list explosion,
computer conferencing, general file transfer.  From #2 above, Bitnet has
developed a CB (Chat) system.

By combined both of the basic primitives above, a file server can be set
up at any node that will trap incoming 'Interactive Messages' - which
contain a command and process the command and send the results back to the
user via the 'One-Way File Transfer' mechanism.  This method allows users
to sit at their machine and issue commands like DIR or LIST to some remote
file server and then issue some SEND commands to retrieve the files they
want.  There is no need in that case to do any sort of remote connect
(anonymous FTP).

Most servers (200+) in Bitnet also accept transactions via files or RFC822
mail.  Lately, various servers in Arpanet have decided that is also a 'clever'
thing to have, so we have things like archive-request@simtel20.arpa and
service@sri-nic.arpa popping up (I expect more before the end of th year).

So to answer your question:

> a remote file they own

They cannot access it.  Yup would be nice and that is just one reason why
Bitnet should convert to Tcp/Ip.  Incidentally, there is a program I
distribute in Bitnet that allows this remote access to a file the person
owns but it is a private convention.  The program runs as a task (and
therefore must be running when the remote user wants access to his/her files).
and the user needs to set up a remote access password.  It uses the
Interactive Message Primitive to send and receive data, and each command
you want executed on the remote host must be prefixed with your remote pswd.
Not as elegent as TELNET but when the entire concept of TELNET doesn't exist
it is the best one can do.

> a remote file they don't own, but is not protected

Only if the file is available via a remote file server can they access it.

> a remote file they don't own, but is protected

They can't access it.

Hope this helps.

Hank
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 02:14:34 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  danger of bridges

Drew,

The fuzzies, as you know, use broadcast, rather than multicast. There is in
principle no problem using restricted multicast, but then this also apllies
to RIP and others. Do you have a concrete suggestion on how to manage the
multicast group?

Dave

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 02:17:47 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  INFO REQUEST!

Brian,

Contact Dave Stoffel (dave@mimsy.umd.edu) for much information on Braille
and computers, including packet radio and related topics.

Dave

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 05:35:23 EST
From:      jon@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   NIFTP

A few days ago i inadvertantly mentioned the UK JNT spooled file
transfer service as a neat means of getting data around a
network. A larginsh number of people have asked me for more
information, so

Network Independant File Transfer protocol  (aka Blue Book),
normally runs over transport + X.25, but can and does run over
TCP/IP at some sites (using well known port 47).

 Does recovery from connection failure, is spooled etc. Is
widely used in the UK for email, a lot.

A list of implementations can be got from:

r.cooper@gec-b.rutherford.ac.uk

One unix version can be got from SApider Systems, or ask piet
brooks at Cambridge (don't have his address, but requests to
mailgroup@ucl.cs.ac.uk will find him).

jon

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 07:46:44 EST
From:      sra@MITRE-BEDFORD.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   TCP/IP for NCR 3000, Burrougs XE520 and B-25

The ULANA program has been requested to add three machines to its list of
hosts to be supported.  These are:
NCR WS3000 with CTOS
Burroughs XE520 with CTOS, BTOS, MSDOS, or XENIX
Burroughs B-25 with MSDOS, or BTOS

I am unfamilar with any of these machines but I would like to acomodiate
the request if interfaces are available.

We are looking for an 802.3 interface with TCP,IP,TELNET,FTP,SMPT,etc
any information or leads would be greatly appreciated.

Stan Ames
sra at mitre-bedford

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 10:28:41 EST
From:      mohamed%hscfvax@HARVARD.HARVARD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Time RFC 868

I would like to hear from sites that keep exact time and make it
available (RFC 868) to others.  Also whether it is available via
TCP or UDP.

Thanks

ellozy@harvard.harvard.edu

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Apr 87 10:28:41 EST
From:      mohamed%hscfvax@harvard.harvard.edu (750025@Mohamed_el_Lozy)
To:        tcp-ip@sri-nic.arpa
Subject:   Time RFC 868
I would like to hear from sites that keep exact time and make it
available (RFC 868) to others.  Also whether it is available via
TCP or UDP.

Thanks

ellozy@harvard.harvard.edu
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 10:29:37 EST
From:      jmg@CERNVAX.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ethernet TCP/IP broadcasts: help


Last Wednesday (yes, it was April 1st; no it was NO JOKE) we got a
situation on our Ethernet where a particular telnet RST packet from
a host to a client was being sent inside a broadcast packet. The
trouble was that this same broadcast packet was being sent out repeatedly
by just about every TCP/IP host on our Ethernet (including both VMS
with Wollongong and 4.2BSD). Thus, we were seeing about 1000 broadcast
packets per second, coming from many diffferent sources but all containing
this same RST information. This was, of course, killing all the small
microvaxes and weaker 750/780 etc., with only the big 8800 having enough
clout to continue apparently normally.

We eventually stopped it by disconnecting all of the offenders, much
to their disgust. After that everything started fine.

Since we started installing Ethernet some years ago we have never seen
such a catastrophic situation. Therefore, if anyone has any idea why
so many vaxes should start rebroadcasting packets which were nothing
to do with them I should be eternally grateful.

Mike Gerard

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 11:52:45 EST
From:      brescia@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   multicast groups on ether (was: danger of bridges)


     Do you have a concrete suggestion on how to manage the multicast group?

How about the following (summary: manage by czar).

The goal is to completely eliminate use of the broadcast address.  TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.

Go to the ethernet number czar and get two (2) groups of 65536 (2^^16)
multicast addresses.  By that, I mean the high order 32 bits are assigned by
the czar, and the low 16 bits are ours to play with.  Call the first group
<ether-link> and the second group <ip-port>.  These become well know, and wired
in the programs, much like 255.255.255.255.255.255 is today.

The first group, <ether-link>, is the contact address for all hosts which
handle 'broadcast' for a particular ether link (message type).  Thus ARP,
instead of polluting all the hosts in the net, would send to the address
<ether-link>.8.6 (0x0806 is the number assigned to the address resolution
protocol).

The second group, <ip-port> is the set of addresses for IP broadcast
protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one
byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea).

While this idea is a bit half-baked, it should serve to move host and gateway
impementations to independence from broadcasts.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      03 Apr 87 11:52:45 EST (Fri)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        Mills@louie.udel.edu
Cc:        Drew Daniel Perkins <ddp#@andrew.cmu.edu>, tcp-ip@sri-nic.ARPA, tsuchiya@gateway.mitre.org, x3s33-interest@gateway.mitre.org
Subject:   multicast groups on ether (was: danger of bridges)

     Do you have a concrete suggestion on how to manage the multicast group?

How about the following (summary: manage by czar).

The goal is to completely eliminate use of the broadcast address.  TCP/IP
implementations may be overusing this feature, between ARP, RWHO, etc.

Go to the ethernet number czar and get two (2) groups of 65536 (2^^16)
multicast addresses.  By that, I mean the high order 32 bits are assigned by
the czar, and the low 16 bits are ours to play with.  Call the first group
<ether-link> and the second group <ip-port>.  These become well know, and wired
in the programs, much like 255.255.255.255.255.255 is today.

The first group, <ether-link>, is the contact address for all hosts which
handle 'broadcast' for a particular ether link (message type).  Thus ARP,
instead of polluting all the hosts in the net, would send to the address
<ether-link>.8.6 (0x0806 is the number assigned to the address resolution
protocol).

The second group, <ip-port> is the set of addresses for IP broadcast
protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one
byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea).

While this idea is a bit half-baked, it should serve to move host and gateway
impementations to independence from broadcasts.
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3 Apr 87 12:14:24 EST
From:      Mills@UDEL.EDU
To:        jon@cs.ucl.ac.uk
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Tcp/Ip vs a store & forward network
Jon,

Then your worries are over. There is a NIFTP implementation running on
TOPS-20s and fuzzballs. Since further development of FTP is not in the mainstream
and that dinosaur is many years old now, it is not fair to bash it.
Why don't you guys poke Berkeley to include your NIFTP with Unix
distributions as an interim until FTAM (on TCP or whatever) is available?

Dave
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1987 15:55-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Mike Brescia <brescia@ccv.bbn.com>
Cc:        Mills@louie.udel.edu, Drew Daniel Perkins <ddp@andrew.cmu.edu>, tcp-ip@sri-nic.ARPA, tsuchiya@mitre-gateway.ARPA, x3s33-interest@mitre-gateway.ARPA
Subject:   Re: multicast groups on ether
    The goal is to completely eliminate use of the broadcast address.  TCP/IP
    implementations may be overusing this feature, between ARP, RWHO, etc.

Hear! hear!  At the moment, if you want to use IP on an Ethernet, you
must listen to Ethernet broadcasts, for the sake of ARP.  Here at
Stanford, that means you get to receive and discard packets broadcast
for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name
lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new
broadcast protocol was invented today.

In RFC988, I propose a way to manage multicast addresses for IP-based
applications.  I suggest that the number czar should allocate well-known
IP multicast address, rather than Ethernet multicast addresses, and that
there should be a standard mapping from IP to local network multicast
addresses for each type of local network.

As for ARP, I think ARP-for-IP should use a different Ethernet multicast
address than ARP-for-Chaos or ARP-for-whatever, even though they use the
same Ether-type.  And, of course, Reverse ARP should use different
addresses than ARP.

To phase in multicast-based ARP, you could (during the phase-in period)
listen to both the broadcast address and the multicast address.  When
sending an ARP request, use the multicast address first, then broadcast
if you don't get a reply.

Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support
RFC988-style multicasting, on top of which I have implemented a
multicast version of Berkeley's rwho daemon.  This code (both Karen's
and mine) is running successfully at a couple of test sites and I hope
it will soon be made available for wider distribution to those who wish
to experiment with IP multicasting.

I would appreciate any feedback on RFC988.  I would also like to hear
of any other work going on in the area of internetwork multicasting.
In particular, is the x3s33 committee considering internetwork multicast
addressing and routing?

Steve Deering
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 13:45:11 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network


     There is still a hole with current TCP mailers in that often mail
     really travels an extra hop. That is, mail for janedoe@somewhere.edu
     gets sent to the machine at "somewhere.edu", which after accepting the
     mail, turns around and forwards it the machine the user reads mail on.
     I would prefer an acknowledgement that mail has actually been placed
     in the users mailbox, rather than just handing the mail to a
     "reliable" delivering agent at the site.

Like the gentleman from rice said, you don't always know when mail is
placed in the user's mailbox.  It may be a post-office type system,
where mail is read from a mail server, but composed from the mail
client.  Everything is done without forwarding.  When do you decide that
the mail is in the mailbox?

     Domain names were designed to handle lots more than just machine name
     to IP address mappings. At some point, it will (hopefully) be possible
     to register mailboxes in the system. That way, mail sent to
     janedoe@somewhere.edu will not necessarily mean sending the mail to
     "somewhere.edu". Rather, sendmail will find the real agent via
     nameserver queries about "janedoe@somewhere.edu".  Now mail gets sent
     directly to the machine where the user's mailbox resides, and now when
     the mail is no longer in the sender's local queue, it really is in the
     correct mailbox, and not still in transit somewhere.

It still might be in transit somewhere -- the mailbox entries may point
to non-Internet sites which will require at least an extra hop at a mail
bridge.

Does this "ack" scheme imply retransmission of a mail message until a
retransmission timeout?  I would hate to see those old "Message queued
for 3 days -- will try again for another 12 days" messages from mailers
coming to my mailbox again.

--gregbo

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Fri, 03 Apr 87 10:18:05 +0000
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   NIFTP
A few days ago i inadvertantly mentioned the UK JNT spooled file
transfer service as a neat means of getting data around a
network. A larginsh number of people have asked me for more
information, so

Network Independant File Transfer protocol  (aka Blue Book),
normally runs over transport + X.25, but can and does run over
TCP/IP at some sites (using well known port 47).

 Does recovery from connection failure, is spooled etc. Is
widely used in the UK for email, a lot.

A list of implementations can be got from:

r.cooper@gec-b.rutherford.ac.uk

One unix version can be got from SApider Systems, or ask piet
brooks at Cambridge (don't have his address, but requests to
mailgroup@ucl.cs.ac.uk will find him).

jon
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 15:29:31 EST
From:      m15368%mwvm@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   (none)


 To: CERF%A.ISI.EDU    CERF at A.ISI.EDU
 From: Steve Silverman
 Subject: Layer 2 multiplexing on ISDN
     
     
     
 The proposed Frame Relay service of ISDN does do layer 2 multiplexing.
 In LAPD, there is a 2 byte address containing a 6 bit SAPI and a 7 bit TEI
 (Terminal Equipment Identifier).  These 2 fields are combined into a
 13 bit DLCI (Data Link Connection Identifier) which would be handled
 similarly to the LCN in X.25.  It would be mapped and set in each node as a
 frame progressed through the network.  Then a new CRC would be calculated
 and inserted.
 *
 *        Steve
     
 Cc: TCP-IP@SRI-NIC.ARPA                   MITRE(MCKEE)      MCKEE at MITRE

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 17:25:06 EST
From:      martinea@SKL-CRC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   RDP source




Is anyone aware of public domain RDP source???  I would like to use
RDP but want to avoid the pain of re-inventing the wheel.

Thanks in advance.

Mike Martineau

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 18:55:00 EST
From:      deering@PESCADERO.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: multicast groups on ether


    The goal is to completely eliminate use of the broadcast address.  TCP/IP
    implementations may be overusing this feature, between ARP, RWHO, etc.

Hear! hear!  At the moment, if you want to use IP on an Ethernet, you
must listen to Ethernet broadcasts, for the sake of ARP.  Here at
Stanford, that means you get to receive and discard packets broadcast
for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name
lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new
broadcast protocol was invented today.

In RFC988, I propose a way to manage multicast addresses for IP-based
applications.  I suggest that the number czar should allocate well-known
IP multicast address, rather than Ethernet multicast addresses, and that
there should be a standard mapping from IP to local network multicast
addresses for each type of local network.

As for ARP, I think ARP-for-IP should use a different Ethernet multicast
address than ARP-for-Chaos or ARP-for-whatever, even though they use the
same Ether-type.  And, of course, Reverse ARP should use different
addresses than ARP.

To phase in multicast-based ARP, you could (during the phase-in period)
listen to both the broadcast address and the multicast address.  When
sending an ARP request, use the multicast address first, then broadcast
if you don't get a reply.

Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support
RFC988-style multicasting, on top of which I have implemented a
multicast version of Berkeley's rwho daemon.  This code (both Karen's
and mine) is running successfully at a couple of test sites and I hope
it will soon be made available for wider distribution to those who wish
to experiment with IP multicasting.

I would appreciate any feedback on RFC988.  I would also like to hear
of any other work going on in the area of internetwork multicasting.
In particular, is the x3s33 committee considering internetwork multicast
addressing and routing?

Steve Deering

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 21:18:43 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

John,  I think you did a good thing.  Testing for idiotic holes in
the "system".  Now, if you could figure out a way to encourage
them to get plugged.  I remember years ago being annoyed at the 
loose security in the Tenex operating system that was prevalent
on the early Arpanet.  I couldn't get the wizards at BBN to "fix"
the problems by the "usual" means.  So, one day I took advantage of
the holes and, across the net, all by myself with no confederates,
obtained the password of the wizard of all wizards and sent it to him 
in a one word mail message.  No other communication was necessary.
He plugged the holes as fast as his fingers could type.  I was a "good
guy" and he knew it, but it took an actual event to drive the point home 
it wouldn't be too long before someone else would figure out the
method i used an dperhaps not be so benign.  
Can you think of a similar thing to do?  Or have you already done it?
(I think not because what you are pointing out is going to take
lots of thinking to solve.  But, it has to start somewhere.

Dan
-------

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 1987 21:18:43 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        jkh%violet.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Jordan K. Hubbard)
Cc:        hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: My Broadcast
John,  I think you did a good thing.  Testing for idiotic holes in
the "system".  Now, if you could figure out a way to encourage
them to get plugged.  I remember years ago being annoyed at the 
loose security in the Tenex operating system that was prevalent
on the early Arpanet.  I couldn't get the wizards at BBN to "fix"
the problems by the "usual" means.  So, one day I took advantage of
the holes and, across the net, all by myself with no confederates,
obtained the password of the wizard of all wizards and sent it to him 
in a one word mail message.  No other communication was necessary.
He plugged the holes as fast as his fingers could type.  I was a "good
guy" and he knew it, but it took an actual event to drive the point home 
it wouldn't be too long before someone else would figure out the
method i used an dperhaps not be so benign.  
Can you think of a similar thing to do?  Or have you already done it?
(I think not because what you are pointing out is going to take
lots of thinking to solve.  But, it has to start somewhere.

Dan
-------
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 21:40:49 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  IP over x.25

Gerd,

I assume the X.25 connection is broken somewhere in the public-net path, perhaps
in either of the national X.25 nets or in the X.75 gateway(s). To break that
after two minutes of inactivity sounds broken in the extremus, especially if
the restoration costs real Geld. On the other hand, your opens are cheap, about
equivalent to twenty seconds of connect time, so maybe things aren't that bad,
at least if the reset/open can be made transparent to your TCP/TELNET connection.

Come to think of it, if the MILNET/ARPANET congestions is as fierce as you
report, it might be cheaper to encapsulate IP datagrams as fast-select packets,
rather than go through the complete virtual-circuit clankery. This might be
a fun puddle to go wading in. Lemme see, at twenty (roundtrip!) packets per 
Mark, you would break even at about seven minutes. Maybe not too bad under
current conditions...

While it is in principle possible to do all kinds of things which might convey
the connection-closed state at the VAN gateway to the end systems, I suggest
this would not be very useful if only to stimulate a re-open. If it really does
come down to keeping the connection open, the VAN driver could be modified to
send ICMP echoes to its peer just often enough to reset the VAN timers. Be
advised you did not hear me say this, for I am not present and will instantly
disavow any attribution of such nonsense to mine lips. Now, I hope that will
keep the truthspeakers from my throat. Yes, and stop the ICMP echoes after
a period when no other traffic is present. [Gaggg]

Dave

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 22:48:51 EST
From:      gordan@maccs.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: maccs!gordan
From: gordan@maccs.UUCP (Gordan Palameta)
Newsgroups: mod.protocols.tcp-ip
Subject: TCP retransmission
Keywords: retransmission algorithm
Message-ID: <519@maccs.UUCP>
Date: 4 Apr 87 03:48:50 GMT
Reply-To: gordan@maccs.UUCP (Gordan Palameta)
Distribution: world
Organization: DCSS, McMaster University, Hamilton, Ontario, Canada
Lines: 20

Hello...

I'm currently writing some TCP-IP code (for a PDP-11 running RT-11), and am
looking to do retransmissions correctly.

From what I've read here, poor retransmission behavior is a major source
of congestion... although my code is intended for a very lightly loaded
Ethernet and I can get away with being sloppy, if there's a painless way to
do it right for the general case, it would be nice to put it in.

I understand the idea of exponential backoff, and know of the RTT-based
algorithm suggested in the RFC (which I believe is what BSD 4.2 uses (?))...
is this the proper algorithm to use, or is there a better one?

Thanks for any info...

-- 
UUCP:  ... !seismo!mnetor!lsuc!maccs!gordan   (note ..dAn or mail may bounce)
BITNET: GP@TANDEM                        ^  <---' 
                    Gordan Palameta

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Fri, 3-Apr-87 23:18:26 EST
From:      cyrus@hi.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Ethernet TCP/IP broadcasts: help

In article <459@cernvax.UUCP> cernvax!jmg () writes:
 >
 >Last Wednesday (yes, it was April 1st; no it was NO JOKE) we got a
 >situation on our Ethernet where a particular telnet RST packet from
 >a host to a client was being sent inside a broadcast packet. The
 >trouble was that this same broadcast packet was being sent out repeatedly
 >by just about every TCP/IP host on our Ethernet (including both VMS
 >with Wollongong and 4.2BSD). Thus, we were seeing about 1000 broadcast
 >packets per second, coming from many diffferent sources but all containing
 >this same RST information. This was, of course, killing all the small
 >microvaxes and weaker 750/780 etc., with only the big 8800 having enough
 >clout to continue apparently normally.
 >
 >We eventually stopped it by disconnecting all of the offenders, much
 >to their disgust. After that everything started fine.
 >
 >Since we started installing Ethernet some years ago we have never seen
 >such a catastrophic situation. Therefore, if anyone has any idea why
 >so many vaxes should start rebroadcasting packets which were nothing
 >to do with them I should be eternally grateful.
 >
 >Mike Gerard
 
 
 We had a simular problem with one of our micro vax II running Ultrix.
 There had been a brown out (power surge) and all our machines continued
 to run (more uvax II's and sun 2's and 3's).  We noticed that the network
 was slow though.  After some investigation we determined that this one
 uvax II was rebroadcasting every packet on the network 4, yes four times.
 We tried 'ifconfig down' and then 'ifconfig up' without any success.
 The only thing we could do was to reboot.

 A possible explanation was that the dequna's table of valid ethernet
 addresses to accept got hosed.  If this occured then it would basically
 be like in promiscuous mode.  On receiving these packets it would determine
 that none of the packets were for it so it would REbroadcast these packets.
 This still does not explain why it was duplicating packets.

 Strange............

 Sorry this is no help but, ....

-- 
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|         /|    University of New Mexico
  / |        / |    Dept of EECE - Hypercube Project
 @__|_______@  |    Albuquerque, New Mexico 87131
 |  |       |  |
 |  |  hc   |  |    e-mail:
 |  @.......|..@       cyrus@hc.dspo.gov or cyrus@hc.arpa or
 | /        | /        {gatech|ucbvax|convex}!unmvax!hi!cyrus
 @/_________@/

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Sat, 04 Apr 87 10:40:32 EST
From:      H. Craig McKee <mckee@mitre.ARPA>
To:        CERF@A.ISI.EDU
Cc:        mckee@mitre.ARPA, tcp-ip@SRI-NIC.ARPA, m15368%mwvm@mitre.ARPA
Subject:   Layer 2 muxing on ISDN
     
The proposed Frame Relay service of ISDN does do layer 2 multiplexing.
In LAPD, there is a 2 byte address containing a 6 bit SAPI and a 7 bit TEI
(Terminal Equipment Identifier).  These 2 fields are combined into a
13 bit DLCI (Data Link Connection Identifier) which would be handled
similarly to the LCN in X.25.  It would be mapped and set in each node as a
frame progressed through the network.  Then a new CRC would be calculated
and inserted.
*
*        Steve
     
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Apr-87 12:04:27 EST
From:      mckee@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: overloaded station wagon


>Forgive my inexperience at these things.
>I was just under the impression
>that such conversations are usually carried on elsewhere.
>I am being forced to filter my mail,
>to distill other more useful information on TCP/IP.

Come on, friend, lighten up, we are an eclectic group.  If you have no
use for an Illudium Q-2 Explosive Network Demodulator then I offer the
following story concerning the relative skills of French and German
diplomats.

At a banquet celebrating the fiftieth birthday of a reigning Queen,
whose name I will not mention for the sake of tact, every country
contributed a typical dish to the meal.  Unfortunately, the frijoles
refritos from Mexico and garbanzos from Spain very soon affected the
delicate digestion of the Queen.  In a moment of silence, one could
hear, very definitely from the seat of honor, the sound of escaping air.
   Immediately, the French Ambassador, purple-faced, was on his feet
saying, "Madame, I beg you, mille pardons, but my digestive system has
been very labile.  I have been warned by my doctor to eat bland foods
but have been unable to resist these delicacies."
    This, of course, was a serious diplomatic defeat for the other
ambassadors present, and was particularly felt by the representative of
the Third Reich, one Joachim von Ribbentrop.
    With a keen ear, he awaited another such happening from the royal
presence, and when it occurred, he jumped to his feet, clicked his
heels, and bowed, shouting, "Madame, this one and the next three are for
the Third Reich."

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Apr-87 15:38:42 EST
From:      malis@CC5.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Packet network reliability

Darrel,

I'm afraid your experiment wouldn't cause much as much routing
traffic as you think.  Your details on the PSN routing algorithm
were a bit wrong.  First, there are three things that can cause a
routing update to be generated: a link going up or down, the
delay to a neighbor PSN changing more than a certain threshold,
or the expiration of 50 seconds from the last time the PSN
generated an update.  Second, a PSN can generate an update at
most every 10 seconds, no matter how much is changing in the
network.  Third, when a link goes down, it takes 60 seconds to
bring it back up (this ensures that if a PSN was isolated
from the network, it cannot bring up its links until it has
received at least one routing update from every other PSN in the
network; otherwise, its routing database would be incomplete).

The estimated time for a routing update to propagate through the
network is simply the network "diameter" (the minimum-hop path
between the two most logically distant PSNs in the network) times
the average propagation delay across the links.  Flooding routing
updates gets the highest priority in the PSN, so intra-PSN delays
are usually negligible.

Since routing updates cannot be generated at a greater rate than
every 10 seconds by each PSN and at least every 50 seconds, it is
easy to calculate the minimum, average, and maximum number of
routing updates per minute on a network.  And since the line
up/down protocol keeps links down for at least 60 seconds,
manually making links go up or down will probably not produce any
more updates than you would have had anyway.

Andy

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      04 Apr 87 15:38:42 EST (Sat)
From:      Andy Malis <malis@cc5.bbn.com>
To:        AFDDN.TCP-IP@gunter-adam.ARPA
Cc:        tsuchiya@gateway.mitre.org, tcp-ip@sri-nic.ARPA, malis@cc5.bbn.com
Subject:   Re: Packet network reliability
Darrel,

I'm afraid your experiment wouldn't cause much as much routing
traffic as you think.  Your details on the PSN routing algorithm
were a bit wrong.  First, there are three things that can cause a
routing update to be generated: a link going up or down, the
delay to a neighbor PSN changing more than a certain threshold,
or the expiration of 50 seconds from the last time the PSN
generated an update.  Second, a PSN can generate an update at
most every 10 seconds, no matter how much is changing in the
network.  Third, when a link goes down, it takes 60 seconds to
bring it back up (this ensures that if a PSN was isolated
from the network, it cannot bring up its links until it has
received at least one routing update from every other PSN in the
network; otherwise, its routing database would be incomplete).

The estimated time for a routing update to propagate through the
network is simply the network "diameter" (the minimum-hop path
between the two most logically distant PSNs in the network) times
the average propagation delay across the links.  Flooding routing
updates gets the highest priority in the PSN, so intra-PSN delays
are usually negligible.

Since routing updates cannot be generated at a greater rate than
every 10 seconds by each PSN and at least every 50 seconds, it is
easy to calculate the minimum, average, and maximum number of
routing updates per minute on a network.  And since the line
up/down protocol keeps links down for at least 60 seconds,
manually making links go up or down will probably not produce any
more updates than you would have had anyway.

Andy
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Apr-87 16:39:43 EST
From:      kzm@ACC-SB-UNIX.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Wiretapping ICMP messages


There have been a number of suggestions on this list recently that
congestion-control could be enhanced if various IP implementations 
took note of ICMP Destination Unreachable messages, eg. if gateways
cached the information and refused to send packets based on this 
cached information.  It appears to me that this could cause problems 
when the routing and congestion algorithms are upgraded to include 
TOS-routing, Precedence, and Security.

TOS-routing may not be available yet, but it appears to be considered
a desirable addition in the (not too distant) future.  When it is 
available, a destination might be reachable with one TOS value, but
not with another.  Similarly, there is work underway to have packets
queued in switches (eg. in IMPs) according to their Precedence.
So, a similar scenario (reachable with a high Precedence value,
but not with a low value) could be applicable here also.  The use
of Security information as a routing criteria may be further into
the future, but the same considerations apply.

Of course, the cached information could be expanded to include TOS,
Precedence and Security along with the destination address.  The size 
of the cache would increase, but probably manageably-so for the time
being while the majority of packets have the same TOS/Precedence
/Security values.  However, this could cause a "scaling-up" problem 
in the future.  Also, the mechanism loses some of its usefulness when
it can only be applied to packets of the same TOS, Precedence, and
Security.  Again, this might not a problem today when the majority of 
packets have the same TOS/Precedence/Security values, but does it 
cater to the future ?

Keith McCloghrie
ACC, Columbia Md.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Sat, 4-Apr-87 21:18:43 EST
From:      gnu@hoptoad.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: multicast on ether

brescia@CCV.BBN.COM (Mike Brescia) writes:
> The goal is to completely eliminate use of the broadcast address.  TCP/IP
> implementations may be overusing this feature, between ARP, RWHO, etc.

I heartily agree with this goal.  While working at Sun I noticed a
large number of broadcast packets passing around, and this caused a few
amusing problems, especially when these packets were addressed to
user-mode daemons which swapped in over the ether.  Note, however, that
the current volume of broadcasts has the worst impact on hosts with old
or badly designed Ethernet interfaces, e.g. 3Com boards with one or two
receive buffers.  These interfaces typically don't filter multicast
packets anyway -- you can set a bit saying "receive multicast" or "toss
multicast" and no more.  Moving broadcast applications to multicast
will only benefit hosts with more modern, e.g. AMD or Intel VLSI,
interfaces.

> Go to the ethernet number czar and get two (2) groups of 65536 (2^^16)
> multicast addresses.  By that, I mean the high order 32 bits are assigned by
> the czar, and the low 16 bits are ours to play with.  

It might be worth looking at the filtering algorithms in the common
Ethernet chips before figuring out the configuration of the multicast
numbers.  Typically they hash the addresses down to ~6 bits and the
user supplies a 64-bit filter mask.  We should try to match the number
assignment to the hash functions.

>                                                                 Thus ARP,
> instead of polluting all the hosts in the net, would send to the address
> <ether-link>.8.6 (0x0806 is the number assigned to the address resolution
> protocol).

Virtually every host has to implement ARP so they will all be listening
on <ether-link>.8.6 and there would be no benefit over just
broadcasting.  In the case of ARP, it would be better if the multicast
address included the low byte of the Internet address you're looking
for, so that hosts which don't know anything about that Internet
address could ignore the packet in hardware.  Note that most machines
on one Ethernet will have the same high 3 bytes of their Internet
address, so supplying the whole thing would be overkill.


If a scheme like this gets worked out, I suggest that we allocate a bit
in the ARP packets for "I listen to multicast for IP broadcasts", to
tell a sending kernel which scheme to use (like the trailer protocol
stuff).  This begs the question of how the sending kernel decides how
to send the ARP Request packet, but we're designing on the fly here
anyway.  Of course, a receiving kernel that handles multicasts should
also accept the old broadcast packets for compatability.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 10:09:07 EST
From:      hwb@MCR.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: multicast groups on ether

You have to watch out, though. Most interfaces I know of only support a
limited set of multicast addresses (DEQNAs, I think, just have a table
for fourteen or so addresses in general). You don't really want to end
up having to listen to each and every packet in a multiprotocol gateway,
just because your multicast address table in the EThernet device overflows.

	-- Hans-Werner

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 11:21:15 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network

The concept of distributing internal configuration information to everyone
in the world is too prone to failures from too much information. Assuming
that people will extensively use the domain system to publish current
routing information for mailboxes and dealing with cacheing and all the
other problems is expecting too much. The idea is a nice one alas a very
flawed one (from too much data).

The trick at this pont is to just get a reasonable mail relaying mechansim up
and to get rid of the host table. The MX records solve in a not so great way
the problem of mail relaying for hosts not on the connected network alas a
better algorithm has not been thought up that did not get shot down (heck, we
can not even get packet routing right...how do you expect to get mail routing
right?) Also many places are still using the host table mechanism and are
starting to suffer because of the size problems....alas they have received
temporary relief in the form of a 10% smaller NIC table.

Let us keep an eye toward the future but make that first couple of steps
instead of just dreaming about the future....

-Rudy

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 11:57:12 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Whoa!

Encouraging people to find holes and then use them to make the local system
programmers work on them is wrong. It is like encouraging people to find out
if their neighbors lock their door during the day so they will. Do you really
want that or do you want the theives to be caught? I want the theives to be
caught and the ability to leave my door open. I don't want to fear my
neighborhood or my users.

I could spend many man years working on Unix security alone. The same is
TRUE with TOPS-20. The worst is when you fix a security problem and some
yo-yo finds out about it and then attacks some other remote site. The remote
site gets pissed and says it can not afford to fix it....would you please
deal with the yo-yo.

-RUdy

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 1987 15:09-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Hans-Werner Braun <hwb@MCR.UMICH.EDU>, hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)
Cc:        tcp-ip@sri-nic.ARPA, tsuchiya@mitre-gateway.ARPA, x3s33-interest@mitre-gateway.ARPA
Subject:   Re: multicast on ether

    From Hans-Werner Braun <hwb@MCR.UMICH.EDU>:

    You have to watch out, though. Most interfaces I know of only support a
    limited set of multicast addresses (DEQNAs, I think, just have a table
    for fourteen or so addresses in general). You don't really want to end
    up having to listen to each and every packet in a multiprotocol gateway,
    just because your multicast address table in the EThernet device
    overflows.

You don't have to listen to every packet, just every *multicast* packet,
when your multicast filter is exceeded.  The DEQNA and other interfaces
provide such a reception mode.  If we are just replacing broadcast packets
with multicast packets, listening to all multicasts is no worse than the
current situation of having to listen to all broadcasts.  However, using
multicast addresses is much better for those hosts that *are* able to filter
multicasts adequately.  Besides, it is not unreasonable to expect a
sophisticated multiprotocol gateway to have a sophisticated Ethernet
interface.  The important thing is to stop sending unwanted packets to
non-gateway hosts.

I agree that we should conserve multicast addresses by looking out for
situations in which more than one application may reasonably use the same
multicast address, but I don't think we should be bound by the limitations
of current hardware.  Once there is a demand for good multicast filtering,
the manufacturers will improve their products.

    From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)

    It might be worth looking at the filtering algorithms in the common
    Ethernet chips before figuring out the configuration of the multicast
    numbers.  Typically they hash the addresses down to ~6 bits and the
    user supplies a 64-bit filter mask.  We should try to match the number
    assignment to the hash functions.

That's a good idea if they all use the same hash function.  Both the AMD
7990 and the Intel 82586 send incoming multicast addresses though their
CRC generators and take 6 bits of the result as a hash value, as you
described.  From the documents I have, it is not obvious that they
both use the same 6 bits of the CRC in the same order.  (Can anyone say
for sure?)  Are there other hashing functions in use in other interfaces?

    Virtually every host has to implement ARP so they will all be listening
    on <ether-link>.8.6 and there would be no benefit over just
    broadcasting.

Hosts that aren't running IP aren't interested in ARP-for-IP packets.
Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO
protocols.  We don't like their broadcasts and they don't like ours.

    If a scheme like this gets worked out, I suggest that we allocate a bit
    in the ARP packets for "I listen to multicast for IP broadcasts", to
    tell a sending kernel which scheme to use (like the trailer protocol
    stuff).

I don't think any new bits are needed.  Just send your ARP requests to
the multicast address, and if you don't get an answer, try the broadcast
address.

Steve Deering
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 12:36:31 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP As A Diagnostic Tool?

Miles,

I suggest you invite co-BBNer Mike Brescia (X3662) for a beer and learn
all about ICMP uses and abuses. This is not a frivolous suggestion.

Dave

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 12:48:13 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP As A Diagnostic Tool?

Vint,

Well, I don't know about that, although I (modestly) claim to have invented
the term "ping" (Packet InterNet Groper) circa 1979. Mike Brescia at BBN,
Hans-Werver Braun at U Michigan and others have a lot of grease under their
fingernails.

Having said that, I can't imagine an internet (small i), ISO or any other,
viable in even the weakest sense without something like ICMP built into
the protocol stack at outset. I even have to resist saying that agian
for emphasis.

Dave

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 14:51:54 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Wiretapping ICMP messages

Keith,

The mechanism I suggested some time ago involves cacheing ICMP messages of
selected types for a period longer than the typical TCP retransmission
interval, but shorter than the typical "retry" interval, maybe a couple
of minutes or so. I did not specify which message types should be cached
and what detail information (TOS, etc.) should be saved, but did assume
as much information as useful in the routing algorithm. My suggestion
would not affect routing until a number of these messages (tbd) had been
received within a period equal to some number of TCP retransmissions,
maybe fifteen to thirty seconds. When that happened the local routing data
base would be marked "down" for that destination net/TOS/whatever and the
normal routing exchanges would do the rest.

You will note this is functionally identical to the hard-to-reach concept
used in the telephone network, except that routing updates per se are not
used in that network (#4 ESS non-hierarchical routing honkers will be
politely ignored here). I am not suggesting now as the optimum time to
construct a definitive proposal on how to implement this concept in a
j-random gateway, but am suggesting the concept ripe for experimentation
in a real gateway, maybe even a fuzzball.

Dave

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 15:16:59 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Time RFC 868

You can't keep "exact time" with RFC-868 time servers, since that protocol
provides resolution only to the second. You should really and truly avoid
TCP-based time, since not only is the accuracy udually degraded by the
clank-and-bump of the connection-open sequence, but the sometimes meager
resources of the time server can be strained. The protocol of choice is
the Network Time Protocol (NTP), documented in RFC-958, for which Unix-
based server and client programs are available (e.g. Mike Petry
petry@trantor.umd.edu, Milo Medin medin@orion.arpa, both for 4.3 systems).

As for the most accurate clocks in town, a fair number of "fuzzball"
gateways and hosts are equipped with WWVB and WWV radio clocks that can
deliver time accurate to a millisecond or two. Typical accuracies using
NTP via ARPANET/MILNET are within 20 to 100 milliseconds, depending on
the path and state of congestion. The fuzzballs are interconnected with
NTP and, in some cases an interior-gateway protocol called hellospeak
(c.f. RFC-891), so a failure in one radio clock does not frustrate the
clockwatchers.

At present the NSFNET Backbone sites are all synchronized to a WWVB
radio clock at Boulder, CO, and capable of very accurate and robust
time service using RFC-868 or NTP protocols. Use of TCP is adamantly
discourged with the former and not available with the latter. UDP is
the prefered envelope in any case. In addition, several WWVB-equipped
servers are scattered about, including macom1.arpa (192.5.8.1), umd1.umd.edu
(128.8.10.6) and ford1.arpa (182.5.0.1 - actually a GOES clock). Finally,
a few hosts scattered over the swamps support less-accurate WWV radio
which are also used as backups for the NTP system, including gw.umich.edu
(35.1.1.1) and udel2.udel.edu (192.5.39.87).

If present plans work out, the best places to watch clocks will be the
NSFNET Backbone fuzzballs or other hosts synchronized directly to them.
An announcement will be posted to this list when the details stabilize.
Meanwhile, feel free watch one or more of the clocks above, with the
first two (macom1.arpa or umd1.umd.edu) as the primary choice, but please
don't use TCP.

Dave

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 15:29:39 EST
From:      ROODE@BIONET-20.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   anti-bridge comment

I don't think anyone has pointed out the following advantage of
an IP gateway over a level 2 bridge between physical Ethernets.
Ethernet broadcasts are filtered by IP gateways whereas in the case
of bridges, full IP functionality between gateways requires that
all Ethernets so joined see the combined broadcasts of each network
in the group.  
-------

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 18:09:00 EST
From:      deering@PESCADERO.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: multicast on ether


    From Hans-Werner Braun <hwb@MCR.UMICH.EDU>:

    You have to watch out, though. Most interfaces I know of only support a
    limited set of multicast addresses (DEQNAs, I think, just have a table
    for fourteen or so addresses in general). You don't really want to end
    up having to listen to each and every packet in a multiprotocol gateway,
    just because your multicast address table in the EThernet device
    overflows.

You don't have to listen to every packet, just every *multicast* packet,
when your multicast filter is exceeded.  The DEQNA and other interfaces
provide such a reception mode.  If we are just replacing broadcast packets
with multicast packets, listening to all multicasts is no worse than the
current situation of having to listen to all broadcasts.  However, using
multicast addresses is much better for those hosts that *are* able to filter
multicasts adequately.  Besides, it is not unreasonable to expect a
sophisticated multiprotocol gateway to have a sophisticated Ethernet
interface.  The important thing is to stop sending unwanted packets to
non-gateway hosts.

I agree that we should conserve multicast addresses by looking out for
situations in which more than one application may reasonably use the same
multicast address, but I don't think we should be bound by the limitations
of current hardware.  Once there is a demand for good multicast filtering,
the manufacturers will improve their products.

    From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore)

    It might be worth looking at the filtering algorithms in the common
    Ethernet chips before figuring out the configuration of the multicast
    numbers.  Typically they hash the addresses down to ~6 bits and the
    user supplies a 64-bit filter mask.  We should try to match the number
    assignment to the hash functions.

That's a good idea if they all use the same hash function.  Both the AMD
7990 and the Intel 82586 send incoming multicast addresses though their
CRC generators and take 6 bits of the result as a hash value, as you
described.  From the documents I have, it is not obvious that they
both use the same 6 bits of the CRC in the same order.  (Can anyone say
for sure?)  Are there other hashing functions in use in other interfaces?

    Virtually every host has to implement ARP so they will all be listening
    on <ether-link>.8.6 and there would be no benefit over just
    broadcasting.

Hosts that aren't running IP aren't interested in ARP-for-IP packets.
Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO
protocols.  We don't like their broadcasts and they don't like ours.

    If a scheme like this gets worked out, I suggest that we allocate a bit
    in the ARP packets for "I listen to multicast for IP broadcasts", to
    tell a sending kernel which scheme to use (like the trailer protocol
    stuff).

I don't think any new bits are needed.  Just send your ARP requests to
the multicast address, and if you don't get an answer, try the broadcast
address.

Steve Deering

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Sun, 5-Apr-87 23:38:00 EST
From:      anon@CITI.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: overloaded station wagon


Shades of James Watt and the Beach Boys.
Apologies, everyone.

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 1987 00:38 EDT
From:      anon@citi.umich.edu
To:        mckee@mitre.ARPA
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: overloaded station wagon

Shades of James Watt and the Beach Boys.
Apologies, everyone.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 02:15:26 EST
From:      usenet@ucbvax.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Dan -

     I'm afraid you (and I, and any of the other old-timers who
care about security) are banging your head against a brick wall.
The philsophy behind Unix largely seems quite reminiscent of the
old ITS philsophy of "security through obscurity;" we must
entrust our systems and data to a open-ended set of youthful
hackers (the current term is "gurus") who have mastered the
arcane knowledge.

     The problem is further exacerbated by the multitude of slimy
vendors who sell Unix boxes without sources and without an
efficient means of dealing with security problems as they
develop.

     I don't see any relief, however.  There are a lot of
politics involved here.  Some individuals would rather muzzle
knowledge of Unix security problems and their fixes than see them
fixed.  I feel it is *criminal* to have this attitude on the DDN,
since our national security in wartime might ultimately depend
upon it.  If there is such a breach, those individuals will be
better off if the Russians win the war, because if not there will
be a Court of Inquiry to answer...

     It may be necessary to take matters into our own hands, as
you did once before.  I am seriously considering offering a cash
reward for the first discoverer of a Unix security bug, provided
that the bug is thoroughly documented (with both cause and fix).
There would be a sliding cash scale based on how devastating the
bug is and how many vendors' systems it affects.  My intention
would be to propagate the knowledge as widely as possible with
the express intension of getting these bugs FIXED everywhere.

     Knowledge is power, and it properly belongs in the hands of
system administrators and system programmers.  It should NOT be
the exclusive province of "gurus" who have a vested interest in
keeping such details secret.

-- Mark --

PS: Crispin's definition of a "somewhat secure operating system":
A "somewhat secure operating system" is one that, given an
intelligent system management that does not commit a blunder that
compromises security, would withstand an attack by one of its
architects for at least an hour.

Crispin's definition of a "moderately secure operating system": a
"moderately secure operating system" is one that would withstand
an attack by one of its architects for at least an hour even if
the management of the system are total idiots who make every
mistake in the book.
-------

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 02:26:02 EST
From:      kik@CERNVAX.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Response to anti-bridge comments


   I get the impression that, in the discussion  on  Bridge  functionality,
people  are  not taking enough trouble to distinguish between the *service*
and the *communications*.

   The service is to filter and  forward,  based  on  destination  address.
There  is  no reason for the filtering not to be shared, in a disjoint way,
by any number of devices.  In fact, we intend to do this.  The load-sharing
and backup algorithms are designed and we plan to implement them on our own
equipment once we get the time.

   The communications can be based  on  point-to-point  links,  satellites,
etc.  In  fact,  the  choice  of  communications  is  limited  only by your
networking ability.  For  example,  DEC  and  Vitalink  have  "invented"  a
spanning-tree  approach  to provide redundant communcation.  This is really
primitive.  We, at CERN, use a genuine communications subnet  with  all  of
the  build-in  advantages  (originally designed for inter-computer traffic,
and all the better for that!).  The ideal backbone for such purposes  would
be a high-speed bus-type network (we're hoping for FDDI).

    I am trying to rewrite the IEEE 802.1 document on MAC-level bridges  to
reflect the clear separation between
   a) address resolution and
   b) routing
so that the current confusion can be avoided.

          Cheers

               Crispin PINEY

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 04:42:26 EST
From:      Steve.Kille@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: GOSIP vs TCP/IP

Right.   X.25 on its own is not capable of end to end recovery.
I was just making clear that this is not a deficiency in X.25,
and that in the right combinations it is a sensible building block.

Steve

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 07:19:50 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Jordan, you are right in your assumptions that people will get annoyed
that what happened was allowed to happen.

By the way, I am the program manager of the Arpanet in the Information
Science and Technology Office of DARPA, located in Roslin (Arlington), not
the Pentagon.

I would like suggestions as to what you, or anyone else, think should be
done to prevent such occurances in the furture.  There are many drastic
choices one could make.  Is there a reasonable one?  Perhaps some one
from Sun could volunteer what there action will be in light of this
revelation.  I certainly hope that the community can come up with a good
solution, because I know that when the problem gets solved from the top
the solutions will reflect their concerns.

Think about this situation and I think you will all agree that this is
 a serious problem that could cripple the Arpanet and anyother net that
lets things like this happen without control.

dennis
-------

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Mon 6 Apr 87 07:19:50-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        jkh%violet.Berkeley.EDU@berkeley.edu
Cc:        hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: My Broadcast
Jordan, you are right in your assumptions that people will get annoyed
that what happened was allowed to happen.

By the way, I am the program manager of the Arpanet in the Information
Science and Technology Office of DARPA, located in Roslin (Arlington), not
the Pentagon.

I would like suggestions as to what you, or anyone else, think should be
done to prevent such occurances in the furture.  There are many drastic
choices one could make.  Is there a reasonable one?  Perhaps some one
from Sun could volunteer what there action will be in light of this
revelation.  I certainly hope that the community can come up with a good
solution, because I know that when the problem gets solved from the top
the solutions will reflect their concerns.

Think about this situation and I think you will all agree that this is
 a serious problem that could cripple the Arpanet and anyother net that
lets things like this happen without control.

dennis
-------
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 08:45:55 EST
From:      howard@cos.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Time RFC 868



Time synchronization has been a major issue in 
performance work.  Several lessons learned may help.

First, if at all possible, do not depend on a single
time of day "message," but iterate to get a sense
of path delay.

A technique developed jointly by the Commerce Department
(NBS Time Lab and Institute for Telecommunications Sciences)
and Bell Labs illustrates.  In this technique, assume
a master-slave relationship for time setting, initiated
by the slave.  The slave contacts one (or more) master
clock sites, and requests a download of the time of day.

So far, this is traditional.  However, the enhancement
takes place after the master sends its time of day:
the slave RETRANSMITS what it received.  The master
then calculates the difference (in time units) between
what it sent and what the slave received, and sends
that as a correction factor.  The slave then algebraically
adds this correction factor to its clock and retransmits the
new value.This process repeats until
the desired resolution is achieved.

The first implementation of this method was over the
AT&T dial network (there was one at the time).  It turns
out that the widely held belief that you cannot assume
equal delay on both sides of a dial call is FALSE, at
least for the AT&T routing plan.  They do not, for
example, assign one side to a terrestrial and one to
a satellite facility; both go in the same way.

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 08:56:50 EST
From:      Steve.Kille@CS.UCL.AC.UK.UUCP
To:        mod.protocols.tcp-ip
Subject:   NIFTP

This is just to expand a few details of Jon Crowcroft's note:

NIFTP (Network Independent File Transfer Protocol) may be of
some interest to the DARPA community, as it is currently more
widely available than FTAM.   There are a number of potential
advantages of ARPA FTP, as Jon pointed out:
   - Many implementations support resumptions
   - Spooled implementations are available
   - the single channel makes gatewaying rather easier

A copy of the protocol can be obtained from:
        ITSU
        Department of Trade and industry
        Kingsgate House
        66-74 Victoria Street
        London SW1

The protocol will operate over TCP/IP, and has assigned sockets:
        47 (straight NIFTP)
        61 (NIFTP + JNT Mail)

There are implementations for a wide range of machines.  A full
table of colured book implementations for the various machine
ranages can be obtained from Dr. Bob Cooper
<r.cooper@gec-b.rutherford.ac.uk> who runs the Joint Network Team.

A brief note on UNIX implementations, which I know are of
particular interest.   There is a JNT supported implemetnation,
which is available through Spider Systems.   Contact
Andy Davis <andy%spider@cs.ucl.ac.uk>.   However, this does
not support either TCP or resumptions.

There is another UNIX implementation, which is not supported
but is being assembled as a public domain package by
Cambridge/UCL/Nottingham.   This is a very full implementation
of the protocol, and has TCP/IP (4.2/4.3).  We believe that this system is
substantially better than the official one, but of course there
is no support.   We are currently doing testing as a
smallish group, but the system will be distributed in due course,
after it has been released to a number of beta sites.
If anyone is interested, contact <unix-niftp@cs.nott.ac.uk>.
Do NOT send messages to mailgroup@cs.ucl.ac.uk, as suggested by Jon.


Steve

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 09:16:00 EST
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: multicast groups on ether

As I think some people have already tried to state, ** There is now
standard for multicast addressing **.  The only thing the blue Ethernet
book says is that multicast addresses exist and here's what they look
like.  It does not say what functinality implementors of hardware
interfaces should provide.  It doesn't give any hints if implementations
should allow filters on the top 24 bits, or the bottom 8 bits, or
anything.  Therefore, what Interlan does is different than what 3Com
does which is different than what DEC does which is different.... 
Please don't go inventing ideas that work well on only one type of
interface.

I also suggest people separate network level packets like ARP from
protocol like packets like RWHO, TFTP and Time.  They are very different
and you may find that the "solution" for each is different.

I'm against adding IP-specific things to the handling of ARP.  ARP is
blatently non-IP specific (non-anything specific for that matter) and I
fear putting in non-modular hooks between the layers will burden
multi-protocol operatins systems at the expense of single-protocol
systems.  Additionally, it isn't easy to extend ARP to be Ethernet
specific (e.g., have ARP-for-IP and ARP-for-CHAOS) since ARP doesn't
know anything about Ethernet nor about IP and wouldn't know what to do
if you told it.

I conjecture that if there are excessive ARP packets on your cable, than
one of two things is happening: Some station's cache isn't big enough
(simple enough to solve), or some station isn't responding.

XNS, Pup and Chaos routing present a constant (though supposedly
low frequency) stream of broadcast packets.  Multicast would probably be
a good thing here, if we could figure out how multicast should work.

RWho in my opinion should be flushed.  It is an unsolicited
user-level protocol.

Time is (or should be) a solicited user-level protocol.  I'd be
surprised if it really caused excessive burden.

Domain Name lookups are broadcast?  New one on me.

How often does BOOTP really happen?  If the BOOTP protocol isn't able to
latch on to the server address directly, I suggest the BOOTP protocol be
changed to do so.  A PDP-11 netboot protocol I wrote 5 years ago did
indeed broadcast the initial request and then latched onto the server.
Everybody is burdened with one, perhaps two, packets and then never
hears from the booter again.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 11:27:52 EST
From:      jkh@VIOLET.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Dennis,

Sorry about the mixup on your location and position within DARPA. I got
the news of your call to Richard Olson second hand, and I guess details
got muddled along the way. I think the best solution to this problem (and
other problems of this nature) is to tighten up the receiving ends. Assuming
that the network is basically hostile seems safer than assuming that it's
benign when deciding which services to offer.

I don't know what Sun has in mind for Secure RPC, or whether they will move
the release date for 4.0 (which presumably incorporates these features)
closer, but I will be changing rwalld here at Berkeley to use a new YP
database containing a list of "trusted" hosts. If it's possible to change
RPC itself, without massive performance degradation, I may do that as well.

My primary concern is that people understand where and why unix/network
security holes exist. I've gotten a few messages from people saying that
they would consider it a bug if rwall *didn't* perform in this manner, and
that hampering their ability to communicate with the rest of the network
would be against the spirit of all it stands for. There is, of course, the
opposite camp which feels that IMP's should only forward packets from hosts
registered with the NIC. I think that either point of view has its pros and
cons, but that it should be up to the users to make a choice. If they wish
to expose themselves to potential annoyance in exchange for being able to,
uh, communicate more freely, then so be it. If the opposite is true, then
they can take appropriate action. At least an informed choice will have been
made.

		Yours for a secure, but usable, network.

					Jordan Hubbard

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 11:36:56 EST
From:      PALLAS@SUSHI.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

I see that, as usual, Mark Crispin has tried to turn a constructive
discussion into a diatribe against Unix.  If there's a point to his
flame, however, it escapes me.  It does bear an entertaining
resemblance to some conspiracy theories I've heard, I must admit.

    Crispin's definition of a "somewhat secure operating system":
    A "somewhat secure operating system" is one that, given an
    intelligent system management that does not commit a blunder that
    compromises security, would withstand an attack by one of its
    architects for at least an hour.

"You stupid fool, who told you to turn the damn thing on?!?"

    Crispin's definition of a "moderately secure operating system": a
    "moderately secure operating system" is one that would withstand
    an attack by one of its architects for at least an hour even if
    the management of the system are total idiots who make every
    mistake in the book.

The first mistake in the book is to believe that the security of the
operating system implies the security of the data, or rather that the
system is an isolated entity which can be made "secure" independent of
its environment.

joe
-------

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 12:25:44 EST
From:      GS@DEEP-THOUGHT.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Case Studies/Information needed


Could someone provide pointers to recent papers or studies
addressing implementation concerns of large local area networks
using TCP/IP to communicate between 10-100 VAXes (or other
larger-than-workstation system) and 1000-10,000 standalone workstations
(PCs to Suns)?  I would be particularly interested in experiences
with unix, VMS or unix/VMS environments.  The kind of information I
am looking for is the DOs and DON'Ts of the architecture design and
any tradeoffs that must be considered.

I have a few naive questions also.  Does performance of the network
degrade as the number of hosts increases (independent of the amount of
traffic)?  Does the number of hosts defined in the namespace play 
a part?  Can a large local area system cause a degradation in
performance of a larger group (other intenet sites not in the local
area)?  

Any information would be appreciated.  Please respond directly
as I am not a regular reader of this list.

Gordon Strong
gs%ee@mit-xx (Arpa)
gs@mit-eddie (uucp)
-------

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 12:35:16 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Well,  Looks like we have (re)uncovered a can of mixed worms here.
The example I gave was definitely in the "security" area and you
should note that the method used to get it fixed involved exactly
one "outside site", the site of the author of the operating system.

The example of the broadcast that went "astray" is more accurately
described as an "integrity" issue.  With integrity one is concerned
that the "system/facility" stay alive and functional under both
normal use and many forms of abnormality.  What we are learning
with some of the facilities for message sending is that our
"internet" is very highly connected and even can be considered
to be too highly connected for some forms of (even innocent)
misbehavior.  How do we benefit from what we have learned thus far?

Dennis has suggested that one of the manufacturers fix some code
and/or defaults and/or procedures in its releases.  I'm sure other
manufacturers can do likewise should they also exhibit the
same misfeatures in their offerings.  But the big thing that we
need to understand is that we do not understand how to live
in these highly connected internets yet.  Much more research needs
to happen in the area of intergroup interactions.  And much more
tolerance needs to be exhibited towards those who are probing
the edges of all this.

Dan
-------

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 1987 12:35:16 EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Rudy.Nedved@H.CS.CMU.EDU
Cc:        Dan Lynch <LYNCH@A.ISI.EDU>, hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: My Broadcast
Well,  Looks like we have (re)uncovered a can of mixed worms here.
The example I gave was definitely in the "security" area and you
should note that the method used to get it fixed involved exactly
one "outside site", the site of the author of the operating system.

The example of the broadcast that went "astray" is more accurately
described as an "integrity" issue.  With integrity one is concerned
that the "system/facility" stay alive and functional under both
normal use and many forms of abnormality.  What we are learning
with some of the facilities for message sending is that our
"internet" is very highly connected and even can be considered
to be too highly connected for some forms of (even innocent)
misbehavior.  How do we benefit from what we have learned thus far?

Dennis has suggested that one of the manufacturers fix some code
and/or defaults and/or procedures in its releases.  I'm sure other
manufacturers can do likewise should they also exhibit the
same misfeatures in their offerings.  But the big thing that we
need to understand is that we do not understand how to live
in these highly connected internets yet.  Much more research needs
to happen in the area of intergroup interactions.  And much more
tolerance needs to be exhibited towards those who are probing
the edges of all this.

Dan
-------
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 13:27:44 EST
From:      robert@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

>> 						..... we must
>> entrust our systems and data to a open-ended set of youthful
>> hackers (the current term is "gurus") who have mastered the
>> arcane knowledge.

	Only because these 'youthful hackers' are the only ones
	willing (or having the time) to look for the problems
	they discover.
>> 
>>    ....
>> 
>>   Knowledge is power, and it properly belongs in the hands of
>> system administrators and system programmers.  It should NOT be
>> the exclusive province of "gurus" who have a vested interest in
>> keeping such details secret.

	Mark,

	I agree that system administators should have the know-how
	to protect their systems.  However I have not seen the
	concerted effort of gurus to keep security problems
	secret from the administors.  Rather I have seen administrators
	keeping such holes secret from the users, and then complaining
	when the users discover and use them.

>> 
>> -- Mark --
>> 
>> PS: Crispin's definition of a "somewhat secure operating system":
>> A "somewhat secure operating system" is one that, given an
>> intelligent system management that does not commit a blunder that
>> compromises security, would withstand an attack by one of its
>> architects for at least an hour.

	...except for the case where one has physical access to
	the hardware.

Robert Allen,
robert@spam.istc.sri.com

Disclaimer: I am not a guru, and I don't advocate breakins, but if a
	    feature is there (such as telnet port 25), and is used,
	    I think that the administrators should share responsibility
	    with the user for any problems that result.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 13:34:01 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Dan,

My two areas of frustration are abuse of mail resources and abuse of
network resources. Each year people, send mail to as many mailing lists
as they can asking to be put on them instead of the request list. Several
times a year, someone configures a mailer to cause a huge loop that causes
many megabytes of mail messages to be sent to many people on many different
systems. At least once year, I see a piece of code written under the
assumption that the network is a quiet high-speed high-relaibility
medium -- the code retransmits quickly and has very short timeouts.

Lastly, we have several systems that take a list of hosts and broadcast
messages to them to update databases. This is in the similiar flavor
of grapevine. It is not unlikely that some company could set up a
system and want a broadcast facility similiar to the one that started
up this discussion. At this point, it is no longer a security problem
but a feature.

If I had concrete improvements that I could implement, I would act on them.

Maybe the system will change to charge for mail and to charge for network
access and usage. People would then be more responsive to their utilization
of those resources.

-Rudy

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 14:01:09 EST
From:      faustus@IC.BERKELEY.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  My Broadcast

What type of security are we really taking about, anyway?  Military security?
If so, maybe it's better that there are well-known loopholes so that nobody
places too much faith in their system and makes use of techniques like
public-key encryption when it really matters.  No matter how secure your
network and OS is, if you assume that it's ok to rely on their security alone
for very sensitive data, you'll get burned sooner or later.  It's much
safer to assume the worst and take proper precautions.

	Wayne

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 14:12:34 EST
From:      robert@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

>> Whoa!
>> 
>> Encouraging people to find holes and then use them to make the local system
>> programmers work on them is wrong. It is like encouraging people to find out
>> if their neighbors lock their door during the day so they will. Do you really
>> want that or do you want the theives to be caught? I want the theives to be
>> caught and the ability to leave my door open. I don't want to fear my
>> neighborhood or my users.

While this doesn't deal directly with TCP-IP, it is a *very* important
consideration in the Internet in particular, and any network in general.

Often a so-called 'breakin' does not even require that a user maliciously
"try their neighbors doors" to see if they can gain restricted permissions
or access.  Often curiosity alone is enough to cause problems. Example 1:
a first-time UNIX user was learning about the file system, and in particular
how to delete files.  He was told that he could only delete files owned by
him, and by way of counterexample his mentor typed "rm /etc/passwd".
Surprise, /etc was writeable and the file was gone.  Example two: the recent
rlogin breakins at Stanford.  Example 3: Obviously if you have hardware
access to the transmission medium you can unintentionally wreak havoc merely
by using someone elses IP address.

I too would like to live in a word where I can leave my "door unlocked".
Unfortunately it doesn't take more than a very few nasty or ignorant persons
to cause problems.  Due to the fact that computers have evolved in an
atmosphere of sharing (time sharing, memory sharing, src sharing..)
we have yet to realize the responsibilities and risks of trusting them too
much.  I.e., there is a big difference between leaving your door
unlocked but closed, and spreading $20.00 bills on your front lawn.
In the case of J. Hubbards 'wall' to the Net, the problem was not
caused by a malicious person, but by simple curiosity.

At the recent TCP/IP Conference in Monterey CA, some discussion was
given to "network security".  From the military standpoint they want
the ability to send data through a network, such that anyone who
captures the data won't be able to read or use it.  While this may
be a prerequisite for the military, I don't think that 'normal' users
should expect that their Email be any more secure than their USMail.
The best method of keeping something secure on a network is to physically
seperate it.  Or, do what I do, and don't put anything on the system
which you wouldn't read by someone else under the worst case scenario.

Fixing security 'features' is obviously important, and should be pursued.
Catching malicious persons doing damage is also extremely important.  But
"catching the theives" is not the answer to a lack of network security.
If your network rolls out a red-carpet to someone then don't be surprised
if you find muddy footprints on it the next morning.  I leave you with
two examples quoted from the January 1987 issue of the ACM Software
Engineering Notes...

	"The computer security administrator at Roche ... had been
	 plagued by a hacker who auto-dialed the entire Roche phone
	 system in sequence.  .... They laid a hacker trap on one of
	 the PC's and traced the call.  Once the suspect was found,
	 it was even harder to get him arrested since he was in
	 New York, and Roched in New Jersey (which got the FBI involved).
	 The perp was brought into the police station and had the riot
	 act read to him...  He was not charged -- because there wasn't
	 a **no-trespassing** sign on the hacker trap identifying the
	 system as private proberty of Roche."

	 " "Welcome to the ______ System" ... A Mass. financial firm
	  that had attempted to prosecute a hacker who had penetrated
	  their system.  The defense lawyer argued that the system had
	  a greeting that welcomed people to the system, and that was 
	  tantamount to welcoming someone intor your home.  The judge
	  threw out the case, accepting the arguments of the defense.."

Robert Allen,
robert@spam.istc.sri.com

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 14:14:08 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   My Broadcast


Mark Crispin --

I think your attack on UNIX is utterly unwarranted and devoid of
content. How you can compare it to ITS where everyone was effectively
a wheel is utterly beyond me.

UNIX exhibits no worse characteristics than other commonly used
systems. Even your beloved TOPS-20 had this charming feature of
unencrypted passwords so anyone gaining access to a priviliged
terminal for a few seconds could print every pwd on the system in
clear text with one command. Sure, that's fixed, but the fix came
recently, after DEC had dumped the product. We had to live with this
for years (and show me the local hack patches that "fixed" this and
I'll show you the local hack patches that fix any UNIX security flaw
you see.)

For the love of god Mark, Jordan broadcast a message to a lot of terminals.

That's it.

BFD, sure it could be annoying, but the originating site (and user,
although I admit that could be faked easily) was clearly printed and
easily (see etherfind for example) identified. To say your "systems
and data" were endangered by this broadcast is hyperbole, at best.

Can you condemn the entire UNIX operating system because a user was
able to SHOUT to a bunch of hosts he didn't own? Sounds flimsy to
me.

As to "muzzling" of unix security problems, there's an entire, active
mailing list on the internet devoted to nothing but discussing UNIX
security issues. What other operating system can claim this? (Ok,
these things are also freely discussed on some of the TOPS-20 lists,
no argument, but name another? I've seen this stuff specifically
stifled and people severely flamed on at least one other O/S's list.)

	-Barry Shein, Boston University

P.S. One thing I do agree with Mark about is that without the sources
you might be a sitting duck. This is one major reason I discourage
people from buying VMS.

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 14:29:03 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   My Broadcast


From Dennis Perry:
>I would like suggestions as to what you, or anyone else, think should be
>done to prevent such occurances in the furture.

Solution:

Edit /etc/servers and remove the rwalld line. This will disable the
remote service. The local "write to all users" program, 'wall', can
still be used on any individual system. To shout to all systems in an
area either have the operators log in and run wall locally or execute
it via 'rsh system wall ..msg..' from a locally trusted site (as per
the rsh restrictions.) A command file could be created trivially which
simulated "rwall" to a selected set of sites:

#!/bin/sh
echo "Enter message to be sent to all systems (one line)"
echo -n 'MESSAGE: '
read msg
for i in host1 host2 etc...
do
	rsh $i wall $msg
done

(I didn't test this, but I think the point is clear.)

This can be further enhanced by removing the rwall binary from your
systems, but if you don't support the daemon, you're not going to see
any broadcasts, so it's under your control. Done.

	-Barry Shein, Boston University

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 14:43:19 EST
From:      chris@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: New source for Imagen laser printer memory boards.


Original message.
-----------------
>>	I, recently had the oppertunity to evaluate a memory board for
>>the Imagen IP/II processors.  Since this is the first I had heard of an
>>alternative source for Imagen memory I thought I'd share the info with 
>>the net.  The company's name is Kortex Systems and in case you want to
>>contact them their phone numbers are (415)-961-4411 or (415)-969-4053.
>>They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board
>>in our 8/300 and our 3320 Imagen printers, both printers sit on our 
>>local ether net.  In the past large jobs (100+ pages) would come out 
>>in reverse order and you would have to collilate the pages manually, 
>>with the 4 meg board in the system I couldn't find a listing large enough 
>>to use up all of the memory.  We used the board in both systems for a
>>week and saw no problems with it. The 4 Meg board retails for $1795 with 
>>discouts for non-profit and educational groups.  The last time I checked
>>the largest board Imagen sold was a 3 Meg one and it was going for $1900.
>>
>>						Chris

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

	Several folks have asked me for Kortex Systems address and 
pointed out that I had several typo's and misspelled words in my first
message.  Kortex System's address is:  1561 Elmhurst Dr. Los Altos, CA
94022.  Below is a corrected version of my earlier message, please note 
that the 4 meg board is listed for $1900 not $1795. Sorry for the erroneous 
information in my earlier note.
	
-----------------------------------------------------------------------------

	I recently had the opportunity to evaluate a memory board for
the Imagen IP/II processors.  Since this is the first I had heard of an
alternative source for Imagen memory I thought I'd share the info with 
the net.  The company's name is Kortex Systems and in case you want to
contact them their phone numbers are (415)-961-4411 or (415)-969-4053.
They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board
in our 8/300 and our 3320 Imagen printers, both printers sit on our 
local ethernet.  In the past, large jobs (100+ pages) would come out 
in reverse order and you would have to collate the pages manually. 
With the 4 meg board in the system I couldn't find a listing large enough 
to use up all of the memory.  We used the board in both systems for a
week and no problems were encountered.  The 4 Meg board retails for $1900 
with discounts for non-profit and educational groups. For more information
please contact the folks at Kortex Systems, I have no association with the
company.

						Chris

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 14:49:02 EST
From:      budd@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   ICMP redirect caching

I agree that BSD would be better off if the networking code took a
more active (and reality based) interest in the health of its routing
tables.  Like some frail monarch hidden in its chambers it has too
long listened to the half truths of its wormtongued routing daemon.

TENEX/TOPS-20 use caching of ICMP Redirect derived routes.  The
"default" gateways are statically assigned.  Perhaps an initial
broadcast request could be used to dynamically build a weighted list
of possible gateways when the current set is empty (or contains only
reticent redirectors).

Another valuable concept is the (sparing) use of pinging to ascertain
the health of the default and active (catched) gateways.

The file [NIC]NETINFO:INTERNET.PINGING contains information regarding
the care and feeding of your GATEWAYS file.

	Phil Budne, Boston University

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 15:17:26 EST
From:      rfradenb@CCV.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Addition To Mailing List

Please add my name to the mailing list for this newsgroup.

Thank you.

Roger Fradenburgh (rfradenb@ccv.bbn.com)

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 16:04:35 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Jordan, thanks for the note.  I agree that we should discover and FIX holes
found in the system.  But at the same time, we don't want to have to
shut the thing down until such a fix can be made. Misuse of the system
get us all in a lot of trouble.  The Arpanet has succeeded because of
the self policing community. If this type of potential for disruption
gets used by very many people, I guarentee that we all will not like the
solution or fix proposed.

dennis
-------

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Mon 6 Apr 87 16:04:35-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        jkh%violet.Berkeley.EDU@berkeley.edu
Cc:        PERRY@vax.darpa.mil, jkh@violet.berkeley.edu, hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: My Broadcast
Jordan, thanks for the note.  I agree that we should discover and FIX holes
found in the system.  But at the same time, we don't want to have to
shut the thing down until such a fix can be made. Misuse of the system
get us all in a lot of trouble.  The Arpanet has succeeded because of
the self policing community. If this type of potential for disruption
gets used by very many people, I guarentee that we all will not like the
solution or fix proposed.

dennis
-------
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 16:11:59 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Barry, thanks for your suggestion.  Seems to me like a good solution
to start with, i.e. where we trust the users to implement the fix.
Ultimately, we have to build a network that will protect itself somehow.

Can I ask all you out there to implement such a scheme or any better one
that may come out of this discussion.

Thanks,
dennis
-------

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Mon 6 Apr 87 16:11:59-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        bzs@bu-cs.bu.edu
Cc:        PERRY@vax.darpa.mil, jkh%violet.Berkeley.EDU@ucbvax.berkeley.edu, hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: My Broadcast
Barry, thanks for your suggestion.  Seems to me like a good solution
to start with, i.e. where we trust the users to implement the fix.
Ultimately, we have to build a network that will protect itself somehow.

Can I ask all you out there to implement such a scheme or any better one
that may come out of this discussion.

Thanks,
dennis
-------
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Apr 87 16:17:26 AST
From:      Roger Fradenburgh <rfradenb@ccv.bbn.com>
To:        tcp-ip@sri-nic.ARPA
Cc:        rfradenb@ccv.bbn.com
Subject:   Addition To Mailing List
Please add my name to the mailing list for this newsgroup.

Thank you.

Roger Fradenburgh (rfradenb@ccv.bbn.com)
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6 Apr 87 22:43:47 MST
From:      John B. Nagle <jbn@glacier.stanford.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   NFS security
       Quit worrying about "rwall".  All one can do with that is annoy
people.  Worry about Sun NFS and Berkeley RLOGIN, both of which assume
that hosts are "good guys".  Consider the following:

     If you have the means to impersonate any host by setting an interesting
number in your source IP address, and can see the replies coming back,
you can access any remotely accessable file on any NFS server.  If you are
on the same LAN, this is trivial; otherwise it may take some eavesdropping
or gateway tampering to bring it off.  Note, by the way, that large networks
constructed with low-level bridges are especially vulnerable to this type
of attack.  (This is not to be construed as an argument that IP routers
provide some kind of security).  With the advent of PC-based NFS clients,
NFS break-in can be accomplished with low-cost hardware and requires minimal 
technical sophistication.

      NFS is useful.  NFS is clever.  NFS is efficient.  NFS works.  NFS
has security holes though which one could drive an armored division.  Don't
blame Bill Joy; he's the one who insisted that SUN machines have sockets for
DES chips.  However, DoD's export controls on cryptographic equipment
discourage the use of crypto hardware in commercial equipment.  So the
socket is invariably empty.  DoD has shot itself in the foot on this one.

					John Nagle


-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Mon, 6-Apr-87 22:09:03 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Dan, you are right in one point, anyway.  That is we need to explore the
issues of intergroup interaction.  But, like any society where our
collective well being depends upon the behavior of others outside
our control, we need to be sensitive on how we explore the edges of these
interactions.  I posit that this should take place in a controlled 
experiment that maximizes the benefits and minimizes the disruptions.

After all, the Arpanet is still an 'experimental' network.  Let's plan
our experiments, rather than just letting them happen.

dennis
-------

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Mon 6 Apr 87 22:09:03-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        LYNCH@a.isi.edu
Cc:        Rudy.Nedved@h.cs.cmu.edu, hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: My Broadcast
Dan, you are right in one point, anyway.  That is we need to explore the
issues of intergroup interaction.  But, like any society where our
collective well being depends upon the behavior of others outside
our control, we need to be sensitive on how we explore the edges of these
interactions.  I posit that this should take place in a controlled 
experiment that maximizes the benefits and minimizes the disruptions.

After all, the Arpanet is still an 'experimental' network.  Let's plan
our experiments, rather than just letting them happen.

dennis
-------
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 00:43:47 EST
From:      jbn@GLACIER.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   NFS security


       Quit worrying about "rwall".  All one can do with that is annoy
people.  Worry about Sun NFS and Berkeley RLOGIN, both of which assume
that hosts are "good guys".  Consider the following:

     If you have the means to impersonate any host by setting an interesting
number in your source IP address, and can see the replies coming back,
you can access any remotely accessable file on any NFS server.  If you are
on the same LAN, this is trivial; otherwise it may take some eavesdropping
or gateway tampering to bring it off.  Note, by the way, that large networks
constructed with low-level bridges are especially vulnerable to this type
of attack.  (This is not to be construed as an argument that IP routers
provide some kind of security).  With the advent of PC-based NFS clients,
NFS break-in can be accomplished with low-cost hardware and requires minimal 
technical sophistication.

      NFS is useful.  NFS is clever.  NFS is efficient.  NFS works.  NFS
has security holes though which one could drive an armored division.  Don't
blame Bill Joy; he's the one who insisted that SUN machines have sockets for
DES chips.  However, DoD's export controls on cryptographic equipment
discourage the use of crypto hardware in commercial equipment.  So the
socket is invariably empty.  DoD has shot itself in the foot on this one.

					John Nagle

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 00:55:34 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Time RFC 868

Howard,

I would like to recommend RFC-958 and the references cited there as input
to this work. A reasonable volume of swampslush has washed under the keel
of the DARPA Internauts in the area of time synchronization.

Dave

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 02:24:27 EST
From:      mike@BRL.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  ICMP As A Diagnostic Tool?

BRL uses the "ping" program, which transmits ICMP Echo Request packets
with the data field set to a process ID, a sequence number, and
a struct timeval (time in seconds and microseconds), plus patterns
to pad out any extra length (a command-line parameter).

[The BRL ping program is now provided as /etc/ping in 4.3 BSD UNIX].

We use this tool for network troubleshooting *extensively*.
Many Lab managers even know how to run PING, so that they can
get more information about why connections to far-away hosts
may be working poorly.

We also have a tool (PINGPOLL) that we use (within the campus net only)
to monitor round-trip-times and packet loss, as well as a very simple
ICMP-based routing daemon (ROUTER).

ICMP is invaluable -- it provides a level of visibility of activity
at the link level that is very helpful.

Oh yes, another good use to to watch the effects of varying packet
size.  Good for finding IP reassembly bugs (in days gone by), and
various interesting performance problems (back-to-back etherpackets, etc).

The "ping -f" (aka FLOODPING) option is very good for stress-testing
a particular network, gateway, host, whatever.  As the name suggests,
it releases ICMP echo request packets as fast as it can.

Another version of PING that we have uses the IP option "record route",
which is useful to see where the packets are traveling.

Very useful, and amusing to watch.

	Best,
	 -Mike

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 05:25:44 EST
From:      HANK@TAUNIVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Introduction to Tcp/Ip

Can anyone refer me to an RFC or some other online document that gives
a good overview of Tcp/Ip - how it is built, what protocols it uses,
etc.  Basically a good comprehensive 30-page overview of the whole
Tcp/Ip system.  Please answer directly to me and if you have something
that you wrote up that is not available publically, feel free to send
it to me.

Thanks in advance,
Hank

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 05:38:41 EST
From:      HANK@TAUNIVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Access control and accountability

I have a feeling this posting might generate quite a bit of
philosphical talk - but I would like to request in advance that I am
not interested in feelings and/or emotions but rather technical solutions.

With that behind me I would like to know about solutions in Tcp/Ip for
the following two areas:

1) Access control:
   A) On a system level: How do I go about restricting the use of users
      from using Tcp/Ip?  I realize that every operating system may have
      a different solution but I am interested in hearing concepts and
      whether anyone is actually doing it.
   B) On a gateway level: If I have a gateway (say something like Bridge
      or cisco) do I have any capability of performing any sort of access
      control?  If yes, is this access control based on connected machines
      or can I even exercise access control on a user level (i.e. restrict
      FTP or TELNET to a certain group of users on a certain machine).

2) Accounting:
   A) System level: Is there any accounting package that can measure things
      like packet transfer (FTP always tells you how many Kb/sec you sent
      so it isn't impossible to figure out) levels and Telnet connect time?
   B) Gateway level: Is there some gateway or monitoring PC that can do
      accounting?  Is the accounting per system or can it be broken down
      per user (I assume very difficult to do)?

As a side note, anyone who is up on ISO: what is the status of accounting
and access control in ISO?  Has it even been thought of?

Thanks in advance,
Hank

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 07:42:27 EST
From:      galvin@dewey.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast


	From:     Robert Allen <robert@spam.istc.sri.com>

	I don't think that 'normal' users should expect that their
	Email be any more secure than their USMail.

I don't buy this.  Why should we restrict or constrain current technology
based on what we are used to?  There is no reason that electronic mail can't
be more secure than USMail.  Isn't it self-defeating to assume otherwise?

	From:     Rudy.Nedved@h.cs.cmu.edu

	Encouraging people to find holes and then use them to make the
	local system programmers work on them is wrong. It is like
	encouraging people to find out if their neighbors lock their
	door during the day so they will. Do you really want that or do
	you want the theives to be caught? I want the theives to be
	caught and the ability to leave my door open. I don't want to
	fear my neighborhood or my users.

This analogy doesn't hold in the internet (small i intended).  It is not your
neighbors you are worried about.  You can live in a "friendly" network just
like you can live in a "friendly" neighborhood.  The problem is, your friendly
network is a great deal "closer" to the unfriendly ones than your friendly
neighborhood is close to unfriendly ones.

Isn't this what Dan Lynch meant when he said:

	From: Dan Lynch <LYNCH@a.isi.edu>

	What we are learning with some of the facilities for message
	sending is that our "internet" is very highly connected and
	even can be considered to be too highly connected for some
	forms of (even innocent) misbehavior.  How do we benefit from
	what we have learned thus far?

	... But the big thing that we need to understand is that we do
	not understand how to live in these highly connected internets
	yet.  Much more research needs to happen in the area of
	intergroup interactions.  And much more tolerance needs to be
	exhibited towards those who are probing the edges of all this.

Jim

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 07:58:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:      Access control and accountability


Hank,

Little has been developed for access control and accounting. Some gateways
(e.g. BBN?) can filter IP packets based on source/destination address.
I don't know of any which filter with knowledge of the protocol being used.

I do not know of any gateways that provide accounting data, although such
information as packet counts from a given host can be obtained from,
e.g. the ARPANET. I would not be surprised to hear that some gateways and
even some bridges keep some statistics about traffic loads, but probably
not by source or destination.

Thus far, the TCP/IP software has gone into private or gov't-owned systems
which have not demanded much inthe way of accounting (or of access control).

Vint 

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 09:36:03 EST
From:      hoey@NRL-AIC.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Mailbridge homings


    Date: Mon, 6 Apr 87 15:49:02 EDT
    From: budd@bu-cs.bu.edu (Philip Budne)
    To: tcp-ip@nic.sri.com
    Subject: ICMP redirect caching

    ... The file [NIC]NETINFO:INTERNET.PINGING contains information
    regarding the care and feeding of your GATEWAYS file.

	Phil Budne, Boston University

At the end of that file is a copy of DDN MGT Bulletin 23, dated 29 Aug
1984.  If you are (as I was last month) using it to find out your
mailbridge homing, you should read either
	[NIC]NETINFO:ARPA-MAILBRIDGE-HOMINGS.TXT, or
	[NIC]NETINFO:MIL-MAILBRIDGE-HOMINGS.TXT
depending on which side of the mailbridges you use.

KLH, or NETINFO maintainer:  Please note these filenames at the end of
INTERNET.PINGING, and maybe even remove the outdated mailbridge list.

Dan Hoey

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1987 09:36:03 EST (Tue)
From:      Dan Hoey <hoey@nrl-aic.ARPA>
To:        budd@bu-cs.bu.edu (Philip Budne), tcp-ip@sri-nic.arpa
Cc:        SUGGESTIONS@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA
Subject:   Mailbridge homings
    Date: Mon, 6 Apr 87 15:49:02 EDT
    From: budd@bu-cs.bu.edu (Philip Budne)
    To: tcp-ip@nic.sri.com
    Subject: ICMP redirect caching

    ... The file [NIC]NETINFO:INTERNET.PINGING contains information
    regarding the care and feeding of your GATEWAYS file.

	Phil Budne, Boston University

At the end of that file is a copy of DDN MGT Bulletin 23, dated 29 Aug
1984.  If you are (as I was last month) using it to find out your
mailbridge homing, you should read either
	[NIC]NETINFO:ARPA-MAILBRIDGE-HOMINGS.TXT, or
	[NIC]NETINFO:MIL-MAILBRIDGE-HOMINGS.TXT
depending on which side of the mailbridges you use.

KLH, or NETINFO maintainer:  Please note these filenames at the end of
INTERNET.PINGING, and maybe even remove the outdated mailbridge list.

Dan Hoey
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1987 08:58-EDT
From:      CERF@A.ISI.EDU
To:        Hank%BARILVM.BITNET@WISCVM.WISC.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:      Access control and accountability

Hank,

Little has been developed for access control and accounting. Some gateways
(e.g. BBN?) can filter IP packets based on source/destination address.
I don't know of any which filter with knowledge of the protocol being used.

I do not know of any gateways that provide accounting data, although such
information as packet counts from a given host can be obtained from,
e.g. the ARPANET. I would not be surprised to hear that some gateways and
even some bridges keep some statistics about traffic loads, but probably
not by source or destination.

Thus far, the TCP/IP software has gone into private or gov't-owned systems
which have not demanded much inthe way of accounting (or of access control).

Vint 
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 11:40:52 EST
From:      don@SRI-LEWIS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  My Broadcast


Just an interested bystander here,

Perhaps the fundemental difference in UNIX versus most other operating
system is that the basic user has to get so much more intimate with the
command set. In addition a goodly number of these users are writing software
that requires them to, at some point in time, have a hook or two into 
the workings of the operating system.

Also one must remember that the abilities/capabilities of one to cross
mount entire file systems is a FEATURE, not a quirk.

Believe me, when the feds come crashing through your bedroom window
and sieze your equipment you will know you shouldn't have been doing
what you were doing.

TIA, (That Is All)
Don

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 12:59:42 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Access control and accountability

Hank,  On the "system" side is is entirely up to the operating system
that runs the hardware interface to the network.  I have worked on a system
that did enforce access controls on a per user basis to the network
interfaces that were attached to it.  Since the operating system
allready had a strong notion of access control it was not dificult
to add in the support for network access.  But, it certainly is true
that we needed the source code to everything in sight to
make it all happen.  

The early days of networking had a notion of what it was that 
was being hooked up to the netowrk:  a timesharing system with a
responsible adminstration ensuring some kind of access restrictions
or at least a place to call to register a complaint.  Today's
technological advances have made is so that everyone on earth
is a "timesharing system administrator".  Clearly the
"responsibility" for hooking up to the network has to be placed
elsewhere.  The owner of the "cable" is teh obvious choice,
but that does not take into account radio based networks...

IN short:  It looks like the "gateway owners" are going to
have to become the administrators of the future!  Yikes, back
to the future???

Dan
-------

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 13:37:11 EST
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   How big is big?

I am doing some routing research which requires that I predict the
performance of a new sort of routing hierarchy for networks of
virtually unlimited numbers of nodes.  I need to also state the
diameters of these large networks.  I am therefore curious as
to what people think the diameter of very large networks will be.
For those who care to consider it, then, please make a guess at the
following:

What should be the diameter of networks with
	10,000 nodes?
	100,000 nodes?
	1,000,000 nodes?

Rules:
1.  A node is a switching point, such as an IMP or a gateway.  Hosts don't
    count (DEC people call hosts nodes).
2.  Consider any single piece of transmission as a hop.  This includes
    Ethernets, single wires, and a single satellite hop, but does not
    include transit through a DDN or even bridged Ethernets.
3.  This does not include ALL connectivity, only connectivity that can
    be used for transit routing.  For instance, we at MITRE have both
    a MILNET and an ARPANET connection two machines on the same Ethernet.
    However, since we do transit traffic between the two, we cannot be
    considered a hop.  (Actually, this third point is a little tricky,
    since physical connectivity can be blocked in many ways at many levels,
    and in different ways for different users.
    People may answer the question assuming both physical and logical
    connectivity if they wish.  I just happen to be more interested in
    logical connectivity.)
4.  ANSWER TO ME DIRECTLY.  Do not answer over the interest list.  I
    don't want people's guesses to be biased by other guesses they have
    seen.  I will post a summary of this (assuming I get any interest)
    in a few days.
5.  Prizes for most accurate guesses will be awarded.  First prize is
    full veto power over all ISO and CCITT standards.  Second prize is
    AT&T long lines and 1000 fuzzballs.  Third prize is AT&T long
    lines and 2000 fuzzballs.  Prizes will be awarded when the actual
    diameters of said networks are discovered.



	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 14:39:10 EST
From:      NJG@CORNELLA.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

>As to "muzzling" of unix security problems, there's an entire, active
>mailing list on the internet devoted to nothing but discussing UNIX
>security issues. What other operating system can claim this? (Ok,
>these things are also freely discussed on some of the TOPS-20 lists,
>no argument, but name another? I've seen this stuff specifically
>stifled and people severely flamed on at least one other O/S's list.)
I couldn't resist:
The VM Group of the IBM user's group SHARE has a conferencing system
(VMSHARE) which has an on going discussion of security problems.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 1987 13:59:42 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Henry Nussbacher <Hank%BARILVM.BITNET@WISCVM.WISC.EDU>
Cc:        <tcp-ip@SRI-NIC.ARPA>, LYNCH@A.ISI.EDU
Subject:   Re: Access control and accountability
Hank,  On the "system" side is is entirely up to the operating system
that runs the hardware interface to the network.  I have worked on a system
that did enforce access controls on a per user basis to the network
interfaces that were attached to it.  Since the operating system
allready had a strong notion of access control it was not dificult
to add in the support for network access.  But, it certainly is true
that we needed the source code to everything in sight to
make it all happen.  

The early days of networking had a notion of what it was that 
was being hooked up to the netowrk:  a timesharing system with a
responsible adminstration ensuring some kind of access restrictions
or at least a place to call to register a complaint.  Today's
technological advances have made is so that everyone on earth
is a "timesharing system administrator".  Clearly the
"responsibility" for hooking up to the network has to be placed
elsewhere.  The owner of the "cable" is teh obvious choice,
but that does not take into account radio based networks...

IN short:  It looks like the "gateway owners" are going to
have to become the administrators of the future!  Yikes, back
to the future???

Dan
-------
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 15:13:11 EST
From:      ahill@CC7.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast


	I would like to hear why Mark Crispin's second definition isn't
a more pratical approach to the security issue.  If Unix is still vulnerable
after a decade of availability should we ever expect it to be safe?  Why also
should we pick on Unix (except its a good subject to evoke flames)?  My
years of experience in dealing with security indicates that data should
be encrypted whenever practical.  Relying on software or system adminstrators
is folly.

Alan

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 15:37:31 EST
From:      mts@EMPTYS.CC.UMICH.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Security or what?


I'm suprised about messages I receive where the intent
of the author is to raise my consciousness by making me angry.
What usually happens is this -- I get angry.

So is the case with the message from Mark Crispin.

	The philsophy behind Unix largely seems quite reminiscent of the
	... "security through obscurity;"

The only security is through obscurity.  It is precisely the lack of 
information which secures some system.  As an example, consider publishing
the passwords of all the accounts on a system, or the private parts of
DES pair. 

	entrust our systems and data to a open-ended set of youthful
	hackers (the current term is "gurus") who have mastered the
	arcane knowledge.

I'm confused here about the term youthful hackers.  Is youthful under 18?
under 25? under 35?  under 45?  I know of many excellent programmers
in all age groups.  I also know malicious usage has no age range.

Mark, if you are a manager, have you had occassion to use the same talents
you are complaing about to solve some particular problem without getting
involved?  Are you complaing about their knowledge or about your unwillingness
to learn what you need to know?
	 
	The problem is further exacerbated by the multitude of slimy
	vendors who sell Unix boxes without sources and without an
	efficient means of dealing with security problems as they
	develop.

The focus seems to have changed.  If the discussion was about Unix problems,
if the focus was about selection criterea for the people hired,
the focus is now on vendor problems?

Even so,  I wasn't aware that lack of source was the key to the security
problems on Unix systems.  I'm not aware of too many unix vendors who
are unwilling to share their code when they are reimbursed for their efforts.

	I don't see any relief, however.  
	There are a lot of politics involved here.

<here? Where is here? Stanford? Sumex? California? USA?>

	Some individuals would rather muzzle knowledge of
	Unix security problems and their fixes than see them fixed.

This may be true.  This may always be true.

	I feel it is *criminal* to have this attitude on the DDN,
	since our national security in wartime might ultimately depend
	upon it.  If there is such a breach, those individuals will be
	better off if the Russians win the war, because if not there will
	be a Court of Inquiry to answer...

Ah, after alot of though, I think I am beginning to understand what you
are trying to write.  Are you assuming the sensitive machines on the DDN
to be Unix machines?  And from there assuming they are unsecured?
I would think people using machines and needing particular levels of
security would be well aware of the issues, much more than you or I.
I have seen some of the specs to come out of the military for secure
system, and have felt very good about the militaries' own understanding
of its needs.

	It may be necessary to take matters into our own hands, as
	you did once before.

<focus? ranting?>

	I am seriously considering offering a cash reward for the
	first discoverer of a Unix security bug, provided that the
	bug is thoroughly documented (with both cause and fix).

Now I am beginning to understand a bit more... so happends these kind of bugs
have been found  before.  In fact, bugs have been discovered.  In fact,
information has been sent out, describing the problem, and the resolution.

	There would be a sliding cash scale based on how devastating the
	bug is and how many vendors' systems it affects.

<focus?>

	My intention would be to propagate the knowledge as widely
	as possible with the express intension of getting these bugs
	FIXED everywhere.
	 
If that is your intention, then the process you are suggesting for making
it happen is faulty.  You are trying to get people to help you by making
them angry at you.  This will not work.

	Knowledge is power, and it properly belongs in the hands of
	system administrators and system programmers.  It should NOT be
	the exclusive province of "gurus" who have a vested interest in
	keeping such details secret.

Here I am very confused.  Seems the people who are refered to as "gurus"
are the very best system programmers.  All the "gurus" I have ever met
have many talents beyond programming; including leadership.  Getting the
leadership required excellant interpersonnel skills.   As mentioned above,
if this is not the case where you work, then the people responsible for
selecting appropriate individuals for their positions have made mistakes.

As for "in the hands of"; a case of analogy may make clear that this is
not necessarily the best way... I would guess the same was said to the
people making the atomic bomb; that they had the understanding the create
the bomb, but not the understanding to use it correctly.  Defering the
responsibilty to the people who wanted it for "power" created an environment
where those people used the very technology only for "power".  

I would say for you to focus on the knowledge itself, because for you,
the knowledge will not be power.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Tue, 07 Apr 87 15:39:10 EDT
From:      Nick Gimbrone <NJG%CORNELLA.BITNET@wiscvm.wisc.edu>
To:        Barry Shein <BZS@BU-CS.BU.EDU>, tcp-ip@sri-nic.arpa
Subject:   Re: My Broadcast
>As to "muzzling" of unix security problems, there's an entire, active
>mailing list on the internet devoted to nothing but discussing UNIX
>security issues. What other operating system can claim this? (Ok,
>these things are also freely discussed on some of the TOPS-20 lists,
>no argument, but name another? I've seen this stuff specifically
>stifled and people severely flamed on at least one other O/S's list.)
I couldn't resist:
The VM Group of the IBM user's group SHARE has a conferencing system
(VMSHARE) which has an on going discussion of security problems.
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Apr 87 16:13:11 EDT
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        Nick Gimbrone <NJG%CORNELLA.BITNET@wiscvm.wisc.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: My Broadcast
	I would like to hear why Mark Crispin's second definition isn't
a more pratical approach to the security issue.  If Unix is still vulnerable
after a decade of availability should we ever expect it to be safe?  Why also
should we pick on Unix (except its a good subject to evoke flames)?  My
years of experience in dealing with security indicates that data should
be encrypted whenever practical.  Relying on software or system adminstrators
is folly.

Alan

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 18:06:20 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  My Broadcast

Wayne -

     In a sense your message is very reminiscent of the attitude of the
architects of MIT ITS.  It is a useful attitude in certain environments;
it has been argued that the security/integrity consciousness of TOPS-20
and Multics hampered tools development (or limited it to system wizards)
compared to systems such as ITS, WAITS, and Unix.  But this does not
mean that it is right for all environments.  Even in an environment in
which rwalld is useful, it's important to have safeguards in place to
limit its range.  In the present state of affairs, such safeguards are
either absent, not enabled, or inadequately documented.

     Just as an example, why did Dennis Perry's system at DARPA accept a
rwall from a machine somewhere at Berkeley?  Maybe Berkeley is doing such
time-critical research that breakthroughs must be announced by such
"network shouts", but I think it's much more likely that nobody at DARPA
even knew that such a facility existed or was running on their machine.

     Think of what would happen if our IP gateways supported an IP address
of FF.FF.FF.FF (the famous and as-yet mythical "Godzilla-gram").
Fortunately, no gateway does.  The same sort of sanity check needs to
be extended to higher-level protocols.

-- Mark --

PS: I could envision a security bug caused by the ability to broadcast
arbitrary characters to terminals on other systems.  Are all the rwalld
implementations clever enough to filter out control characters?  Also,
those of us who are old enough to know what "cookie bear" know that
broadcasting messages CAN effectively stop all work...
-------

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 19:59:48 EST
From:      karn@JUPITER.BELLCORE.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   A New TCP Retransmission Algorithm

I'd like to describe a TCP retransmission algorithm that I've been using
with excellent results for the last several months.

Background

TCP has the following well known problem.  When an ACK finally returns for a
segment that was retransmitted, you don't know which transmission caused it.
Therefore you can't be certain what the round trip time (RTT) for this
packet was.  Different implementations react differently to this problem:

1.  Some assume that the first transmission(s) was/were lost and restart
the round trip timer on each retransmission.

2.  Others ignore the measurement (since it isn't reliable), keeping their
previous estimates of the round trip time.

Both approaches share a serious problem.  Consider the case where the
retransmission occurred because the smoothed round trip time (SRTT) was too
small, not because packets are being lost.  If approach #1 is used, the
returning ACK is in fact responding to the FIRST transmission, so timing
from a later transmission gives a measurement that is too small. Because the
measurements are erroneously small, SRTT never adapts to the true value;
because the SRTT never adapts to its true value, unnecessary retransmissions
keep happening, resulting in erroneously small RTT measurements.  This
vicious circle can go on essentially forever.  If the measurement is instead
rejected as unreliable, SRTT is never updated, and again unnecessary
retransmissions go on forever.  Believe me, I've seen more than my share of
TCPs behave this way.

The current accepted way out of this problem is to assume the worst whenever
a timeout occurs by measuring the RTT from the FIRST transmission of a given
segment.  If network loading suddenly increases, or if the initial estimate
of the round trip time was too low, there will be a few retransmissions but
the correct value *will* be found; the TCP eventually learns and unnecessary
retransmissions stop.  As long as the network packet loss rate is low, this
approach works quite well. Retransmissions caused by the occasional dropped
packet result in erroneously large round trip time measurements being fed
into the smoother, but this is better than erring on the low side.  Since
few packets are being dropped, subsequent packets will most likely bring the
SRTT value back down to its "real" value long before the next packet is
dropped, so the timeout won't waste too much time.

A serious problem develops, however, when the network is very lossy.  A
"raw" amateur packet radio channel (no link level acknowledgments) often
loses 25% or more of the packets sent due to collisions and poor signal
levels.  Such rates drive this algorithm crazy, especially when consecutive
packets are lost.  In this situation, retransmission intervals are
increasing rapidly due to back-off, and these intervals are added to the
total round trip measurement for the segment. Enough such measurements can
can drive the smoothed round trip time estimate right through the roof.
This is especially true when a nonlinear smoothing function is used that
reacts more quickly to increases in round trip delay than to decreases
(e.g., Mills, RFC-889).

Some people might say that the answer is simple: just constrain the round
trip time to some arbitrary limit, say, 30 or 60 seconds, but there are real
problems with this.  Just how do you pick this "arbitrary" value? Through
measurement? Just like the Dow Jones average, any number you see today is
almost guaranteed to be exceeded tomorrow.  If the delay through the
Internet exceeds your arbitrary timeout limit, you start retransmitting
unnecessarily, further adding to whatever it is that is causing the large
delay in the first place.  Perhaps we need robots to stand in the office of
every protocol hacker:

	WARNING WARNING DANGER WILL ROBINSON!
	ARBITRARY PROTOCOL TIMEOUT DETECTED!
	EVENTUAL CONGESTION COLLAPSE IS NOW GUARANTEED!
	(SOONER OR LATER)

A Better Way

Thinking there *had* to be a better way, I devised and implemented the
following rules:

1. If a segment being ACKed was sent only once, update the estimated round
trip time and recompute the timeout interval. (This is standard behavior).

2. If a timeout occurs, back off the timeout timer interval (e.g., double
it), retransmit the oldest unacknowledged segment, and restart the timeout
timer. (Again, nothing unusual).

3. When an ACK comes in for a segment that was sent more than once (i.e.,
retransmitted at least once) do NOT attempt to measure its round trip time;
leave the smoothed estimate alone.  FURTHERMORE, KEEP THE BACKED-OFF TIMER
SETTING FOR THE *NEXT* SEGMENT, AND DO NOT RECOMPUTE IT FROM (BETA*SRTT) UNTIL
IT OR A LATER SEGMENT HAS BEEN ACKED WITHOUT A RETRANSMISSION.

The purpose of this last rule is as follows.  If the retransmission was
caused by a too-small SRTT, keeping the backed-off timeout for the following
segment gives an ACK a chance to come back without the RTT measurement being
spoiled by an unnecessary retransmission.  This gives a valid data point
that can be fed into the smoothed estimate, driving it toward its true
value.  On the other hand, if the timeout was caused by the packet being
lost altogether, the estimated round trip time will not (and should not)
change.  Only valid RTT measurements are fed into the smoother, and the
timeout is always backed off whenever retransmissions occur until valid RTT
measurements are again obtained. 

This algorithm seems to work extremely well in practice. Even when the
packet loss rate is so high as to cause many packets to be lost in a row,
SRTT always reflects a "sane" value.  If the network delay suddenly
increases, there may be a short period where the retransmission timeout
"oscillates" between a value based on the SRTT and the backed-off interval
necessary to allow an ACK to come back without a retransmission, but this
stops when the computed SRTT catches up with the current network delay.
Dave Mills' nonlinear algorithm shortens this period by allowing the
smoothed estimate to react more quickly to sudden increases, but even
without it the algorithm always converges.

Comments?

Phil Karn

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Apr 87 12:04 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@wiscvm.wisc.edu>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Introduction to Tcp/Ip
Can anyone refer me to an RFC or some other online document that gives
a good overview of Tcp/Ip - how it is built, what protocols it uses,
etc.  Basically a good comprehensive 30-page overview of the whole
Tcp/Ip system.  Please answer directly to me and if you have something
that you wrote up that is not available publically, feel free to send
it to me.

Thanks in advance,
Hank
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7 Apr 87 12:07 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@wiscvm.wisc.edu>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Access control and accountability
I have a feeling this posting might generate quite a bit of
philosphical talk - but I would like to request in advance that I am
not interested in feelings and/or emotions but rather technical solutions.

With that behind me I would like to know about solutions in Tcp/Ip for
the following two areas:

1) Access control:
   A) On a system level: How do I go about restricting the use of users
      from using Tcp/Ip?  I realize that every operating system may have
      a different solution but I am interested in hearing concepts and
      whether anyone is actually doing it.
   B) On a gateway level: If I have a gateway (say something like Bridge
      or cisco) do I have any capability of performing any sort of access
      control?  If yes, is this access control based on connected machines
      or can I even exercise access control on a user level (i.e. restrict
      FTP or TELNET to a certain group of users on a certain machine).

2) Accounting:
   A) System level: Is there any accounting package that can measure things
      like packet transfer (FTP always tells you how many Kb/sec you sent
      so it isn't impossible to figure out) levels and Telnet connect time?
   B) Gateway level: Is there some gateway or monitoring PC that can do
      accounting?  Is the accounting per system or can it be broken down
      per user (I assume very difficult to do)?

As a side note, anyone who is up on ISO: what is the status of accounting
and access control in ISO?  Has it even been thought of?

Thanks in advance,
Hank
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Tue, 7-Apr-87 21:52:48 EST
From:      martillo@ATHENA.MIT.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Ken Olsen vs MAP


Last week Ken Olsen was dumping on MAP/TOP.

Charles Gardner, corporate coordinator of communications standards for
Eastman Kodak Co. and chairman of the MAP/TOP Steering Committee
stated in reply:

"The broadband token bus is needed in the factory, and Olsen doesn't
seem to understand that," he said.  "For some control applications,
you need to calculate how long it takes a message to get from one
place to another, and Ethernet can only give a probability."

Excuse me but I thought life was probabilistic even when tokens were
used to solve contention problems.  Even if you can calculate the time
to get the token, packets still might get trashed in transmission.
Further if you are using virtual circuit oriented protocols at upper
layers, meerly getting the token does not mean you can transmit, the
relevant window might be closed, because the last time the machine
which could open the window got the token, he was so busy transmitting
to yet another machine that he could not send out necessary ACKs.  If
datagrams are being used (which I don't think were part of the MAP
suite when I looked over the spec last year) unreliability makes for
probabalistic calculations.

Do the MAP/TOP people know something which I don't?  Or are they just
totally off the wall?

Yaqim Martillo

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 04:48:16 EST
From:      MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Alan -

     I consider it a given that Unix will never be "safe" (although it can
be made a lot "safer").  The whole point of my message (or flames, if you
will) was to knock a hole into some of the complacency surrounding "standard"
software.  The incident that started this entire discussion demonstrated an
instance in which a particular operating system lacked a sanity check.

     It is my contention that certain (but not all) versions of this operating
system (Unix) have an endemic lack of such sanity checks.  Since this operating
system is the primary operating system on the DDN it is crucial that these
oversights be corrected.  Otherwise, as long as there are other operating systems
or crackers on the network there will be similar incidents.

     If I didn't care, I'd keep my mouth shut.

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

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 05:02:25 EST
From:      mhsc@oce.nl.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: oce!mhsc
From: mhsc@oce.nl (Maarten Schoonwater)
Newsgroups: mod.protocols.tcp-ip,comp.sys.m68k,mod.computers.68k
Subject: TCP-IP for 68000 VERSAdos system
Message-ID: <29@oce-rd2.oce.nl>
Date: 8 Apr 87 10:02:23 GMT
Reply-To: mhsc@oce-rd2.UUCP (Maarten Schoonwater)
Organization: Oce-Nederland bv, Venlo, the Netherlands
Lines: 10


   We have several 68000 based systems that we need to interface with an
   Ethernet using TCP-IP protocols. The systems run under the Motorola
   VERSAdos operating system on a VME-bus. Till now we only found Unix based
   TCP-IP implementations. Support for ftp and perhaps telnet would be
   sufficient. Does anyone know of  possible solutions??

   Maarten Schoonwater			Usenet:  mhsc@oce.nl
   Oce-Nederland B.V.			mail  :  P.O. 101  5900MA Venlo
   R&D department			 	 The Netherlands

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 05:30:49 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Tcpip Overview

Perhaps the best one I have found so far that is available online is
RFC871 (for all those who asked).

Thanks to all those who responded,
Hank

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 07:56:42 EST
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   errata:How big is big

I have got to start screening my mail more carefully for typos.

We at MITRE do NOT forward traffic between ARPANET and MILNET.

PT

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 07:59:14 EST
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Access control and accountability

There are fairly widely-available patches to Unix to allow you to
control access to TCP.  It restricts the ability to open a network
connection based on the network number.  That is, you create a list of
"local" networks.  (We assume you want users to be able to access
local machines, and are concerned only about the Arpanet, etc.  If you
want to restrict all access, you can make this list empty.)  Attempts
to open connections to networks not in this list fail unless the user
is in a certain specified user group.  However this does not control
daemons.  E.g. mail will still work because the mailer has to have
network access.  You will need to insert the access control in
sendmail also.  We have done all of this stuff in the past, but are
not doing it now.  It is nearly impossible to control mail.  There are
now so many gateways, that you can always find some machine on the
local network that will forward your mail to the Arpanet for you.  Not
to mention UUCP or Bitnet to Arpanet gateways.  However other services
should work.  Cisco gateways allow access control lists to be attached
to various operations.  This includes incoming and outgoing telnet
connections (applied only when the connection opens), and packets
going out a specified interface.  We have an access control list on
our Arpanet gateway.  The lists can use wildcards or individual hosts,
however for performance reasons there is a limit to the number of
wildcard conditions you can have.

I know that people are working on accounting and performance
monitoring of the type you mention, but I don't know of anything that
is available now.  Of course most gateways and TCP/IP implementations
maintain packet and event counts of various sorts.  So if you just
mean counts of packets per interface in and out, the Unix TCP/IP
implementations and Cisco gateways do this.  I presume other vendors'
gateways do as well.

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 08:20:46 EST
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ICMP As A Diagnostic Tool?

From Miles Fidelman:
> It's been my observation that ICMP provides some useful functionality for
> isolating and diagnosing internetwork problems - e.g. by timing pings, 
> looking at what percentage of echos come back, source routing packets via
> specific paths, route recording, etc.
> 
> It strikes me that the lack of similar functionality for the OSI world may
> lead to an OSI internet in which significant classes of problems can not
> be fault isolated. I find this a rather scary thought.

It is not true that the OSI world lacks similar functionality.  ISO IP
ISO 8473) has error messages which covers everything ICMP does except
Redirect, Echo, and Timestamp, and Information.

The Redirect function in ISO is in the ES-IS (End System to Intermediate
System) routing protocol, DP 9542.  The Echo function can be accomplished
by using partial source route with the "echoing" machine on the list.
(This if the distant machine is an IS.)  To an ES, a transport connection
can be used much to the same, if not better, effect.

In addition, ISO is working on a suite of management functions and
protocols which will allow for much more detailed and flexible management,
debugging, etc., of networks.  I can't speak for all layers, but in ANSI
X3S3.3 (Network and Transport layers) we are actively working on this.

	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 09:13:51 EST
From:      mo@SEISMO.CSS.GOV.UUCP
To:        mod.protocols.tcp-ip
Subject:   Token nets and deterministic behavior

Having actually conducted experiments to measure these claims of
deterministic behavior, I can say that (1) it simply ain't so and (2)
you don't WANT it to be so.  Token rings have their own brand of
strange pathologies related to convoying, syncronized buffer blocking,
and such.  It is very clear from our experiments that the hardware
never read the papers describing the "theoretical" behavior.
"Fantasized" would be a better word.  The paper, and a couple of others
along the same line, is in the Proceedings of the IEEE Symposium on
Computer Networking, December, 1983, if you care to look at the
numbers.

	-Mike O'Dell

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 09:20:01 EST
From:      preece%mycroft@GSWD-VMS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast


  From: "Alan R. Hill" <ahill@cc7.bbn.com>
> My years of experience in dealing with security indicates that data
> should be encrypted whenever practical.  Relying on software or system
> adminstrators is folly.
----------
Unless you're doing all your work on a trusted workstation, to which
only you have access, encryption isn't enough.  The processor on which
the work is done has to encrypt and decrypt, meaning that the data
has to be floating around in plaintext form at some times.  If your
software is ignoraably secure, then so is your transitory plaintext.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 09:29:50 EST
From:      ahill@CC7.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: My Broadcast

Mark,
	History indicates that "whistle blowing" is not generally appreciated
regardless of its well meaning intent.  Unless DoD specifies requirements
for Unix use on the internet, I doubt that anything will change.

	Although there are lots of security problems with Unix and its
network code, I thought I would relate my experience with this type of
problem.  Many years ago I had responsibility for a Unix system that
was used by competing contractors and a government agency.  My job was
to prevent importation of non-approved code that could compromise the
integrity of the system.  I also had to keep the various groups from
digging into each others files.  I modified the access code for the
network and the file system.  It took me roughly 2 hours work and
I was able to restrict access by user and source location.  I also logged
all access attempts good or bad.  My point is that the effort to 
dramatically improve control is not costly.

	I suggest that this discussion is no longer useful to the
TCP-IP mailing list and can be continued off-line.  I generally
approve of comments that will evoke an emotional response since they
will generate much more data than those that are more benign.

Alan

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 09:46:42 EST
From:      howard@cos.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Access control and accountability


In article <8704071037.AA04224@ucbvax.Berkeley.EDU>, HANK@TAUNIVM.BITNET (Hank Nussbacher) writes:
> With that behind me I would like to know about solutions in Tcp/Ip for
> the following two areas:
> As a side note, anyone who is up on ISO: what is the status of accounting
> and access control in ISO?  Has it even been thought of?

Here are some answers, or directions, for the questions raised, but
from an ISO context:

The ISO OSI Management Framework, a draft appendix to the OSI Reference
Model, defines five missions in OSI management:  configuration,
fault, performance, security, and accounting management.  This is
an architectural definition of the problem, not an implementation
specification.  Associated with this architecture are the 
Common Management Information Service (CMIS) 
and the Common Management Information Protocol (CMIP)
definitions, which describe mechanisms for management entities to
exchange general management information.

There is a subtle distinction between "security" and 
"security management".  Such mechanisms as link or end-to-end 
encryption are security mechanisms,
part of the data link or transport layer definitions.  
If these mechanisms are not implemented, 
there is no need to manage them and thus no
need for security management.  Once you decide to have them, security
management then logically should exist to provide such supporting
services as breach attempt logging, key distribution, etc. Similar
distinctions apply in accounting;  accounting data collection is
a layer function, but data distribution is a management function.

> 1) Access control:
>On a system level: How do I go about restricting the use of users
> from using Tcp/Ip?  
>On a gateway level: If I have a gateway (say something like Bridge
> or cisco) do I have any capability of performing any sort of access
> control?  If yes, is this access control based on connected machines
> or can I even exercise access control on a user level (i.e. restrict
> FTP or TELNET to a certain group of users on a certain machine).
Association Control Service Elements (ACSE --formerly CASE)
, a layer 7 function, does 
deal with access control to OSI applications.  Other applications,
such as FTAM (File Transfer, Access, and Management) do have
their own access control mechanisms, including optional anonymous
user access.
> 2) Accounting:
> System level: Is there any accounting package that can measure things
>   like packet transfer (FTP always tells you how many Kb/sec you sent
>   so it isn't impossible to figure out) levels and 
>   Telnet connect time?
ANSI standards X3.102 and X3.141, the latter in publication,
define general models for describing such things as packet transfer
time; draft ANSI work in the T1Q1.3 committee and the Question 29
Rapporteur's group in CCITT Study Group VII also are dealing
with such problems.  Neal Seitz, at the U.S. Commerce Department's
Institute for Telecommunications Sciences in Boulder, CO,
is the chair of the latter groups and a major author of the
preceding standards.  He has some public domain software available
from his group (telephone 303-497-3106; I don't have a net address).
> Gateway level: Is there some gateway or monitoring PC that can do
>   accounting?  Is the accounting per system or can it be broken down
>   per user (I assume very difficult to do)?
There are general, hardware-based monitoring systems which can
do this.  They are not cheap, and the mindset of their sales
forces is primarily dealing with response time measurement
in IBM 3270 and similar environments.  Nevertheless,
systems made by Tesdata (also the OEM for Infinet and Paradyne),
Avant-Garde, and Dynatech do have some ability to track
applications, users, or other high-level entities.  Several]
years ago, I did the first Tesdata design, and know that
it's quite internally capable of tracking network addresses,
user ID's, etc.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Apr 87 12:21:54 -0400
From:      Craig Partridge <craig@LOKI.BBN.COM>
To:        karn%jupiter.bellcore.com@relay.cs.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: A New TCP Retransmission Algorithm

Phil,

    I've been looking at the same problem from the perspective of
RDP for some months.  Some of my conclusions are in a paper I'm
presenting at the June USENIX.  Most of them are the same as yours,
except I came up with a different selection algorithm based on the
assumption that the network *usually* maintains relative order
(if packet A is sent before packet B, then is is likely that A
will reach the destination before B).

    By the way, in support of the view that we need to look at
retransmission timeouts, I've seen the SRTT explode at loss rates
below 10% on some systems.

    One other point -- your algorithm is engaged in throwing away a
certain number of good RTT values because the filtering isn't perfect.
If the RTT suddenly increases sharply, you have to throw out the first
packet that has the new RTT, and wait for the second packet to be
accepted.  Out of curiousity, what is beta in your implementation?
I.e., how much does the RTT have to increase to cause this problem?

Craig
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8 Apr 87 10:29:50 EDT
From:      "Alan R. Hill" <ahill@cc7.bbn.com>
To:        Mark Crispin <MRC%PANDA@sumex-aim.stanford.edu>
Cc:        ahill@cc7.bbn.com, NJG%CORNELLA.BITNET@wiscvm.wisc.edu, tcp-ip@sri-nic.arpa
Subject:   Re: My Broadcast
Mark,
	History indicates that "whistle blowing" is not generally appreciated
regardless of its well meaning intent.  Unless DoD specifies requirements
for Unix use on the internet, I doubt that anything will change.

	Although there are lots of security problems with Unix and its
network code, I thought I would relate my experience with this type of
problem.  Many years ago I had responsibility for a Unix system that
was used by competing contractors and a government agency.  My job was
to prevent importation of non-approved code that could compromise the
integrity of the system.  I also had to keep the various groups from
digging into each others files.  I modified the access code for the
network and the file system.  It took me roughly 2 hours work and
I was able to restrict access by user and source location.  I also logged
all access attempts good or bad.  My point is that the effort to 
dramatically improve control is not costly.

	I suggest that this discussion is no longer useful to the
TCP-IP mailing list and can be continued off-line.  I generally
approve of comments that will evoke an emotional response since they
will generate much more data than those that are more benign.

Alan

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 11:59:15 EST
From:      craig@LOKI.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   re: A New TCP Retransmission Algorithm


Phil,

    I've been looking at the same problem from the perspective of
RDP for some months.  Some of my conclusions are in a paper I'm
presenting at the June USENIX.  Most of them are the same as yours,
except I came up with a different selection algorithm based on the
assumption that the network *usually* maintains relative order
(if packet A is sent before packet B, then is is likely that A
will reach the destination before B).

    By the way, in support of the view that we need to look at
retransmission timeouts, I've seen the SRTT explode at loss rates
below 10% on some systems.

    One other point -- your algorithm is engaged in throwing away a
certain number of good RTT values because the filtering isn't perfect.
If the RTT suddenly increases sharply, you have to throw out the first
packet that has the new RTT, and wait for the second packet to be
accepted.  Out of curiousity, what is beta in your implementation?
I.e., how much does the RTT have to increase to cause this problem?

Craig

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 13:23:46 EST
From:      raju@MITRE.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   test

please ignore, this is a test.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 13:34:00 EST
From:      NS-DDN@DDN3.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Access control and accountability


 
 
The UCLA ACP and its derivatives are very concerned about access control, and
less concerned about accounting. The public domain code has a pseudo-service
called PACCESS which is invoked at choice places in the package to inquire as
to the efficacy of an end user's requests. Unless the installer does some
coding, the barn door is wide open for using TCP, UDP, TELNET, etc., and
whatever security system installed on MVS controls file access. UCLA has an
interface to ACF2 which is based upon a local interface SVC, and their version
of PACCESS can be conditionally assembled. However, the interface involves some
pretty trick UCLA MVS mods and would require substantial systems programming
expertise and time to massage into another environment.
 
DDN/MVS features a modified version of PACCESS which uses a table of user-ids,
passwords, and user attributes to control user access. Customers code macros
for each user, reassemble the table, and link it into the commutator. This
controls VTAM accesses to the internet, use of some privileged TELNET services,
authorizations to receive SMTP mail on a mailbox basis, and FTP file accesses
on a high-level DSNAME qualifier basis.
 
For accounting, the public domain version sports logic which accumulates CPU
time used by pseudo-tasks or counts ptask dispatches (the default). However,
no provision is made for reporting this information to an accounting system.
Here again, it is expected that an experienced systems programmer is installing
the ACP into a sophisticated MVS shop. The FTP logic has a place (FTPWACR -
Write ACcounting Record) where an SMF record could be cut, but only generates
an internal WTO-type messaage describing the FTP request. DDN/MVS currently
provides no enhancements to the accounting support.
 
Dave Craig
Network Solutions, Inc.

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 87 13:34 EST
From:      NS-DDN @ DDN3.arpa
To:        HANK%BARILVM.BITNET @ WISCVM.WISC.EDU, tcp-ip @ SRI-NIC.ARPA
Cc:        
Subject:   Re: Access control and accountability
 
 
The UCLA ACP and its derivatives are very concerned about access control, and
less concerned about accounting. The public domain code has a pseudo-service
called PACCESS which is invoked at choice places in the package to inquire as
to the efficacy of an end user's requests. Unless the installer does some
coding, the barn door is wide open for using TCP, UDP, TELNET, etc., and
whatever security system installed on MVS controls file access. UCLA has an
interface to ACF2 which is based upon a local interface SVC, and their version
of PACCESS can be conditionally assembled. However, the interface involves some
pretty trick UCLA MVS mods and would require substantial systems programming
expertise and time to massage into another environment.
 
DDN/MVS features a modified version of PACCESS which uses a table of user-ids,
passwords, and user attributes to control user access. Customers code macros
for each user, reassemble the table, and link it into the commutator. This
controls VTAM accesses to the internet, use of some privileged TELNET services,
authorizations to receive SMTP mail on a mailbox basis, and FTP file accesses
on a high-level DSNAME qualifier basis.
 
For accounting, the public domain version sports logic which accumulates CPU
time used by pseudo-tasks or counts ptask dispatches (the default). However,
no provision is made for reporting this information to an accounting system.
Here again, it is expected that an experienced systems programmer is installing
the ACP into a sophisticated MVS shop. The FTP logic has a place (FTPWACR -
Write ACcounting Record) where an SMF record could be cut, but only generates
an internal WTO-type messaage describing the FTP request. DDN/MVS currently
provides no enhancements to the accounting support.
 
Dave Craig
Network Solutions, Inc.

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 14:45:47 EST
From:      geof@apolling.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: A New TCP Retransmission Algorithm


 >      1. If a segment being ACKed was sent only once, update the estimated round
 >      trip time and recompute the timeout interval. (This is standard behavior).
 >      
 >      2. If a timeout occurs, back off the timeout timer interval (e.g., double
 >      it), retransmit the oldest unacknowledged segment, and restart the timeout
 >      timer. (Again, nothing unusual).
 >      
 >      3. When an ACK comes in for a segment that was sent more than once (i.e.,
 >      retransmitted at least once) do NOT attempt to measure its round trip time;
 >      leave the smoothed estimate alone.  FURTHERMORE, KEEP THE BACKED-OFF TIMER
 >      SETTING FOR THE *NEXT* SEGMENT, AND DO NOT RECOMPUTE IT FROM (BETA*SRTT) UNTIL
 >      IT OR A LATER SEGMENT HAS BEEN ACKED WITHOUT A RETRANSMISSION.

Looks good.  If it works, all the better!

I like the separation of the RTT estimate from the timeout computation.
I think it would help the description of the algorithm to make the
separation clearer.  The RTT estimate is a particular metered value, so
it makes a lot of sense to not try to update it based on data that is
questionable.  The timeout value is a function of the RTT estimate, but
need not be a simple function -- sometimes it might not depend on the RTT
estimate at all, as you cleverly suggest.

The possible problem is that the RTT might not be estimated for a long
time (if packets are lost frequently).  It looks like the algorithm will
correctly play with the timeout in the absence of measured RTT values.
I'm not sure what you do in [1], though.  If you compute something like
    RTTnew = (7*RTTold + RTTmeasured)/8
then your behavior may be bad when the RTT had become seriously out of
date and was then measured.  You'll get a damped oscilatory response,
I think.

An example:

Say the RTT estimate is 1 second and the retransmission timer is 2 s.
Now imagine that the the network conditions change abruptly
so that the real network RTT is 10 seconds.  For several segments,
you get spurious retransmissions and don't compute the RTT.  Meanwhile
the retransmission timer is increased using normal backoff.  Eventually,
it hits ~10 seconds or so, and you get a valid computation of RTT.
This gives you:
    RTTnew = (7*1 + 10)/8 = 2.125
Then you might compute
    timer = RTT * 2 = 4.25 s

This means that the next segment will also be retransmitted spuriously,
and the process repeats.  Maybe my example is too severe when compared
with the real world (I don't think so, if you have both satnets, X.25
links and direct lines as alternate paths to each other).

I guess the moral of the story is to use a method of smoothing the RTT
estimate that converges very quickly, like
    RTTnew = (RTTold + RTTmeasured)/2
or even
    RTTnew = RTTold

One element of incompleteness in the algorithm is the turn-on transition.
You don't specify how to make the initial RTT and Timer guesses.  In view
of the above, that sounds especially important in this algorithm.

- Geof Cooper

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 15:52:16 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Security or what?

Michael,

I read your message in response to Mark Cripin's flame. I only want
to comment on guru versus system programmer misunderstanding you have.

We have many people at CMU that can crack a system but are impossible to
communicate with. These people are brilliant but their personaility is very
very poor on interpersonal skills. In many cases, they are in control of
important software. There is no intent to discourage such situations by
management since all benefit....on the other hand they are not policy or
decision makers except in their own "world". 

In some cases, I have dealt with people that control software and blantantly
ignore management. Management is in a position of needing them and not
feeling the issue is critical enough to fire (since they have a hard time
evaluating the situation). The result is the hacker is viewed as a guru
who controls the systems and runs it as he sees fit and management tolerates
him until he leaves.

In the final analysis, hacker is not the same as guru which is not the
same as system programmer which is not the same as system manager. Luckily,
many people have some or all of these "jobs" at the same time....makes
life interesting.

Cheers,
-Rudy

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 15:52:50 EST
From:      bzs@BU-CS.BU.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   My Broadcast


>...If Unix is still vulnerable
>after a decade of availability should we ever expect it to be safe?

Look folks, we're really flying off the handle here on innuendo and
virtually no facts.

Let me try to rehash what I believe happened that started all this:

Sun provided a utility, rwalld, which is a daemon which listens for
certain informatory message broadcasts on a network (such as a
scheduled system shutdown) and displays them on terminals.

This was an extension of the single system 'wall' (Write ALL) program
that most UNIX systems come with. Wall, as it is standardly provided,
is not the issue. Most O/S's come with some utility to broadcast a
message within a local system (ie. no network involved.) Sun simply
extended this service to a network facility (leaving the older method
intact, thus it was an optional extension.)

The security breach was that someone discovered that many systems were
configured to accept these broadcasts fairly indiscriminately.

This, in turn, was due not to a lack of security inherent in the
system, but the fact that the way the system comes off the tape it
allows this. All O/S's come off of distribution tapes inherently
insecure (eg. super-user password is typically generic or null.)

There is a facility (netgroups) which is supposed to be set up by the
concerned system administrator with those machine groups who are to be
allowed to issue such broadcasts (well, that's a little backwards, you
list the systems who you will accept such messages from.)

So, in complete contradiction to Mark Crispin's analysis, it was not
the "random gurus" who were the problem in finding an unclosed
security hole but, rather, the sysadmins who never even opened the
manuals to find out what daemons they were running and how to
administer security (there aren't that many, look at your start-up
files and services/servers files.)

Or, perhaps as was the case with my system (which received the
broadcast) they didn't particularly care if someone sent such a
message and viewed it in the same light as someone sending mail to
someone who didn't want it, a nuisance that could be dealt with easily
if a problem arises (I am still not convinced there is much of a
problem with this particular event.) We never really took a vote on
how many people even agree that a security breach worthy of concern
has occurred on their system, even that fundamental observation
remains an opinion.

Thus, as is almost always the case with system security, it was not
the fault of the system providers but entirely the fault of those
charged with the responsibility of maintaining the system, if they
were concerned about this (later) then they have only themselves to
blame. They simply left the barn door wide open, ignoring the door,
the lock and the key.

To add insult to the system administrator's injury, not only was it
within their normal administrative power to limit such an event with a
simple file edit, they never even had to run the utility at all.  It
is purely icing on the cake to find out about other system's status
changes on your network and can be removed by adding one comment
character to one line in the system's start-up file with no real ill
effect on the operation of the system (remember, only SUN's UNIX even
has this particular utility.)

I really wish that people who send notes discussing these issues would
ask themselves if their notes actually contain any factual information.

If nothing else, this whole interchange has pointed out how
ill-informed many folks are about security management on various
systems and how they have turned to folk tales and philosophizing
to supplant that void.

This, in my opinion, is a far worse problem. I do not deny that there
are security and integrity problems on an internet. I only claim that
little of the discussion I have seen has moved us any closer to
measuring and rectifying the problems instead of just finding someone
to blame (we has met the enemy and they is us.)

	-Barry Shein, Boston University

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 16:43:59 EST
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: errata:How big is big

As they say, tut tut!

dennis
-------

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Wed 8 Apr 87 16:43:59-EST
From:      Dennis G. Perry <PERRY@vax.darpa.mil>
To:        tsuchiya@gateway.mitre.org
Cc:        tcp-ip@sri-nic.arpa, perry@vax.darpa.mil
Subject:   Re: errata:How big is big
As they say, tut tut!

dennis
-------
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 8-Apr-87 17:13:01 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ICMP As A Diagnostic Tool?


     The Redirect function in ISO is in the ES-IS (End System to Intermediate
     System) routing protocol, DP 9542.  The Echo function can be accomplished
     by using partial source route with the "echoing" machine on the list.
     (This if the distant machine is an IS.)  To an ES, a transport connection
     can be used much to the same, if not better, effect.

I believe one advantage to the way we do ICMP echoes is that, for all
the implementations I have heard of, processing of the echo reply takes
place in kernel space instead of user space.  The use of a user program
waiting on a transport connection to trap echoes and generate echo
replies requires scheduling of that process.  If the system is loaded,
it will lessen the accuracy of the round-trip time.

In case anyone is interested, I have some war stories describing the use
of ICMP for fault isolation.  (Example:  discovering that you have lost
your gateway, and finding a new one.)  They're too long to reprint here,
but might provide some amusing reading.

--gregbo

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Wed, 08 Apr 87 12:30:49 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Tcpip Overview
Perhaps the best one I have found so far that is available online is
RFC871 (for all those who asked).

Thanks to all those who responded,
Hank
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Apr-87 04:01:35 EST
From:      HANK@BARILVM.BITNET.UUCP
To:        mod.protocols.tcp-ip
Subject:   Summary of Tcp/Ip overviews (for all who asked)

Computer Networks, V7, No 5, October 1983, DOD Architecture Model
by Cerf and Cain.

Postel, J., C. A. Sunshine, and D. Cohen, "The ARPA Internet
     Protocol," Computer Networks, pp. 261-271, July 1981.

Leiner, Barry M., Robert Cole, Jon Postel, and David Mills,
     "The DARPA Internet Protocol Suite," IEEE Communica-
     tions, vol. 23, no. 3, pp. 29-34, March 1985.


                               BACKGROUND RFCs

      IEN-48       The Catenet Model for Internetworking
      RFC-896 *    Congestion Control in IP/TCP
      RFC-970 *    On Packet Switches with Infinite Storage
      RFC-813      Window and Acknowledgement Strategy in TCP
      RFC-814      Name, Addresses, Ports, and Routes
      RFC-815      IP Datagram Reassembly Algorithms
      RFC-816      Fault Isolation and Recovery
      RFC-817      Modularity and Efficiency in Protocol Implementation
      RFC-871 *    A Perspective on the ARPANET Reference Model

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Apr 87 14:06:35 -0800
From:      J. Joaquin Garcia-Luna <garcia@tsca.istc.sri.com>
To:        tcp-ip@sri-nic
Cc:        garcia@tsca.istc.sri.com
Subject:   Call for Participation

We are looking for contributions in TCP/IP interoperation for the ACM
SIGCOMM workshop on frontiers in computer communications technology.
Topics include better performance tcp/ip implementations,
interoperation, adoption in Japan, comparison with tp 4, use of tcp
over mixed media links (satellites, radio nets, telephone lines), 
window mechanism analysis, etc.

If you plan to contribute, please drop me a message.

More information follows.
JJ
---------


                            CALL FOR PARTICIPATION                       


                           ACM SIGCOMM Workshop on
                Frontiers in Computer Communications Technology

                             August 11-13, 1987
                      Stoweflake Resort, Stowe, Vermont



Sponsored by ACM SIGCOMM, with the cooperation of the Information
Sciences and Technology Center of SRI International, and Cybertree Inc.
-----------------------------------------------------------------------

The ACM SIGCOMM workshop on frontiers in computer communications
technology is intended as an international forum where those interested
in the theory, development, and applications of computer communications
can meet to discuss the state of the art and future directions in
computer communications, and to further each other's work through
shared information.

Contributions in the form of 20 to 30 minute presentations are sought
in the areas of:

	TCP/IP interoperability
	Gateway protocols and internetworking
	High-speed networks
	High-speed packet switching 
	New applications and future directions of packet switched networks
	ISDN
	Local area networks and metropolitan area networks
	Routing and congestion control in integrated-services networks
	Advances in protocol verification, testing, and analysis
	Large-scale computer networks
	Naming in large distributed systems
	Networking for scientific computing
	Networking for personal computers	
	Computer-supported collaborative work
        Distributed desktop publishing and graphics applications
	Impact of standards in the future of computer communications

Attendees wishing to contribute to the program are requested to submit
a one to two-page abstract or full papers (about 20 pages) by June 15,
1987 to:

	PROGRAM CHAIR
	J.J. Garcia-Luna
        SRI International
        333 Ravenswood Ave., EK-319
        Menlo Park, CA 94025
        (415) 859-5647
	ARPANET: garcia@istc.sri.com
        Telex: 334486

Abstracts can be submitted by electronic mail.  Notification of
acceptance will be given by July 10, 1987.  The record of the workshop
will be published as a special issue of the ACM Computer Communication
Review. 

For more information about the workshop, please contact the program
chair, or Dr. Walter Kosinsky, Workshop Chair (203/869-6322).

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

Please indicate your interest in the workshop here and return this
portion to:

	WORKSHOP REGISTRAR
        Prof. John Trono
        Computer Sciences Dept.
	Saint Michael's College
	P.O. BOX 243
        Winooski, Vermont 05404
 

______ I intend to submit an abstract on the subject of


______ I am interested in attending the workshop, please send me
additional information.

Name:
Affiliation:
Street Address:
City, State, Country:
Telephone:
Electronic Mail:
Fax:
Telex:


-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Apr 87 08:51:41 PDT
From:      karels%okeeffe@berkeley.edu (Mike Karels)
To:        4bsd-bugs@okeeffe.Berkeley.EDU
Cc:        tcp-ip@sri-nic.arpa
Subject:   4.3BSD network bug fix (#9, tcp_output)
Index:	sys/netinet/tcp_output.c 4.3BSD FIX

Note: this message, and other 4.3BSD network-related fixes,
are maintained on host ucbarpa.Berkeley.EDU for anonymous FTP
from the directory pub/4.3/fixes.

Description:
TCP may scramble data at the end of a connection under conditions
of high packet loss.  If a connection is closed while output is still
draining (as FTP does), loss of more than one data segment in the last
window will cause a byte of data to be deleted without detection.

Fix:
*** /nbsd/sys/netinet/tcp_output.c	Wed Aug 20 09:31:34 1986
--- ./tcp_output.c	Sat Mar 28 15:32:04 1987
***************
*** 5,7 ****
   *
!  *	@(#)tcp_output.c	7.2 (Berkeley) 8/20/86
   */
--- 5,7 ----
   *
!  *	@(#)tcp_output.c	7.2.1.1 (Berkeley) 3/28/87
   */
***************
*** 232,235 ****
  	 */
! 	if (flags & TH_FIN && tp->t_flags & TF_SENTFIN &&
! 	    tp->snd_nxt != tp->snd_una)
  		tp->snd_nxt--;
--- 232,234 ----
  	 */
! 	if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0)
  		tp->snd_nxt--;
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Thu,  9 Apr 87 10:05:00 edt
From:      ms6b#@andrew.cmu.edu (Marvin Sirbu)
To:        tcp-ip@sri-nic.arpa
Cc:        martillo@SRI-NIC.ARPA
Subject:   Re: Ken Olsen vs MAP
The answer to your question is that the MAP people do not fully understand
all the sources of probabilistic delay that you catalog.  Some are beginning
to get the idea, however;  Allen Bradley, a major factory automation company,
has just contracted with Bridge to OEM Ethernet equipment.

In their defense however, they have always been concerned about the situation
which might arise when a failure in a manufacturing process causes 500
sensors to all start sending emergency warning messages at the same instant.
This can lead to lockup on an Ethernet in a way which should not occur on a
token bus.  I have heard stories to the effect that one process control
company experienced such a lockup on a 128 kbps CSMA/CD network and became an
adament supporter of token buses as a result.  (Whether that experience could
be recreated on a 10 Mbps network is questionable, of course.)

Marvin Sirbu
CMU
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 87 10:55:24 EDT
From:      Eric Gisin <egisin%watmath.waterloo.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   4.3 bsd and slip
We converted to 4.3 recently, and have a 9600 baud slip P-P link
between two hosts.
Sometimes the interface goes into a state where there are
constantly 20-45 packets on the output queue with a single connection.
Throughput goes down, and a "rsh otherhost date" takes forever.
Data overrun or line errors are not a problem.

From my understanding of tcp, the sending side must be doing
excessive retransmissions.  I thought 4.3 had fixed
most of the network bugs and problems.  Does anyone know what's
happening before I try to do a tcp trace?

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 87 11:27:26 AST
From:      jas@monk.proteon.com (John A. Shriver)
To:        tcp-ip@sri-nic.arpa
Cc:        iso@nrtc.northrop.com
Subject:   ICMP As A Diagnostic Tool? (ISO)
Another important aspect of ICMP echo reply is that it is Mandatory in
the TCP/IP suite (see the latest Official ARPA Internet Protocols,
where IP and ICMP are the only Mandatory protocols).  Using
transport-level protocols in ISO for the same function will not be
nearly as effective, for example a router (IS in ISO parlance)
nominally has no use for transport protocols.  I would recommend to
ISO designers to add a mandatory echo response at as low a level as
possible in the architecture.  If the source routing trick does this,
and is a mandatory capability of ISO 8473, great.  I would then ask
the implementers to provide the necessary user program.

(But enough, this discussion really belongs on the ISO mailing
list, see the CC: address...)
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9 Apr 87 13:00:47 est
From:      karn@flash.bellcore.com (Phil R. Karn)
To:        imagen!geof@decwrl.DEC.COM
Cc:        karn@flash.bellcore.com, tcp-ip@sri-nic.arpa
Subject:   Re: A New TCP Retransmission Algorithm
You are quite correct in pointing out the oscillatory behavior in the
timeout interval when the network delay suddenly increases.  I mentioned
this in my note, as I have both simulated the behavior you describe and
observed it in practice.  The important thing, though, is that the
oscillation always damps out at the correct new value.  How *fast* it
damps out depends of course on the smoothing function in use. I've been
using Dave Mills' nonlinear function. It seems to work quite well since
it responds more quickly to increases than to decreases in observed network
delay.

The "oscillation" is the result of a compromise between assuming the timeouts
are the result of sudden network congestion and assuming the timeouts
are caused by packets being lost outright because of link transmit errors.
Without information in the TCP header indicating which transmission
a given ACK is answering (clearly the ideal solution except for the
compatibility problems) my algorithm seems to be a workable heuristic.

Phil


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Apr-87 18:43:16 EST
From:      shapiro@pdp.cs.ohiou.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   XNS to TCP-IP changeover on Bridge Hardware.


We will soon be making the change from Bridge XNS to TCP-IP on our network.
I am not sure that we are looking forward to this change (well at least
those who will have to make the change and take responsiblity for it). Is there  
anyone on the net who has made this change? If so I would like to have some
input on the following:
 
1.) How about a general comment on Bridges release of TCP-IP.
 
2.) When making the change over is there a way that the current network
    configurations can be copied over so that we don't have to re-enter
    all of the port configs?
 
3.) I have been told that the current release of TCP-IP will boot remotely
    from our central NCS-150 controller. Is this true? I have not made
     contact with our Bridge reps yet (seems that this is not my responsiblity).

4.) Can anyone out there address the issue of compatibility with other
    TCP-IP networks?
 
I have to try to be honest with you folks on the net. This is really an
attempt to Cover My A.. when this new software arrives. I hope things
will go smoothly but who can say. I personally feel if it ain't broke -
don't fix it.
 
The above opinions are mine and not necessarily those of my employer.

 
Ohio University
Computing and Learning Services
Haning Hall
Athens, Ohio 45701
 
(614) 593-1608

BITNET: shapirob@ouaccvma
UUCP:   ihnp4!cbosgd!oucs!shapiro

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Thu, 9-Apr-87 19:30:00 EST
From:      JSLove@MIT-MULTICS.ARPA.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: A New TCP Retransmission Algorithm

Counterproposal:  the following rules are rather complex, and require
more memory than some implementations may use (e.g., a timestamp per
packet), but they may prevent the sort of explosion we see in SRTT
somewhat better, and they use information which is already available.
This combines several schemes, used without credit, so if you think you
recognize the serial numbers, you probably do.

1.  Keep a timestamp associated with each packet in the retransmission
queue which tells when it was first transmitted.  This timestamp is
provided by IP, and indicates when the packet was given to the device
driver.  Since retransmissions should use the same IP identifier for
reassembly, it is reasonable for TCP and IP to share the same copy of
the packet for retransmission purposes.

2.  Never retransmit a packet which hasn't been transmitted yet.  There
are a number of implementations which seem to have this problem.  In
fact, never retransmit a packet which hasn't had a certain minimum delay
since its last transmission:

   SRTT * VR * RB ** RC

Where SRTT is smoothed round trip time, VR is variance ratio, RB is
retransmission base, and RC is retransmission count.

3.  Let's set VR and RB to 2.  This is arbitrary; substitute values to
taste.  RC is initially zero, and is reset for every packet.  It doesn't
have to be stored in the packet, since only one packet is retransmitted
at a time.  The SRTT for the first packet is unknown and doesn't matter.
The RTTs used to calculate the SRTT use a variable weight, SF (smoothing
factor) which is initially zero.  The MSF (maximum SF) is also
arbitrary, but values from 4 to 8 seem reasonable.

4.  When we transmit the first packet, we set the timer to one second.
After the timer has elapsed, we retransmit, and increase the interval
geometrically (by RB), so we retransmit after 2 more seconds, then 4,
and so on.

5.  When the acknowledgement comes back after 10 seconds from the first
transmission, we have possible RTTs of 10, 9, 7, and 3.  We take the
WCRTT (worst case RTT) of 10.

6.  For subsequent datagrams, we distinguish between three kinds of RTT:

a) the datagram was retransmitted (so we have a WCRTT).

b) the datagram wasn't retransmitted, but it was acknowledged at the
same time as a subsequent datagram, or a retransmission of a preceding
datagram was sent subsequent to the transmission of this datagram.  We
can't be certain how much of the RTT was due to the influence of other
datagrams, so we have an MRTT (merged RTT).

c) the datagram wasn't retransmitted, and no retransmissions of
preceding datagrams were transmitted after this one.  We have an ARTT
(actual RTT).

7.  Each time an acknowledgement packet is processed, we may produce
RTTs, including at most one WCRTT or ARTT, and possibly several MRTTs.
All contribute to the SRTT, but at different weights.  For the first
packet (SYN) or if they would tend to decrease the SRTT, all types count
at full weight, so

   SF = minimum (SF + 1, MSF)
   SRTT = ((SF - 1) * SRTT + RTT) / SF

If they would tend to increase the SRTT, then the weights differ, so
that an ARTT counts at full weight, a WCRTT at a lesser weight (perhaps
half), and an MRTT somewhere in between.  This means that an estimate of
the RTT is more strongly influenced by optimistic or reliable data.
This should help the algorithm converge on a small number.

8.  Depending on the nature of the RTT from the preceding packet, we
choose one of the following functions to generate the minimum
retransmission interval for the current packet:

   Delay = maximum (SRTT, ARTT) * VR
   Delay = maximum (SRTT * VR, MRTT)
   Delay = maximum (SRTT * VR, WCRTT * PLR)

PLR is the packet loss ratio.  Lacking a filter to determine PLR as well
as VR, it should be set to some arbitrary value sufficient to keep the
delay from blowing up in the face of high packet loss rates.  Let us
assume that packet loss rates (in both directions) never average more
than 50%, so a PLR of .5 should be sufficient.

9.  Don't ever use a simple timer to determine if a connection has died.
Instead, kill the connection when RC gets to a large value.  Assuming
that SRTT is one, a large value might be 8 (nearly 5 minutes), but the
general idea is that the geometric backoff means that a long delay will
be needed to determine that the connection is broken, so rather than
pick a fixed time interval you can base this on the fixed time interval
of consecutive lost packets.

Note that failing to acknowledge a packet isn't necessarily enough
information since if the remote site closes its window it can still
indicate that it is alive by acknowledging old data.  However, the
geometric backoff means that it might take a very long time to detect
the reopened window.  A window opening ACK wouldn't be acceptable unless
it opened the window farther than it had been before being closed.  Does
anyone admit to actually closing windows?  This might be an argument to
limit the maximum retransmission interval to say, two minutes.  Even
then, you might want a connection to keep trying forever.

Comments?

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Thu, 09 Apr 87 11:01:35 O
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Summary of Tcp/Ip overviews (for all who asked)
Computer Networks, V7, No 5, October 1983, DOD Architecture Model
by Cerf and Cain.

Postel, J., C. A. Sunshine, and D. Cohen, "The ARPA Internet
     Protocol," Computer Networks, pp. 261-271, July 1981.

Leiner, Barry M., Robert Cole, Jon Postel, and David Mills,
     "The DARPA Internet Protocol Suite," IEEE Communica-
     tions, vol. 23, no. 3, pp. 29-34, March 1985.


                               BACKGROUND RFCs

      IEN-48       The Catenet Model for Internetworking
      RFC-896 *    Congestion Control in IP/TCP
      RFC-970 *    On Packet Switches with Infinite Storage
      RFC-813      Window and Acknowledgement Strategy in TCP
      RFC-814      Name, Addresses, Ports, and Routes
      RFC-815      IP Datagram Reassembly Algorithms
      RFC-816      Fault Isolation and Recovery
      RFC-817      Modularity and Efficiency in Protocol Implementation
      RFC-871 *    A Perspective on the ARPANET Reference Model
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      09 Apr 87 21:57:15 D (Thu)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        tcp-ip@sri-nic.ARPA
Cc:        brescia@ccv.bbn.com
Subject:   domain transition is not smooth
In order to fix mailing lists BEFORE they get broken by yet another
transition, I need a tool which will accept a mailing list with garbage
addresses, and replace each host part of the address with the corresponding
'correct' name.  An 'awk' script would be acceptable, since I have access to
u**x-like systems.

    Thanks for reading,
    Mike
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Thu,  9 Apr 87 22:17:53 EDT
From:      "Lawrence A. DeLuca, Jr." <HENRIK@AI.AI.MIT.EDU>
To:        Rudy.Nedved@H.CS.CMU.EDU
Cc:        hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA, mts@EMPTYS.CC.UMICH.EDU
Subject:   Security or what?

More hacker vs. system programmer flamage:

Having spent some time in the MIS world (hired to be a system programmer, but
what they really needed was a high-power system manager) I have found that many
of the other "system programmers" (i was Unix, they were DOS/VSE) were reluctant
to answer questions and share information.  They considered it job security.  This
made it somewhat difficult when I had to make my machines talk to theirs, for
example.  I have met many hackers who are equally obnoxious, but for a slightly
different (though similar) reason - "If you can't figure it out all by yourself,
you don't deserve to know."

I find either attitude in any person irritating.  System programmers are no
better than anyone else.

					larry...

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 87 10:17:15 -0800
From:      Thomas Eric Brunner <brunner@spam.istc.sri.com>
To:        Jon Crowcroft <jon@cs.ucl.ac.uk>
Cc:        unni@cs.ucla.edu, cperry@gateway.mitre.org, AFDDN.BEACH@gunter-adam.arpa, tcp-ip@sri-nic.arpa
Subject:   Re: ROS/REX
Jon,
	My copy of REX is a preliminary draft (March 1985), at the top of
the cover page is the then-current location of the master discfile, so
machine readable does exist. 

/teb
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Apr-87 02:48:54 EST
From:      sgroff@CCJ.BBN.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: A New TCP Retransmission Algorithm

OK.  I'll get back to you after I consult the Barclays sales folks.

One other question.  Is the inclusion of a Customer Support section
in this document a one-off thing ??  Or will it appear in other docs ??
If it's the latter, how do I ensure that the Regional Support Centers
get included in all future docs ??

Thanks,
Steve

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 87  3:48:54 EDT
From:      "J. Stephen Groff" <sgroff@ccj.bbn.com>
To:        "Phil R. Karn" <karn@flash.bellcore.com>
Cc:        imagen!geof@decwrl.dec.com, tcp-ip@sri-nic.arpa, sgroff@ccj.bbn.com
Subject:   Re: A New TCP Retransmission Algorithm
OK.  I'll get back to you after I consult the Barclays sales folks.

One other question.  Is the inclusion of a Customer Support section
in this document a one-off thing ??  Or will it appear in other docs ??
If it's the latter, how do I ensure that the Regional Support Centers
get included in all future docs ??

Thanks,
Steve

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 87 07:47:18 CST
From:      feldman%mycroft@gswd-vms.ARPA (Mike Feldman)
To:        TCP-IP@sri-nic.arpa
Subject:   Re: Ken Olsen vs MAP
> The answer to your question is that the MAP people do not fully understand
> all the sources of probabilistic delay that you catalog.  ...
> 
> In their defense however, they have always been concerned about the situation
> which might arise when a failure in a manufacturing process causes 500
> sensors to all start sending emergency warning messages at the same instant.
> This can lead to lockup on an Ethernet in a way which should not occur on a
> token bus.

I was envolved in designing an early token bus process control system for
a control system manufacturer in '69 - '70, when I first saw the Ethernet spec
and articles describing it.  I was a junior software engineer at the time,
and I suggested to the powers-that-be that Ethernet was much simpler to
implement, and that we were already doing it for the token recovery sequence
(silence on the wire).

It's my opinion that it was dogma among communications engineers even then
that you needed deterministic bus access time and guaranteed throughput for
control system muxes.  There were two cases where the system had to perform
under Ethernet-busting loads.  One was during customer accecptance testing,
and the other was when the reactor pressure relief valve failed open.

I got angry reactions when I suggested Ethernet would be cheaper and easier
to build and would have better performance almost all of the time.  They
were even more irritated when I suggested the if determinism and known
throughput were so important that they use time division multiplexing.

These days, there is a lot of support among control system suppliers for MAP.
There hope is that the semiconductor industry will see a large market and
implement all the hard, expensive lower layers in silicon, because so far it's
been too expensive for each system house to develop one that's a comercial and
technical success.  It might happen, but they still won't get the deterministic
round trip message delay needed to implement stable fast feedback loops.

These opinions are my own.

Mike Feldman
Gould Computer Systems Division
1101 East University Avenue
Urbana, IL 61801
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 87 10:31:03 -0400
From:      Daniel Long <long@SH.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        cic@SH.CS.NET
Subject:   Re: domain transition is not smooth
CSNET has an address "fixer" that you might try.  It's fairly simple-minded but
we've found it a helpful first-step in converting mailing lists.  It will
convert nicknames into official names.  It checks both the NIC table and domain
servers (with MX).  It also knows about non-domain style names that have since
disappeared from the NIC table.

Mail a message to "fixaddr@relay.cs.net" containing no text except the
mailing list (one address per line; user@host is best).  You will get
a reply that contains an annotated "fixed" list.  No guarantees but we've
found it to be a helpful step in the conversion of mailing lists here at
CSNET.

Please send any comments or questions about "fixaddr" to me (long@sh.cs.net).

Enjoy,
Dan
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 1987 08:13:29 EDT
From:      C. David Young <DYOUNG@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        DYOUNG@A.ISI.EDU
Subject:   [Nick Gimbrone <NJG%CORNELLA.BITNET@wiscvm.wisc.edu>: Re: tcp/ip/IBM/PROnet]
Since I got quite a number of responses to my query about how one goes
about interfacing an IBM to a PROnet and just as many requests for CC on
all information that I receive, I thought it would be worthwhile and
easier to just broadcast the information.

By far the most common configuration is that of using Wiscnet running
under VM and going through a DACU unibus interface with a corresponding
unibus interface to the PROnet.  Nick Gimbrone took the time to give me
a thorough description of this setup and his message follows for those
interested.  Unfortunately, our situation requires the speed of PROnet
80 (80 mbs) with an upgrade to FDDI (100 mbs) when it is available.
(Proteon has an upgrade policy that is quite reasonable.)  However, from
what I know about the DACU, it is a relatively slow device (256 kbs?).
It just does not make much sense to us to use such a slow interface
on such a fast bus!  I am about to give up trying to attach the IBM
directly to the PROnet and instead attach it to an Ethernet through
an ACS9310 from Advance Computer Communications.  This device will work
at the full 10 mbs of the Ethernet and then we can go through an
Ethernet/PROnet gateway which should also operate at several mbs.  ACC
also has TCP/IP for MVS in a package called ACCES/MVS.

Bob Dixon also indicated they were using two 4341s connected to a tcp/ip
Ethernet via Fibronics KNET hardware and software (and then gatewaying
onto the PROnet).  I have not investigated this device yet.

Once again, thanks to everyone who sent input.

David Young
                ---------------

Return-Path: <@wiscvm.wisc.edu:NJG@CORNELLA.BITNET>
Received: FROM WISCVM.WISC.EDU BY USC-ISI.ARPA WITH TCP ; 9 Apr 87 18:55:46 EDT
Received: from CORNELLA.BITNET by wiscvm.wisc.edu on 04/09/87 at 17:55:31 CDT
Received: by CORNELLA (Mailer X1.23b) id 5100; Thu, 09 Apr 87 18:42:05 EDT
Date:         Thu, 09 Apr 87 18:11:13 EDT
From:         Nick Gimbrone <NJG%CORNELLA.BITNET@wiscvm.wisc.edu>
Subject:      Re: tcp/ip/IBM/PROnet
To:           DYOUNG@a.isi.edu
cc:           Mark Bodenstein <MAB@CornellC>,
              Mike Hojnowski <MQH@CornellC>,
              Scott Brim <swb@devvax.tn.cornell.edu>

>I was given your name by Selden Ball as a person who might know
>something about hooking an IBM 4381 to a Proteon Pronet.  Could
>you tell me about your configuration, both hardware and software?
>We are interested in using TCP/IP on an IBM on a PROnet 80.
>David Young
Any of the 4341/4381/308x/3090 series will work just the same.  We use
Pronet 10 here, and I understand that there MAY be a minor
consideration with Pronet 80 and how the software picks up the card's
address (some timing difference between the two systems) which MAY not
be handled correctly (or may be done just fine) by the software (I'm
just not in a position to know yet).  Also, we are a VM shop.  I know
nothing about MVS (or at least will never admit to knowing anything
about it), so beware the VM slant in the following.  Lastly, feel free
to come back with further questions or give me a call at (607)255-3748.
Now, on with the show:

We are using the Unibus Pronet10 cards to plug an IBM 7170 "DACU" into
the Pronet.  The 7170 also plugs into an IBM channel (either on a 370
or XA mode machine).  This 7170 has an IBM PC (don't know if it is
ordered separately or as a package from IBM) on top of it.  The PC runs
some code from IBM (called DACU FUNCTIONAL CODE) which makes the 7170
look to the channel like a 3250 (thus you gen it to VM as a 3250 or
2250 graphics device).  In addition this functional code calls some
'user exits' which in this case are supplied w/ the host TCP/IP
software.  These exits will deal w/ the protocol that the host TCP/IP
software uses to pass info to the PC on what to send where, etc.  It is
this software that MAY need to be upgraded for PRONET 80.  The 7170 is
not currently FE supported, but for now a user supported box.  Thus you
will need to deal with the details of getting it attached to the
channels, etc (unless you have a good relationship with FE).  At this
point the hardware side is basically dealt with...  off to software.

We are running the Wiscnet 1.3B package (1.3.1 is now available from
U.ofWisc, we just haven't upgraded yet).  This software is not
installed nor maintained quite like any other normal VM software (if
you follow the instructions in the package).  For all intents and
purposes one can also consider it to be equivalent to the IBM TCP/IP
package 5798-DRG.  In the case of Wiscnet 1.3.1 you can pick up from a
server at UofMaryland ($WNTSRV at UMDD, see Bruce Crabill
<Bruce@UMDD.Bitnet> for more info) some 'common mods' and some service
utilities to make the system maintainable using a natural method for VM.
We have gone this route and it is in our opinion the best way to go.
In addition these common mods address several problem areas in the base
code, and thus are things you want on the base anyway (things like
subnetting support, etc).

Of course, the above host software is only available to Universities,
but from your address I assume that is not a problem.

When setting up the server machines that Wiscnet runs on be sure to
also set the CP Scheduler performance settings (set favor, set qdrop
off, set reserved, set priority, etc) needed to give good performance
to servers of this sort (similar to what one would do for a guest
intruder such as MVS or VTAM, etc under VM).  This is critical to
performance.

You will want to be able to regularly update the public copies of the
HOSTS ADDRINFO and HOSTS SITEINFO files which are built from the
hosts.nic file you get from sri-nic.arpa (or where ever) to describe
all the host names on the network.  This may be a problem if they are
on the Y-disk (or may not, depending upon your shop's policies).  (Yes,
there is no Name Server or query'r support in Wiscnet, may be in some
future time IBM will release the stuff that UofW did but was not
allowed to release.)

I'm sure I've missed lots, perhaps the others copied will add to the
info and copy the rest of us (hint, hint).  Also feel free to ask
questions (it will help us prepare for a talk we need to give soon on
this very question, so this would help us too).
-------
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 87 12:45:47 PST
From:      Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Access control and Accountability
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Access control and accountability
Summary: 
Expires: 
References: <8704081259.AA17700@topaz.rutgers.edu>
Sender: 
Reply-To: dcrocker@ubvax.UUCP (Dave Crocker)
Followup-To: 
Distribution: world
Organization: Ungermann-Bass, Inc., Santa Clara, Ca.
Keywords: 

In article <8704081259.AA17700@topaz.rutgers.edu>
	    hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes:
>...  You will need to insert the access control in
>sendmail also.  We have done all of this stuff in the past, but are
>not doing it now.  It is nearly impossible to control mail.  There are
>now so many gateways, that you can always find some machine on the
>local network that will forward your mail to the Arpanet for you.  Not
>to mention UUCP or Bitnet to Arpanet gateways...

The MMDFII mail transport system, used by CSNet and distributed with
4.3BSD, has considerable path-filtering based security.  You can
prohibit users, networks or hosts from sending to any specified host
or network.

While this requires a cooperating set of internal MMDF's to enforce
filtering pervasively, rather than simply at the boundaries, one would
assume that a security mechanism would not be used unless the requirement
were fairly severe.

Dave

P.S.  You are correct that statistics gathering features are present in
      other vendors' IP Routers.
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Apr-87 12:28:01 EST
From:      unni@CS.UCLA.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: ROS/REX


If you have a m/c readable~r REX, could  you send it to me ?

Thanx

unni

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Apr-87 15:11:07 EST
From:      Mills@UDEL.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Little delights

Folks,

Thought you might enjoy a couple of creepycrawlers that wandered past
our gateways recently. One was a 'gram from 10.10.0.2 to 10.0.0.0, which
showed up at dcn-gw (10.2.0.96). The most beguiling explanation is that
somebody uncorked a 4.2 Unix on the ARPANET and turned on rwho. I still
have to explain why that 'gram showed up here, unless maybe the dude
is running 4.3 Unix and is trying to find a boot server. Maybe I should provide a
suitable core image? That's even more beguiling.

Observed on linkabit-gw (10.0.0.111) yesterday were a number of creatures
apparently hatched on net 128.174. Some of these were from one subnet to
the all-zeroes address on another subnet, while others were to the net (sic)
broadcast address of all ones. While that suggests broken subnets, my
intrigue is spiked by curious fact the buggers showed up half way across the
country.

I know there is a logical explanation for this infestation and will (wearily)
pursue it. Meanwhile, it's the chuckles that keep me warm and suggest that
we might place an add for an Internet spider to catch them bugs.

Dave

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Apr-87 15:45:47 EST
From:      dcrocker@engr.ub.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Access control and Accountability

Newsgroups: mod.protocols.tcp-ip
Subject: Re: Access control and accountability
Summary: 
Expires: 
References: <8704081259.AA17700@topaz.rutgers.edu>
Sender: 
Reply-To: dcrocker@ubvax.UUCP (Dave Crocker)
Followup-To: 
Distribution: world
Organization: Ungermann-Bass, Inc., Santa Clara, Ca.
Keywords: 

In article <8704081259.AA17700@topaz.rutgers.edu>
	    hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes:
>...  You will need to insert the access control in
>sendmail also.  We have done all of this stuff in the past, but are
>not doing it now.  It is nearly impossible to control mail.  There are
>now so many gateways, that you can always find some machine on the
>local network that will forward your mail to the Arpanet for you.  Not
>to mention UUCP or Bitnet to Arpanet gateways...

The MMDFII mail transport system, used by CSNet and distributed with
4.3BSD, has considerable path-filtering based security.  You can
prohibit users, networks or hosts from sending to any specified host
or network.

While this requires a cooperating set of internal MMDF's to enforce
filtering pervasively, rather than simply at the boundaries, one would
assume that a security mechanism would not be used unless the requirement
were fairly severe.

Dave

P.S.  You are correct that statistics gathering features are present in
      other vendors' IP Routers.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10 Apr 87 11:48:00 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        unni@cs.ucla.edu, cperry@gateway.mitre.org, AFDDN.BEACH@gunter-adam.arpa
Cc:        tcp-ip@sri-nic.arpa
Subject:   ROS/REX

Several people asked me where to get documents on ROS and/or
REX:

I'm working on finding an address for email (someone at NPL may
have online copies),
but the best I can suggest
at the moment is to try and find how to get in touch with ECMA (European
Computer Manufacturers Association), and ask them direct for
their standards documents.

One person I know in the US who has
talked to these people and ANSA about REX and transaction
protocols is Dave Clark at MIT.

Jon
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 87 14:00:11 GMT
From:      dartvax!richb.UUCP@seismo.css.gov (Richard E. Brown)
To:        mod-protocols-tcp-ip%linus@mitre-bedford.ARPA, mod.protocols.tcp-ip
Subject:   TCP on an HP 3000

I wasn't paying much attention a couple of months ago, but I seem
to remember that someone said that there was an implementation of
TCP on HP3000 computers.

Is this true?  Please mail responses to me.  Thanks.

Rich Brown
Dartmouth College
Kiewit Computation Center
Hanover, NH 03755
603/646-3648


-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Fri, 10-Apr-87 23:52:12 EST
From:      haque@umn-cs.UUCP.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: umn-cs!haque
From: haque@umn-cs.UUCP (Samudra E. Haque)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: TCP on an HP 3000
Keywords: TCP HP3000 HP9000
Message-ID: <1476@umn-cs.UUCP>
Date: 11 Apr 87 04:52:09 GMT
Article-I.D.: umn-cs.1476
Posted: Fri Apr 10 22:52:09 1987
References: <5985@dartvax.UUCP>
Organization: CSci Systems Group,University of Minnesota,Mpls.
Lines: 24

In article <5985@dartvax.UUCP>, richb.UUCP@dartvax.UUCP (Richard E. Brown) writes:
> 
> I wasn't paying much attention a couple of months ago, but I seem
> to remember that someone said that there was an implementation of
> TCP on HP3000 computers.
> 
Speaking of HP's.. 

We have HP 9000/200 and /300 machines. While the /300 have full
networking (psuedo BSD), the /200 machines do not have any networking
hardware available for them. (according to our HP rep)  We are running
HP/UX on them.

Am I wrong in assuming that there really is no future for networking
the /200 machines or that they might become very expensive to have
networking on ?

				Samudra E. Haque
				Computer Science Systems Group
				University of Minnesota
				Minneapolis, MN 55455

	haque@umn-cs.arpa  or  ..!dayton!umn-cs!haque
		     or (612) 625-0876

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Apr-87 05:09:07 EST
From:      root@TOPAZ.RUTGERS.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: XNS to TCP-IP changeover on Bridge Hardware.

Actually we have seen significant improvement with the Bridge
TCP/IP terminal server software recently.  It now seemed to be
reasonably reliable, which is a big improvement.  I admit
however that support of domain servers for name lookup instead
of the old IEN116 would be welcome, as well as a few other
details from the 4.3 generation.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 87 01:26:28 GMT
From:      steve@cs.d.umn.edu (Steven M. Miller)
To:        mod-protocols-tcp-ip@seismo.CSS.GOV, mod.protocols.tcp-ip
Subject:   Re: XNS to TCP-IP changeover on Bridge Hardware.

In article <531@pdp.cs.OHIOU.EDU>, shapiro@pdp.cs.ohiou.EDU (brian shapiro) writes:
> 
> We will soon be making the change from Bridge XNS to TCP-IP on our network.
>  
> 1.) How about a general comment on Bridges release of TCP-IP.
Doesn't come very close to the quality of their XNS stuff.  They are
way behind with this software (*supposedly* they are working to bring it
up to snuff). If you use your bridges for dial-in uucp then your in trouble.
(some people have claimed that there are ways to get around this, namely 
the 'f' protocol, but I've yet to get it to go) 

> 3.) I have been told that the current release of TCP-IP will boot remotely
>     from our central NCS-150 controller. Is this true? 
Yes.  (If only they supported booting from a host...)

> 4.) Can anyone out there address the issue of compatibility with other
>     TCP-IP networks?
Even though the tcp software supports a subnet mask, the software is 
only at the level of 4.2bsd tcp.   

My personal preference is for Encore's Annex, but since you already
went with Bridge...


			
-- 
	
	    Steve Miller, UMD Computer Science, steve@cs-gw.D.UMN.EDU

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 11-Apr-87 20:45:51 EST
From:      tai%hpltyj@HPLABS.HP.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re:  Submission for mod-protocols-tcp-ip

|Speaking of HP's.. 
|
|We have HP 9000/200 and /300 machines. While the /300 have full
|networking (psuedo BSD), the /200 machines do not have any networking
|hardware available for them. (according to our HP rep)  We are running
|HP/UX on them.
|
|Am I wrong in assuming that there really is no future for networking
|the /200 machines or that they might become very expensive to have
|networking on ?
|
|				Samudra E. Haque

The 9000/200 is virtually identical to the 9000/300 series.  That is,
they can run the same software (kernel is different though) and use the
same networking hardware.  However, the 200 is no longer supported; the
5.17 release of HP-UX is the last release which works for the 200 series.

On the other hand, I've built a 5.17 kernel with the latest networking code
(5.3) for use with the 200 series.

..tai

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Apr-87 12:23:01 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: Call for Participation

The ACM SIGCOMM Workshop in Stowe, Vermont this August will have a session
or two on TCP/IP issues.  The program chair, JJ Garcia-Luna, has asked me
to coordinate the submissions on TCP/IP.  The format of the workshop 
encourages presenters to make a point and then be prepared to discuss
it from many aspects.  

So, please let me know if you want to make a presentation.  Mail to this
mailbox or phone calls to 408-996-2042 wil find me.

Thanks,
Dan
-------

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sun, 12-Apr-87 12:33:42 EST
From:      dzoey@TERMINUS.UMD.EDU.UUCP
To:        mod.protocols.tcp-ip
Subject:   Re: FTP client program

No doubt you will get many replies, but here's the info on how to listen
for a data connection.

The well know data port for FTP is port 20.  You can change this by
issuing the PORT command to the host before you issue a STOR or
RETR.  I forget the exact syntax for the PORT command, but it's in
the RFC.

example

user wants to stor data:

client: PORT x
server: {200,250} PORT command okay
client: listen on x
client: STOR foo
server: {150,125} Establishing connection {opens a tcp connection to port x}

If you want more info, I'll be glad to help.
				Joe Herman

dzoey@umd5.umd.edu

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1987 11:46:18 EDT
From:      Dr. James A. Guffey <GUFFEY@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   FTP client program
I am trying to implement a program on the Silicon Graphics Workstation to
access a remote FTP server.  I've been able to establish a control 
connection and pass commands and receive replies.  However, I have been
unable to establish a data connection.  The RFC says to listen on user
port U before issueing a STOR command.  My question is what is the value
of the default user port U?  I have tried 21, 22, and 1043 (my side of
the control connection).  None of these work.  Any help is greatly
appreciated.
Steve
-------
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 1987 13:23:01 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        J. Joaquin Garcia-Luna <garcia@TSCA.ISTC.SRI.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re: Call for Participation
The ACM SIGCOMM Workshop in Stowe, Vermont this August will have a session
or two on TCP/IP issues.  The program chair, JJ Garcia-Luna, has asked me
to coordinate the submissions on TCP/IP.  The format of the workshop 
encourages presenters to make a point and then be prepared to discuss
it from many aspects.  

So, please let me know if you want to make a presentation.  Mail to this
mailbox or phone calls to 408-996-2042 wil find me.

Thanks,
Dan
-------
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 01:29:51 EST
From:      daemon@DECWRL.DEC.COM.UUCP
To:        mod.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: decwrl!tpov02.dec.com!mobbylin
From: mobbylin@tpov02.dec.com (Mobby Lin, Taiwan Software Services)
Newsgroups: mod.protocols.tcp-ip
Subject: What's vendor support TCP-IP
Message-ID: <9269@decwrl.DEC.COM>
Date: 13 Apr 87 06:29:50 GMT
Sender: daemon@decwrl.DEC.COM
Organization: Digital Equipment Corporation
Lines: 16


hi everyone,

I am more interested in TCP/IP. Does someone know what's third party software
and its hardware can support the tcp/ip and what's model and how to contact 
those products can ported into Wang, Tandem, IBM and NEC.

Now I am planning to connect VAX to Wang, Tandem, IBM and NEC, based on X25
on layer 1, 2, 3 and layer 4,5  used on tcp/ip.
                                                               
my address at 
    mobbylin%22599.dec.com@decwrl.arpa
    Software Services, Taiwan Digital Equipment.

regards,
Mobby Lin

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 1987 06:31-PDT
From:      Mike StJohns <StJohns@SRI-NIC.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Draft of Revised AHIP (1822) available
A  draft  of  proposed  revisions  to  the Arpanet Host Interface
Protocol  (AHIP)  is  available  on  the   NIC   [26.0.0.73]   or
[10.0.0.51] under the name "PS:<IETF>AHIP-E.TXT".

This  is a revision to AHIP as originally specified in BBN report
1822.  This document is available for public comment for the next
six  weeks at which time it will be revised and the final version
issued as a standard.  Please send your comments to  the  address
listed in the document, NOT to this list, and not to me.

This  document  is  being  circulated  for  review because of the
possibility  of  the  MILNET  exceeding  in  size   the   current
addressing limitations of 256 packet switches.

Mike
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 07:17:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Bridghe tcp/telnet


     >We will soon be making the change from Bridge XNS
     >to TCP-IP on our network. I am not sure that we
     >are looking forward to this change (well at least
     >those who will have to make the change and take
     >responsiblity for it). Is there anyone on the net
     >who has made this change? If so I would like to
     >have some input on the following: 
     > 
     >1.) How about a general comment on Bridges release 
     >    of TCP-IP.

     We are doing this at Northeastern University.  So far it seems to 
work as advertised (sort of, I'll get to this in a minute)

     > 
     >2.) When making the change over is there a way that 
     >    the current network configurations can be copied 
     >    over so that we don't have to re-enter all of the 
     >    port configs?

     Not that I know of.  This is a pain!

     > 
     >3.) I have been told that the current release of 
     >    TCP-IP will boot remotely from our central NCS-150 
     >    controller. Is this true? I have not made contact 
     >    with our Bridge reps yet (seems that this is not 
     >    my responsiblity).

     My books say the same thing but we haven't tried this yet.  Ask me 
in a few weeks if you haven't done it yet.  

     >
     >4.) Can anyone out there address the issue of 
     >    compatibility with other TCP-IP networks?
     > 

     It seems to work with Sun systems as that is what we're doing right 
now.  Soon I hope to be working Bridge TELNET with MICOM's 
Board/software for VAX/VMS.  MICOM said that would work when I asked 
them at the TCP conference in March.  I'll be beta testing some stuff 
for MICOM.  I'll find out.

     >I have to try to be honest with you folks on the
     >net. This is really an attempt to Cover My A..
     >when this new software arrives. I hope things will
     >go smoothly but who can say. I personally feel if
     >it ain't broke - don't fix it. 
     > 

     Always good to cover your ...  Anyway, the one problem I had with 
the TCP Bridge box was the following.

     The box of course needs an IP address, xx.yy.zz.tt.  To do this the 
box I've got has ROM code debug software with a system generation
option.  The catch came when I looked at the debug menu through the
command port. There wasn't any generation option listed. 

     We called Bridge and read them the menu.  They were a bit concerned 
that the option wasn't listed but said, "Try <generating code>."  (I 
wrote it down someplace.  It's either GE or GN)  The option wasn't 
listed but it did run.  After that it was obvious what to do.  Choice 3 
took me through the "give box an address" path and everything worked.  

     Note that this is specific to the TCP software.  The XNS system
generation won't do it. 

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13 Apr 87 07:17 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Bridghe tcp/telnet
     >We will soon be making the change from Bridge XNS
     >to TCP-IP on our network. I am not sure that we
     >are looking forward to this change (well at least
     >those who will have to make the change and take
     >responsiblity for it). Is there anyone on the net
     >who has made this change? If so I would like to
     >have some input on the following: 
     > 
     >1.) How about a general comment on Bridges release 
     >    of TCP-IP.

     We are doing this at Northeastern University.  So far it seems to 
work as advertised (sort of, I'll get to this in a minute)

     > 
     >2.) When making the change over is there a way that 
     >    the current network configurations can be copied 
     >    over so that we don't have to re-enter all of the 
     >    port configs?

     Not that I know of.  This is a pain!

     > 
     >3.) I have been told that the current release of 
     >    TCP-IP will boot remotely from our central NCS-150 
     >    controller. Is this true? I have not made contact 
     >    with our Bridge reps yet (seems that this is not 
     >    my responsiblity).

     My books say the same thing but we haven't tried this yet.  Ask me 
in a few weeks if you haven't done it yet.  

     >
     >4.) Can anyone out there address the issue of 
     >    compatibility with other TCP-IP networks?
     > 

     It seems to work with Sun systems as that is what we're doing right 
now.  Soon I hope to be working Bridge TELNET with MICOM's 
Board/software for VAX/VMS.  MICOM said that would work when I asked 
them at the TCP conference in March.  I'll be beta testing some stuff 
for MICOM.  I'll find out.

     >I have to try to be honest with you folks on the
     >net. This is really an attempt to Cover My A..
     >when this new software arrives. I hope things will
     >go smoothly but who can say. I personally feel if
     >it ain't broke - don't fix it. 
     > 

     Always good to cover your ...  Anyway, the one problem I had with 
the TCP Bridge box was the following.

     The box of course needs an IP address, xx.yy.zz.tt.  To do this the 
box I've got has ROM code debug software with a system generation
option.  The catch came when I looked at the debug menu through the
command port. There wasn't any generation option listed. 

     We called Bridge and read them the menu.  They were a bit concerned 
that the option wasn't listed but said, "Try <generating code>."  (I 
wrote it down someplace.  It's either GE or GN)  The option wasn't 
listed but it did run.  After that it was obvious what to do.  Choice 3 
took me through the "give box an address" path and everything worked.  

     Note that this is specific to the TCP software.  The XNS system
generation won't do it. 

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 08:31:00 EST
From:      StJohns@SRI-NIC.ARPA (Mike StJohns)
To:        comp.protocols.tcp-ip
Subject:   Draft of Revised AHIP (1822) available

A  draft  of  proposed  revisions  to  the Arpanet Host Interface
Protocol  (AHIP)  is  available  on  the   NIC   [26.0.0.73]   or
[10.0.0.51] under the name "PS:<IETF>AHIP-E.TXT".

This  is a revision to AHIP as originally specified in BBN report
1822.  This document is available for public comment for the next
six  weeks at which time it will be revised and the final version
issued as a standard.  Please send your comments to  the  address
listed in the document, NOT to this list, and not to me.

This  document  is  being  circulated  for  review because of the
possibility  of  the  MILNET  exceeding  in  size   the   current
addressing limitations of 256 packet switches.

Mike

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 08:48:00 EST
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client program


    Date:  12 April 1987 13:33 edt
    From:  Joe I. Herman <dzoey at TERMINUS.UMD.EDU>
    Subject:  Re: FTP client program

                    .
                    .
                    .
    The well know data port for FTP is port 20.  You can change this by
    issuing the PORT command to the host before you issue a STOR or
    RETR.  I forget the exact syntax for the PORT command, but it's in
    the RFC.

Port 20 is the well known data port for the FTP Server.  It cannot be
changed by having the client FTP send the port command to the Server.
This only changes the port that the client FTP uses which is usually NOT
port 20.  The server may change from port 20 by issuing the PORT command
to the client.

    example

    user wants to stor data:

    client: PORT x
    server: {200,250} PORT command okay
    client: listen on x
    client: STOR foo
    server: {150,125} Establishing connection {opens a tcp connection to port x}

    If you want more info, I'll be glad to help.
                                            Joe Herman

    dzoey@umd5.umd.edu

Again, this changes the port that the client listens on, not the
server's use of port 20.  I didn't get a copy of the original message
that started this, but hope that it helps.

                    John G.  Ata

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 09:41:00 EST
From:      Ata@RADC-MULTICS.ARPA ("John G. Ata")
To:        comp.protocols.tcp-ip
Subject:   Re: FTP client program

Actually, my original message had a typo...the server may NOT change the
well known port 20 by issuing the PORT command.  (The only way I know
how to change the server port is by having the client issue the PASV
command, but this does more than allow for a port change.)  Sorry for
the confusion...

                    John G. Ata

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 11:01:28 EST
From:      brady@MACOM4.ARPA (Sean Brady)
To:        comp.protocols.tcp-ip
Subject:   Packet Tracing

Greetings all:

    On several occasions, I have seen messages which included packet traces
for packets sent around the internet. I would like to use this to perform
some tests here, but I am unable to find specific references on how to do
this options setting on my machines. I'm using SUN 3's with Unix 3.2 (I think).
Any ideas out there?

					Sean

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 16:56:50 EST
From:      ROODE%BIONET@SUMEX-AIM.STANFORD.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   commercial network economies vs. ARPANET

Telenet just made a press release where they talked about
2,000 hosts on their network worldwide.

The ARPANET/Internet can top that easily--there are 4,000 hosts
listed in the NIC host table alone, and only the tip of
the iceberg is represented there.

In comparing costs of Telenet to ARPANET it would not be realistic
to look only at a flat cost per packet without taking into
account a reasonable cost for maintaining connectivity
to a large number of hosts.
-------

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 13-Apr-87 18:05:48 EST
From:      LYNCH@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Network Management Meeting Scheduled



 

       FORMATION OF A NETWORK MANAGEMENT WORKING GROUP

 

The Internet Activities Board in conjunction with its Internet
Engineering Task Force is forming a Network Management
Working Group composed of representatives from the Internet
community and vendors of TCP/IP products. The group will
develop a set of RFCs that define tools to manage systems
containing multiple vendor TCP/IP products.  The working
group is expected to focus on detailing a framework for
management of TCP/IP based networks, the control and
monitoring information to be managed, and the protocols
necessary for the exchange of management information.   Near
term solutions that can result in vendor implementations will
be stressed.

 

The Working Group's first meeting will be held on May 5th,
1987, at TECHMART, the Silicon Valley Marketing Center, in
Santa Clara, CA, from 9-4 in Suite 125.  Adjacent to the
Doubletree Hotel and the Santa Clara Convention Center,
TECHMART is at 5201 Great America Parkway.  Please contact
Dan Lynch, Advanced Computing Environments, 408-996-2042,
if you plan to attend so proper arrangements may be made. The
meeting will be open to all users and vendors.



Lee LaBarre from the Mitre Corporation will chair this
meeting.  Please contact him at 617-271-8507 if you wish to
be included in the following agenda.



The agenda for the first meeting will include the following:

 

        - Discussion of the scope and schedule of the project.  A  
           candidate proposal will be presented.

        - Presentations on models for network management.  Lee 
           LaBarre will present the ISO and IEEE models.

        - Presentations on TCP/IP parameters to be managed.

        - Presentations on protocols for management exchanges.



A long term work list for the group is as follows:

 

        a) Agree on the scope of network management and the
areas of management to be addressed.  The possible areas
include:

 

                configuration management

                fault management

                performance management

                security management

                accounting management

 

           The group might reasonably choose to only address the
first three areas.

 

        b) Determine the management requirements in the chosen
areas.

 

        c) Determine a framework, or model, for network
management.  The group should examine models developed by
standards organizations such as ANSI and IEEE, and any
models being developed for management of the Arpanet or
MILNET.  If possible, the model should be based on existing
work done by the standards bodies.  This does not imply that
we should track evolving standards, but that we might benefit
from their work.  It may be desirable to develop a common
model to ease the management of networks that contain DoD
and ISO protocol suites.  Vendors could then use the same
network management system to manage products in both
suites.

 

        d) Determine for each layer of the DoD suite the
parameters to be managed, e.g., protocol parameters (timers,
max. no. of connections, max. segment size, no. of
retransmissions), statistics (counts on segments, octets sent
and received, refused connections, retransmissions, discarded
datagrams, etc).

 

        e) Determine the protocol for exchanging management
information. Candidates to be examined from the standards
area include ISO's Common Management Information Protocol
(CMIP) and the protocol defined by the IEEE for management
exchanges.  A protocol suitable for encoding management data
to be transferred among machines with heterogeneous storage
formats is CCITT X.409 (ISO ASN.1).

 

        f) Document the above decisions as a set of RFCs.

 



 



-------

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 1987 19:05:48 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        TCP-IP@SRI-NIC.ARPA, netbios@MITRE-BEDFORD.ARPA
Cc:        LYNCH@A.ISI.EDU
Subject:   Network Management Meeting Scheduled


 

       FORMATION OF A NETWORK MANAGEMENT WORKING GROUP

 

The Internet Activities Board in conjunction with its Internet
Engineering Task Force is forming a Network Management
Working Group composed of representatives from the Internet
community and vendors of TCP/IP products. The group will
develop a set of RFCs that define tools to manage systems
containing multiple vendor TCP/IP products.  The working
group is expected to focus on detailing a framework for
management of TCP/IP based networks, the control and
monitoring information to be managed, and the protocols
necessary for the exchange of management information.   Near
term solutions that can result in vendor implementations will
be stressed.

 

The Working Group's first meeting will be held on May 5th,
1987, at TECHMART, the Silicon Valley Marketing Center, in
Santa Clara, CA, from 9-4 in Suite 125.  Adjacent to the
Doubletree Hotel and the Santa Clara Convention Center,
TECHMART is at 5201 Great America Parkway.  Please contact
Dan Lynch, Advanced Computing Environments, 408-996-2042,
if you plan to attend so proper arrangements may be made. The
meeting will be open to all users and vendors.



Lee LaBarre from the Mitre Corporation will chair this
meeting.  Please contact him at 617-271-8507 if you wish to
be included in the following agenda.



The agenda for the first meeting will include the following:

 

        - Discussion of the scope and schedule of the project.  A  
           candidate proposal will be presented.

        - Presentations on models for network management.  Lee 
           LaBarre will present the ISO and IEEE models.

        - Presentations on TCP/IP parameters to be managed.

        - Presentations on protocols for management exchanges.



A long term work list for the group is as follows:

 

        a) Agree on the scope of network management and the
areas of management to be addressed.  The possible areas
include:

 

                configuration management

                fault management

                performance management

                security management

                accounting management

 

           The group might reasonably choose to only address the
first three areas.

 

        b) Determine the management requirements in the chosen
areas.

 

        c) Determine a framework, or model, for network
management.  The group should examine models developed by
standards organizations such as ANSI and IEEE, and any
models being developed for management of the Arpanet or
MILNET.  If possible, the model should be based on existing
work done by the standards bodies.  This does not imply that
we should track evolving standards, but that we might benefit
from their work.  It may be desirable to develop a common
model to ease the management of networks that contain DoD
and ISO protocol suites.  Vendors could then use the same
network management system to manage products in both
suites.

 

        d) Determine for each layer of the DoD suite the
parameters to be managed, e.g., protocol parameters (timers,
max. no. of connections, max. segment size, no. of
retransmissions), statistics (counts on segments, octets sent
and received, refused connections, retransmissions, discarded
datagrams, etc).

 

        e) Determine the protocol for exchanging management
information. Candidates to be examined from the standards
area include ISO's Common Management Information Protocol
(CMIP) and the protocol defined by the IEEE for management
exchanges.  A protocol suitable for encoding management data
to be transferred among machines with heterogeneous storage
formats is CCITT X.409 (ISO ASN.1).

 

        f) Document the above decisions as a set of RFCs.

 



 



-------
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 87 23:31:09 GMT
From:      nbires!opus!chm@ucbvax.Berkeley.EDU  (Paul Chmielewski)
To:        tcp-ip@sri-nic.arpa
Subject:   4.3 TCP keep-alive question

  The 4.2 TCP keep-alive implementation is described two different ways.
According to the comment in tcp_timer.h, when the TCPT_KEEP timer expires
we should send the following segment to elicit a response from our peer:
	<SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK>
But, the actual implementation in our version of tcp_timer.c sends:
	<SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK>

Note that the first segment contains an invalid SEQ and the second
contains both an invalid SEQ and an invalid ACK.

My question is, do we really need to lie about what we've received by 
sending an invalid ACK or is the invalid SEQ enough to elicit a response?

-- 

Paul Chmielewski		
NBI Inc., Boulder, CO		chm@nbires.UUCP or chm@nbires.NBI.COM
(303) 444-5710

-- 

Paul Chmielewski		
NBI Inc., Boulder, CO		chm@nbires.UUCP or chm@nbires.NBI.COM
(303) 444-5710
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 08:17:11 EST
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP on an HP 3000

Yes, it is true.  DARPA paid BBN for an implementation of TCP/ip
on the HP3000.

dennis
-------

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 10:39:04 EST
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Packet Tracing

In the 4.2BSD/4.3BSD world, the program is /etc/trpt, which stands for
TRansliterate Protocol Trace.  It's documented in section 8 of the
UNIX manuals.

By setting SO_DEBUG with a setsockopt() call, you can cause TCP
protocol traces to be accumulated in the kernel.  This is done by
routine tcp_debug() in the file ~sys/netinet/tcp_debug.c.  It keeps
the data in a compacted format in a circular buffer, that /etc/trpt
reads out and formats.

Unfortunately, at least in SunOS Version 3.0, Sun has removed the
actual code for tcp_debug() in the kernel.  It only contains a return.
Of course, they still provide /etc/trpt, but it cusses that it can't
find the symbol for the buffer in the kernel.  I can't understand WHY
they did this, but they did.  I have in the past been able to get Sun
software support to send me a binary tcp_debug.o that has not been
lobotomized.  Alternatively you probably would have no problem
dropping the 4.2BSD code into the hole, you might also have to fix the
header file.

Other 4.2BSD vendors are more reasonable.  The code is all there in
Ultrix-32 Version 1.2.

The other frustrating problem is that some of the TCP applications
have no way to request them to set the debug option.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 11:22:14 EST
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip/IBM/ProNET

I'll have to repeat the standard incantation about LAN's and network
software (at the present state of the commercial art):

	The software is always slower than the LAN.

(Actually, there are some LANs you can buy where this might not be
the case, like Appletalk, but any LAN over 4 megabits/second this
will be the case.)

First of all, the DACU is not, per se, slow.  It is truly possible to
shove lots of data through it, IBM has really measured speeds well in
excess of one Mbyte/sec.  (See "Testing the DACU as a Channel
Attached PC", IBM form G320-3472.)  What is slow is the
time/transaction, not the actual transfer rate.  Thus, while one can
measure 96 Kbytes/sec for 4 Kbyte buffers, this falls to 19
Kbytes/sec for 512 byte bufers.

WISCNET and IBM's code are somewhat limited by using small buffers,
however they do perform tricks to aggregate multiple packets into one
channel transaction and cut overhead.  By doing this, one sees
typical performance in the 30 Kbytes/second range for FTP.

I will soundly agree that the ACC box is somewhat faster at the
hardware level than the DACU.  A 68000 running compiled code can
parse Channel Command Words faster than a PC running interpreted
code.  Both the DACU and the ACC use the DC-interlock channel
protocol.

However (no insult to ACC), the ACC TCP/IP will not run at 10
Mbits/sec (1.25 Mbytes/sec) at the TCP or FTP level.  One customer I
spoke with was getting about 30 Kbytes/sec, about the same as
WISCNET.

Obviously, both benchmarks are very rough numbers, and one could wage
benchmark wars to prove who is better.  However, they will always be
within an order of magnitude of each other, probably a power of two
of each other.

My suspicion is that nodoby has broken (or threatened) the 100
Kbytes/sec barrier for TCP/IP on VM or MVS.  By the way, that's not
shabby, ACF/VTAM is fairly slow stoking 3270's, channel attach
clusters aren't much faster than ones off a 56 kbaud line.

Basically, if you want to run VM, I'd say go for the
DACU/Wiscnet/ProNET solution.  If you want to run MVS, choose from
the many capable Ethernet vendors and use our router.  (If anyone
thinks I'm commercially biased towards the DACU, I make more money on
a router than on one ProNET-80 board.  I just like clean solutions.)

BTW, there's been a lot of discussion about things like this on the
IBM-NETS mailing list (requests to ibm-nets-request@devvax.tn.cornell.edu
on Internet or ibm-nets-request@bitnic on bitnet.)

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 11:55:15 EST
From:      STAHL@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: request for network number assignment

The NIC Hostmaster is the person who assigns network numbers.  I have
forwarded your message to the mailbox HOSTMASTER@SRI-NIC.ARPA.

- Mary Stahl / NIC
-------

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 11:58:00 EST
From:      whna@cgcha.UUCP.UUCP
To:        comp.protocols.tcp-ip
Subject:   request for network number assignment

Dear Sirs,
we have installed a network of different UNIX systems that are attached to an
Ethernet LAN. Today, the network consists of less than 10 hosts, some diskless
workstations and PC's with TCP/IP support. The network will grow soon and we
are planning to divide it into subnetworks using the internetwork routing
facilities existing at our systems.
To be ready for a connection to ARPAnet at a later time, I would like to get
a class B network number assigned. In addition, please let me know what the
conditions are for us as a commercial institution in the scientific area to
get attached to ARPAnet. What is the nearest ARPAnet node for us, and which
protocol is used to attach our main mail system to it (is it DDN 1822 HDH or
X.25 standard or basic protocol)?
Thanks for your information and probable activities arising at your side.
Best regards,
Heinz Naef (whna@cgcha.UUCP)

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 11:58:29 EST
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        comp.protocols.tcp-ip
Subject:   ICMP in ISO

From John Shriver:
> Another important aspect of ICMP echo reply is that it is Mandatory in
> the TCP/IP suite (see the latest Official ARPA Internet Protocols,
> where IP and ICMP are the only Mandatory protocols).  Using
> transport-level protocols in ISO for the same function will not be
> nearly as effective, for example a router (IS in ISO parlance)
> nominally has no use for transport protocols.  I would recommend to
> ISO designers to add a mandatory echo response at as low a level as
> possible in the architecture.  If the source routing trick does this,
> and is a mandatory capability of ISO 8473, great.  I would then ask
> the implementers to provide the necessary user program.


No, partial source routing is NOT mandatory in ISO 8473.  I admit,
I knew this when I suggested it, but I did it anyway.

However, from the responses I have seen on this issue, a lot of
people think ICMP ECHO is important.

We in X3S3.3 would like to be obliging, but are a little uneasy of
putting in an all purpose ping without understanding how it will be
used.  A lot of people may be using ECHO for things when some other
function may do more for that thing.  Since we are just now defining
management functions for the network and transport layers, we are in
a good position to provide a lot more than just pings.

I would like to get some feedback from all those dirty-fingernailed
pingers out there.

What EXACTLY do you use ICMP ECHO for?
Is there a better way to do what you want other than ICMP ECHO, but
you are using ICMP ECHO because it is the only thing available?
Are there things (management-wise) that you wish you could do,
but there is currently nothing standardized to do it with.

Of course, any other random comments are welcome.

> (But enough, this discussion really belongs on the ISO mailing
> list, see the CC: address...)

Yes and no.  While tcp-ip is obviously not going to go away, there
is no question (at least in my mind) that tp4-ip is on the way.  If
we (the ISO designers) don't get feedback from you (the experienced
tcp-ip designers) on these issues, then the ISO mailing list will
be nothing but a repeat of the tcp-ip mailing list, but delayed
5 or 10 years.  I think a lot of things belong on both lists.



While on the ICMP topic, I'd like to bring up another tidbit......
In addition to an error message which is just like SOURCE QUENCH,
there is a thing in ISO-IP called the congestion experienced bit.
It is a bandwidth free way of indicating to transport machines that
your congestion is getting up there, but not to the point where
packets are being thrown away.  This is how DEC does it, and it
seems to work for them.

Now the catches.  One, its optional.  However, optional doesn't
have to mean don't do it.  It is groups like COS
(Corporation for Open Systems), the NBS-ISO Workshop, and
GOSIP (or whoever is behind it) that ultimately decide these things.
Two, what a transport does when it receives such a bit is not
standardized (just like SOURCE QUENCH), nor is it standardized
when the bit gets set.  Again, COS, NBS, etc., are the places to
fight those battles.


	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 13:44:06 EST
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Tcp/Ip vs a store & forward network

Just got around to reading the Subj: msg and hope it's not too late
to point out that the desired effect (of passwordless "spoolers" via
FTP) can be achieved straightforwardly given the mechanisms of a
couple of my old (one ancient, actually) RFCs.  Since it would take
longer for me to find the numbers than to summarize, here goes:
Back in ~'73, when mail was done via FTP, we had a problem with
not having all Hosts able/willing to let given users in without
passwords (indeed, some Hosts didn't even demand USER commands,
muchless PASSs, but others demanded both).  In a little thing
called "What Is 'Free'?" (RFC # in the 500s, I expect), I suggested
that any mail senders which encountered the Login Expected FTP
code should use USER NETML and PASS NETML (and any mail receivers
on systems that demanded logins should duly cause the appropriate
accounts to be created).  Seems to me we could do the same thing
with "NETSPL" for the passwordless aspect of the current thing.
Then a year or two ago (and this one actually is in the latest
version of the FTP RFC), for some obscure reason I decided there
ought to be an FTP command for STOring under a Unique name for use
in all sorts of "pool" directory cases, so if I remembered that
one's number and the other one's I could have just said Why not use
the RFC 5xx and 9xx tricks?  (By the way, the 5xx trick was duly
implemented and worked for years [even if nobody other than
Multics did the receiving end part].)

If my current state of seemingly eternal jetlag hasn't caused me
to miss the point, I think that should do it.  Do I need to
write another RFC to forget the number of?

cheers, map

P.S. Lest anybody misunderstand, I was at Multics at the time and
invented the fictious mail receiver thing in self defense; cf. pp.
84-5 of The Book.
-------

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 13:48:20 EST
From:      blumenth@UCBVAX.BERKELEY.EDU (Steve Blumenthal)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP on an HP 3000

BBN had a contract from DARPA to develop TCP/IP for the HP3000.  Under
that effort we also developed user and server TELNET and user FTP.  This
software required modifications to the HP3000 operating system and ran
on an HP3000 Series 3 under MPE IV.  We completed this effort in 1983
and delivered the software to White Sands Missle Range, where it was
modified to run on an HP3000 Series 44 system under the MPE V/P
operating system.  (See attached note from Ken Terry at WSMR from 1985)
Because we needed access to the HP3000 operating system sources, we had
to sign a non-disclosure agreement with HP.  This agreement restricts
our ability to redistribute this software except to U.S. government
sites as directed by DARPA.

Because BBN is not heavily into the development of HP3000 software, we
tried to give our software to HP to have them support it and track
subsequent HP3000 operating system and hardware improvements.  To date,
HP has not taken us up on our offer.  They may be in the process of
developing TCP/IP for the HP3000 themselves, but at this point, we have
no current contacts at HP. 

Steve Blumenthal
BBN Labs



---------------------------------------------------------------------------
Received: from miser.arpa by BBN-VAX.ARPA id a001802; 5 Sep 85 9:38 EDT
Received: by miser.ARPA (4.12/4.7)
	id AA03774; Thu, 5 Sep 85 07:38:24 mdt
Date: Thu, 5 Sep 85 07:38:24 mdt
From: Kenneth Terry <kterry@MISER.ARPA>
Message-Id: <8509051338.AA03774@miser.ARPA>
To: Winston B. Edmond <wbe@BBN-VAX.ARPA>

Subject: conversion of software.

  Thought I would let you know the status of the conversion effort from
MPE V/P to  MPE V/E.  I currently have TCP/IP, user TELNET, and user FTP
running but still have significant work to do on the Pseudo-drivers for
server telnet.  I have received some help from HP in terms of changes they
have made in the operating system (i.e. new intrinsics) but they haven't
really gone out of their way to be too helpful. 

  Thanks much for all the help you gave me.  You without a doubt saved me
many months worth of searching and scratching.

                                     Ken.

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14 Apr 87 13:48:20 EST
From:      Steve Blumenthal <blumenth@VAX>
To:        "Dennis G. Perry" <PERRY@VAX.DARPA.MIL>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  TCP on an HP 3000
BBN had a contract from DARPA to develop TCP/IP for the HP3000.  Under
that effort we also developed user and server TELNET and user FTP.  This
software required modifications to the HP3000 operating system and ran
on an HP3000 Series 3 under MPE IV.  We completed this effort in 1983
and delivered the software to White Sands Missle Range, where it was
modified to run on an HP3000 Series 44 system under the MPE V/P
operating system.  (See attached note from Ken Terry at WSMR from 1985)
Because we needed access to the HP3000 operating system sources, we had
to sign a non-disclosure agreement with HP.  This agreement restricts
our ability to redistribute this software except to U.S. government
sites as directed by DARPA.

Because BBN is not heavily into the development of HP3000 software, we
tried to give our software to HP to have them support it and track
subsequent HP3000 operating system and hardware improvements.  To date,
HP has not taken us up on our offer.  They may be in the process of
developing TCP/IP for the HP3000 themselves, but at this point, we have
no current contacts at HP. 

Steve Blumenthal
BBN Labs



---------------------------------------------------------------------------
Received: from miser.arpa by BBN-VAX.ARPA id a001802; 5 Sep 85 9:38 EDT
Received: by miser.ARPA (4.12/4.7)
	id AA03774; Thu, 5 Sep 85 07:38:24 mdt
Date: Thu, 5 Sep 85 07:38:24 mdt
From: Kenneth Terry <kterry@MISER.ARPA>
Message-Id: <8509051338.AA03774@miser.ARPA>
To: Winston B. Edmond <wbe@BBN-VAX.ARPA>

Subject: conversion of software.

  Thought I would let you know the status of the conversion effort from
MPE V/P to  MPE V/E.  I currently have TCP/IP, user TELNET, and user FTP
running but still have significant work to do on the Pseudo-drivers for
server telnet.  I have received some help from HP in terms of changes they
have made in the operating system (i.e. new intrinsics) but they haven't
really gone out of their way to be too helpful. 

  Thanks much for all the help you gave me.  You without a doubt saved me
many months worth of searching and scratching.

                                     Ken.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 15:36:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP on an HP 3000

Dennis,

BBN did a TCP to assure that the DARPA HP3000 MIS system could work
after the TCP/IP shift of 1983. My recollection of the work is that
BBN did the implementation and struggled somewhat to obtain the
technical information it needed about the operating system MPE-X
(I forget which version).  In the meantime, HP has apparently developed 
a TCP for a number of machines in its product line. Whether it has 
one commercially for the MPE operating system isn't clear. They have
imported the Berkeley 4.2 (or 3) BSD code, I believe, to operate
on the Spectrum series machines and possibly for others in its
product line. 

A possible point of contact on protocols is Wim Rollandts who has
a senior position at HP dealing with communications. Until recently
he ran their International Networks Division (IND - I think I have
the initials right even if I have messed up the name). IND is
located at HP's corporate facility in Cupertino. The current
Information Networks Division general manager is Dan Warmenhoben
who can be reached at (408) 447-3506. I tried calling him just a
few moments ago but both lines to his office were busy, so I
don't know what the status of HP's TCP is at the moment.

Hope this helps.

Vint

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 15:40:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3 TCP keep-alive question

Paul,

In the absence of a no-op, something which sends no data but is guaranteed to
elicit a response is the option chosen.

Vint

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1987 14:44:06 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        Henry Nussbacher <HANK%BARILVM.BITNET@WISCVM.WISC.EDU>
Cc:        Barry Shein <bzs@Bostonu>, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Tcp/Ip vs a store & forward network
Just got around to reading the Subj: msg and hope it's not too late
to point out that the desired effect (of passwordless "spoolers" via
FTP) can be achieved straightforwardly given the mechanisms of a
couple of my old (one ancient, actually) RFCs.  Since it would take
longer for me to find the numbers than to summarize, here goes:
Back in ~'73, when mail was done via FTP, we had a problem with
not having all Hosts able/willing to let given users in without
passwords (indeed, some Hosts didn't even demand USER commands,
muchless PASSs, but others demanded both).  In a little thing
called "What Is 'Free'?" (RFC # in the 500s, I expect), I suggested
that any mail senders which encountered the Login Expected FTP
code should use USER NETML and PASS NETML (and any mail receivers
on systems that demanded logins should duly cause the appropriate
accounts to be created).  Seems to me we could do the same thing
with "NETSPL" for the passwordless aspect of the current thing.
Then a year or two ago (and this one actually is in the latest
version of the FTP RFC), for some obscure reason I decided there
ought to be an FTP command for STOring under a Unique name for use
in all sorts of "pool" directory cases, so if I remembered that
one's number and the other one's I could have just said Why not use
the RFC 5xx and 9xx tricks?  (By the way, the 5xx trick was duly
implemented and worked for years [even if nobody other than
Multics did the receiving end part].)

If my current state of seemingly eternal jetlag hasn't caused me
to miss the point, I think that should do it.  Do I need to
write another RFC to forget the number of?

cheers, map

P.S. Lest anybody misunderstand, I was at Multics at the time and
invented the fictious mail receiver thing in self defense; cf. pp.
84-5 of The Book.
-------
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Tue, 14-Apr-87 15:54:00 EST
From:      CERF@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: commercial network economies vs. ARPANET

David,

I would add to your comments on economics that Telenet is a
commercial supplier so its charging policies should be
configured to supply a profit. Telenet also has to pay the
overhead of sales/marketing/billing/collection which the
ARPANET laregly avoids (not entirely, as the DDN folks
have to handle tracking of costs for circuits and allocating
charges to the funding organizations - but this is on a
more coarse scale than the Telenet accounting).

Vint

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1987 16:36-EDT
From:      CERF@A.ISI.EDU
To:        PERRY@VAX.DARPA.MIL
Cc:        dartvax!richb@VAX.DARPA.MIL, mod-protocols-tcp-ip%linus@mitre-bedford.ARPA
Subject:   Re: TCP on an HP 3000
Dennis,

BBN did a TCP to assure that the DARPA HP3000 MIS system could work
after the TCP/IP shift of 1983. My recollection of the work is that
BBN did the implementation and struggled somewhat to obtain the
technical information it needed about the operating system MPE-X
(I forget which version).  In the meantime, HP has apparently developed 
a TCP for a number of machines in its product line. Whether it has 
one commercially for the MPE operating system isn't clear. They have
imported the Berkeley 4.2 (or 3) BSD code, I believe, to operate
on the Spectrum series machines and possibly for others in its
product line. 

A possible point of contact on protocols is Wim Rollandts who has
a senior position at HP dealing with communications. Until recently
he ran their International Networks Division (IND - I think I have
the initials right even if I have messed up the name). IND is
located at HP's corporate facility in Cupertino. The current
Information Networks Division general manager is Dan Warmenhoben
who can be reached at (408) 447-3506. I tried calling him just a
few moments ago but both lines to his office were busy, so I
don't know what the status of HP's TCP is at the moment.

Hope this helps.

Vint
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1987 16:40-EDT
From:      CERF@A.ISI.EDU
To:        nbires!opus!chm@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: 4.3 TCP keep-alive question
Paul,

In the absence of a no-op, something which sends no data but is guaranteed to
elicit a response is the option chosen.

Vint
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 1987 16:54-EDT
From:      CERF@A.ISI.EDU
To:        ROODE%BIONET@SUMEX-AIM.STANFORD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: commercial network economies vs. ARPANET
David,

I would add to your comments on economics that Telenet is a
commercial supplier so its charging policies should be
configured to supply a profit. Telenet also has to pay the
overhead of sales/marketing/billing/collection which the
ARPANET laregly avoids (not entirely, as the DDN folks
have to handle tracking of costs for circuits and allocating
charges to the funding organizations - but this is on a
more coarse scale than the Telenet accounting).

Vint
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 03:48:47 EST
From:      martillo@ATHENA.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   TCP on an HP 3000


If you want information about TCP on an HP 3000, you might
try writing to sax%enr.prime.com@eddie.mit.edu.  I think he worked
on this project.

Yaqim Martillo

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 08:18:47 EST
From:      MAILER-DAEMON@VAX.DARPA.MIL.UUCP
To:        comp.protocols.tcp-ip
Subject:   Returned mail: Host unknown


   ----- Transcript of session follows -----
550 tcp-ip@rsi-nic... Host unknown

   ----- Unsent message follows -----
Posted-Date: Wed 15 Apr 87 09:18:44-EDT
Received-Date: Wed, 15 Apr 87 09:18:47 EDT
Received: by vax.darpa.mil (5.54/5.51)
	id AA06849; Wed, 15 Apr 87 09:18:47 EDT
Date: Wed 15 Apr 87 09:18:44-EDT
From: Dennis G. Perry <PERRY@VAX.DARPA.MIL>
Subject: [Harry Forsdick <forsdick@Diamond.BBN.COM>: Re:  Multimedia Mail.]
To: tcp-ip@rsi-nic
Cc: perry@VAX.DARPA.MIL
Message-Id: <545494724.0.PERRY@VAX.DARPA.MIL>
In-Reply-To: <8704142347.AA05768@perry
Mail-System-Version: <VAX-MM(205)+TOPSLIB(126)@VAX.DARPA.MIL>

I have had several similar questions to the ones answered by
Harry below.  I did not ask Harry if I could send his note to a
wider audience, so don't take anything Harry says as an indorsement
of anything.  Just information!!!

dennis
                ---------------

Posted-Date: Tue, 14 Apr 87 20:08:19 AST
Received-Date: Tue, 14 Apr 87 20:09:51 EDT
Received: from SILICA.BBN.COM by vax.darpa.mil (5.54/5.51)
	id AA05811; Tue, 14 Apr 87 20:09:51 EDT
Received: by Diamond.BBN.COM; Tue, 14 Apr 87 20:08:19 AST
Date: Tue, 14 Apr 87 20:08:19 AST
From: Harry Forsdick <forsdick@Diamond.BBN.COM>
Message-Id: <8704150008.AA05200@Diamond.BBN.COM>
To: estrin@usc-oberon.arpa
Subject: Re:  Multimedia Mail.
Cc: Perry@vax.darpa.mil, nsfnet@sh.cs.net

Debbie,

Diamond currently runs only on SUN workstations.  As part of the
EXPRES project we are porting Diamond to PC/RT's, DEC MicroVax GPX
and Apollo DN 3000's.  This will run under the X window system.
BBN is doing the MicroVax port and U of M is doing the PC/RT and
Apollo DN3000 port.  All of the ports are dependent on the appearance
of X.11 which is due mid-Summer.

So, my advice is, get a SUN for the short term.  Diamond will run on an RT
in the long-term.

Regards,

	Harry
-------
-------
-------

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 10:44:36 EST
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP in ISO

As someone said recently for why you want ICMP ECHO required is for debugging.
The application is to determine connectivity which you can not associate with
gateway mechanisms since routing updates are broken half the time. You really
need a simple way of to see if some node in the network tree is there.  You
test node A, you test node B and then test node C and then try X. This is
usually neccessary if you are trying to answer the question, "Why can't I talk
to X?".

The other things that PINGing is good for is testing for drop tests, different
packet sizes and random data failures. There are a variety of failure modes
related to interfaces, translating a packet from one network to another,
congestion versus media, packet sizes and a host of other conditions.

Basic horror stories include the following:
	SDLC interface that paused a bit longer between bits after 256bytes,
	the interface was correct but the old piece of garbage hardware on 
	the receiving side was slightly off...It would randomly pick a bit
	value for that bit. Pings using different packet sizes and data
	showed this.

	Oscillation failures between gateways. The gateways would believe a
	network was done when it is was up and vice versa. Pings helped
	detect this incorrect knowledge in the gateways.

	ARP mechanism is busted. A PING on one host said a host was up but
	on the busted host said it was down. 

	Connections dropping during end of day. PINGs showed that occasionally
	for a minute or so, all packets were lost. Turned out interface under
	high load would occasionally shut itself off....probably related to
	input buffer ring size.

In many cases, the thing that saved us was the fact that ICMP ECHO was
required. We could point at an implementation and say you are not playing
by the game rules and would treat them very badly...It never happened but
the ability is there.

I believe in the Ethernet configuration testing protocol. I look at ICMP
ECHO with source routing as being a mid-level network testing mechanism.
Losing this ability would hamper our ability to quickly track down problems.

If ISO has a better mechanism then simple ECHOs and ECHOs with source
routes, I would love to hear about it on this list since I am certainly
eager to learn better and faster ways to isolate network failures.

-Rudy

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 12:05:00 EST
From:      JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   sun manuals


     I have a Sun 3/180.  We're just starting to use it.  The manuals 
are as yet incomprehensible to me.  Anyone know where to look for calls 
to the tcp/ip/telnet functionality?

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15 Apr 87 12:05 EST
From:      "I am only an egg." <JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   sun manuals
     I have a Sun 3/180.  We're just starting to use it.  The manuals 
are as yet incomprehensible to me.  Anyone know where to look for calls 
to the tcp/ip/telnet functionality?

USnail:
          Chris Johnson
          Academic Computer Services
          Northeastern University 39RI
          360 Huntington Ave.
          Boston, MA. U.S.A. 02115
AT&T:     (617) 437-2335
CSNET:    johnson@nuhub.acs.northeastern.edu
ARPANET:  johnson%nuhub.acs.northeastern.edu@relay.cs.net
BITNET:   johnson%nuhub.acs.northeastern.edu@csnet-relay

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 13:09:00 EST
From:      netnews@orstcs.UUCP
To:        comp.protocols.tcp-ip
Subject:   4.3 TCP keep-alive question


/* Written  3:31 pm  Apr 13, 1987 by chm@opus.UUCP in orstcs:comp.protocols.tcp-ip */
/* ---------- "4.3 TCP keep-alive question" ---------- */

  The 4.2 TCP keep-alive implementation is described two different ways.
According to the comment in tcp_timer.h, when the TCPT_KEEP timer expires
we should send the following segment to elicit a response from our peer:
	<SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK>
But, the actual implementation in our version of tcp_timer.c sends:
	<SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK>

Note that the first segment contains an invalid SEQ and the second
contains both an invalid SEQ and an invalid ACK.

My question is, do we really need to lie about what we've received by 
sending an invalid ACK or is the invalid SEQ enough to elicit a response?

-- 

Paul Chmielewski		
NBI Inc., Boulder, CO		chm@nbires.UUCP or chm@nbires.NBI.COM
(303) 444-5710

-- 

Paul Chmielewski		
NBI Inc., Boulder, CO		chm@nbires.UUCP or chm@nbires.NBI.COM
(303) 444-5710
/* End of text from orstcs:comp.protocols.tcp-ip */

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 15:05:00 EST
From:      SAC.AFGWC-SDMC@E.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Request For Information

It was suggested that I send our message to you by Dale Chase 
<chase@venera.isi.arpa>.  Your help would be greatly appreciated.

--  Tim J. Hern
	
Begin forwarded message
Received: By E.ISI.EDU via direct-append with Hermes; 26 Feb 87 15:14:15-CST
Date: 26 Feb 1987 15:14-CST
From: SAC.AFGWC-SDMC@E.ISI.EDU
To: ACTION@A.ISI.EDU
Cc: SAC.AFGWC-SDMC@E.ISI.EDU
Subject: Request on information on HYPERchannel
Message-ID: <[E.ISI.EDU]26-Feb-87 15:14:14.SAC.AFGWC-SDMC>
Sender: SAC.AFGWC-SDMC@E.ISI.EDU

1.  We are looking for users, special interest groups or vendors that have 
information on techniques/products that can be used to monitor our Network 
Systems Corporation (NSC) HYPERchannel, a high speed, radio-frequency, 
cable-based broadcast computer network.  We are looking for 

software/hardware 
to:

   -  Monitor the frequency of specific data transfers from host to host.  

In other words, "what is going where."  

   -  Monitor network throughput. 

   -  Get information on host-to-host transmission delays.

   -  Get information on how long data is in queue before it is transmitted. 



   -  Monitor the size of the data being transferred. 

   -  Monitor the loading on the source computer and receiving computer 

during 
      the transmission of the data.

   -  Monitor the amount of CPU resources the actual transmission takes.

   -  Track the shipment of data between two database machines (specifically
Sperrys).

2.  Our HYPERchannel allows the following communication configurations:  

Intra Sperry, intra VAX, Sperry to/from Vax and Sperry to/from Cray.  We 

have the 
following kinds of computers:

   -  Sperry 1100/82s.

   -  Sperry 1100/72s.

   -  Sperry 1100/91s.

   -  DEC VAX 11/780s. 

   -  A Cray X-MP.

3.  We wrote the communication software residing on the Sperry 1100s.  

Vendors wrote the communication software residing on the Vax computers and 

Cray.   The following chart shows which communication software we have 

written and which software vendors have written:

                          "AUTHOR OF COMMUNICATION SOFTWARE"

           "USAF"        "USAF"  "Harris"      "Harris"  "Sperry"      

"Sperry"
         

----------------------------------------------------------------------
         |  1100s <--> 1100s
 HOST    |
         |  1100s <------------> Vax
COMPUTER|
         |                         Vax <------> Vax
         |
         |                                                 1100s <---> Cray


4.  We need information on the following subjects:  

   -  User written communication software which can be used on HYPERchannel.

      -  We would like users to send us their evaluations of their 

HYPERchannel communication software, i.e., its advantages and disadvantages 

and whether the users are satisfied with it.

   -  Network monitoring software/techniques, such as NSC's Network 

Recording Facility, which will be available in mid 1987.  This software will 

show data flow on a network.  It is a "passive" system which receives 

records from other systems on the network.  

   -  Commercial communication monitoring software, such as NSC's Network
Monitor software, as well as user created software, which monitors the 

"health" of the NSC hardware.




Tim J. Hern, USAF, Data Flow Administrator









          --------------------
End forwarded message
		

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 1987 15:05-CDT
From:      SAC.AFGWC-SDMC@E.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Request For Information, [SAC.AFGWC-SDMC@E.ISI.EDU: Request on information on HYPERc...]
It was suggested that I send our message to you by Dale Chase 
<chase@venera.isi.arpa>.  Your help would be greatly appreciated.

--  Tim J. Hern
	
Begin forwarded message
Received: By E.ISI.EDU via direct-append with Hermes; 26 Feb 87 15:14:15-CST
Date: 26 Feb 1987 15:14-CST
From: SAC.AFGWC-SDMC@E.ISI.EDU
To: ACTION@A.ISI.EDU
Cc: SAC.AFGWC-SDMC@E.ISI.EDU
Subject: Request on information on HYPERchannel
Message-ID: <[E.ISI.EDU]26-Feb-87 15:14:14.SAC.AFGWC-SDMC>
Sender: SAC.AFGWC-SDMC@E.ISI.EDU

1.  We are looking for users, special interest groups or vendors that have 
information on techniques/products that can be used to monitor our Network 
Systems Corporation (NSC) HYPERchannel, a high speed, radio-frequency, 
cable-based broadcast computer network.  We are looking for 

software/hardware 
to:

   -  Monitor the frequency of specific data transfers from host to host.  

In other words, "what is going where."  

   -  Monitor network throughput. 

   -  Get information on host-to-host transmission delays.

   -  Get information on how long data is in queue before it is transmitted. 



   -  Monitor the size of the data being transferred. 

   -  Monitor the loading on the source computer and receiving computer 

during 
      the transmission of the data.

   -  Monitor the amount of CPU resources the actual transmission takes.

   -  Track the shipment of data between two database machines (specifically
Sperrys).

2.  Our HYPERchannel allows the following communication configurations:  

Intra Sperry, intra VAX, Sperry to/from Vax and Sperry to/from Cray.  We 

have the 
following kinds of computers:

   -  Sperry 1100/82s.

   -  Sperry 1100/72s.

   -  Sperry 1100/91s.

   -  DEC VAX 11/780s. 

   -  A Cray X-MP.

3.  We wrote the communication software residing on the Sperry 1100s.  

Vendors wrote the communication software residing on the Vax computers and 

Cray.   The following chart shows which communication software we have 

written and which software vendors have written:

                          "AUTHOR OF COMMUNICATION SOFTWARE"

           "USAF"        "USAF"  "Harris"      "Harris"  "Sperry"      

"Sperry"
         

----------------------------------------------------------------------
         |  1100s <--> 1100s
 HOST    |
         |  1100s <------------> Vax
COMPUTER|
         |                         Vax <------> Vax
         |
         |                                                 1100s <---> Cray


4.  We need information on the following subjects:  

   -  User written communication software which can be used on HYPERchannel.

      -  We would like users to send us their evaluations of their 

HYPERchannel communication software, i.e., its advantages and disadvantages 

and whether the users are satisfied with it.

   -  Network monitoring software/techniques, such as NSC's Network 

Recording Facility, which will be available in mid 1987.  This software will 

show data flow on a network.  It is a "passive" system which receives 

records from other systems on the network.  

   -  Commercial communication monitoring software, such as NSC's Network
Monitor software, as well as user created software, which monitors the 

"health" of the NSC hardware.




Tim J. Hern, USAF, Data Flow Administrator









          --------------------
End forwarded message
		
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Wed, 15-Apr-87 17:59:00 EST
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Request For Information...

Does Network Systems Corp have any aswers to your questions?

Vint

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 1987 18:59-EDT
From:      CERF@A.ISI.EDU
To:        SAC.AFGWC-SDMC@E.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Request For Information...
Does Network Systems Corp have any aswers to your questions?

Vint
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Apr-87 00:59:23 EST
From:      sch@sequent.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP in ISO

It seems to me that the ISO attitude is that all vendors will have
perfect hardware and software.  This is obviously not true in the real
network swamp.

Pinging hosts is a useful tool just as a hardware tech checks cable continuities
with an Ohm meter.  It is always useful to verify things are working at
the lowest level and trace the problem up through the levels.
The more protocol levels  in between the less useful the tool becomes.

- Steve Hemminger
- Network PIE
- Sequent Computer Systems

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Apr-87 16:13:21 EST
From:      TUCKER@SUMEX-AIM.STANFORD.EDU (Robert Tucker)
To:        comp.protocols.tcp-ip
Subject:   X.25 to Ethernet (TCP/IP) Gateway

We need a gateway which will provide for terminal sessions between PADs
and Hosts on X.25 Public Data Networks and Ethernets (using TCP/IP).  We
are interested in both turn-key black-box schemes and software packages
which might allow small UNIX machines currently on our Ethernet to perform
this function.  The additional ability to support multi X.25 ports both
for backup paths and sub-addressed hosts would be a help.

  Bob Tucker
-------

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Apr-87 16:16:51 EST
From:      tmallory@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP in ISO

I just wanted to add to the debugging scenarios presented by Rudy.

I have on many occasions used the message generators in our gateways to ping
hosts in order to determine just where a routing problem may lie.  The receipt
of an echo reply packet by the gateway generates a trap message which is sent
to the monitoring center.

Using a gateway on a network to which the host is directly attached
can show whether the host is able to communicate at all.  By merely changing
the source address in the ping to be the other side of the gateway, one can
determine whether the host has the necessary routing information.  Depending
on the number of gateways under my control along the path, I can learn much
about the type of problem.

We often get complaints from users who cannot connect to some other host using
tcp.  It is very frequently case that one of the hosts does not have a route
to the other network, but occasionally the problem turns out to be protocol
related, as when it turned out that Sun's telnet could not use Class C
internet addresses for opening connections in one direction.   I don't
remember whether it was client or server mode now.

Such a simple low level tool can be implemented in virtually any network
device, though even 4.2 bsd got it wrong for a while, so that a minimum of 48
bytes needed to be sent to get a reply where only 28 should be necessary.
The more complex your debugging aids, the more likely they won't work when you
need them.

Tracy Mallory
BBN Communciations
617-497-3193

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 87 17:16:51 D (Thu)
From:      tmallory@ccv.bbn.com
To:        tsuchiya@gateway.mitre.org
Cc:        iso@nrtc.northrop.com, tcp-ip@sri-nic.ARPA, x3s33-interest@h.cs.cmu.edu tmallory@ccv.bbn.com
Subject:   Re: ICMP in ISO
I just wanted to add to the debugging scenarios presented by Rudy.

I have on many occasions used the message generators in our gateways to ping
hosts in order to determine just where a routing problem may lie.  The receipt
of an echo reply packet by the gateway generates a trap message which is sent
to the monitoring center.

Using a gateway on a network to which the host is directly attached
can show whether the host is able to communicate at all.  By merely changing
the source address in the ping to be the other side of the gateway, one can
determine whether the host has the necessary routing information.  Depending
on the number of gateways under my control along the path, I can learn much
about the type of problem.

We often get complaints from users who cannot connect to some other host using
tcp.  It is very frequently case that one of the hosts does not have a route
to the other network, but occasionally the problem turns out to be protocol
related, as when it turned out that Sun's telnet could not use Class C
internet addresses for opening connections in one direction.   I don't
remember whether it was client or server mode now.

Such a simple low level tool can be implemented in virtually any network
device, though even 4.2 bsd got it wrong for a while, so that a minimum of 48
bytes needed to be sent to get a reply where only 28 should be necessary.
The more complex your debugging aids, the more likely they won't work when you
need them.

Tracy Mallory
BBN Communciations
617-497-3193
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Apr-87 18:50:00 EST
From:      NIC@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Sendmail files

The NIC has collected some sendmail configuration files for use
by internet or internet-uucp sites.  They are for sites running
sendmail with 4.2BSD without domain resolvers (i.e. still using
the host table).  The files and documentation on how to modify
them for your particular site are courtesy of Erik Fair.  You 
can FTP them from the SRI-NIC.ARPA host using the pathnames

NETINFO:SENDMAIL-CF-DOC.TXT
NETINFO:SENDMAIL-INTERNET-GENERIC.TXT
NETINFO:SENDMAIL-GENERIC.TXT

The DDN Network Information Center
-------

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 87 17:50:51 GMT
From:      medin@cod.nosc.mil  (Ted Medin)
To:        tcp-ip@sri-nic.arpa
Subject:   Looking for ip/tcp mdqs

 We are looking for an mdqs implementation on a dec vax runing vms 4.x
or so.
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16-Apr-87 22:56:04 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP in ISO

We should not lose sight of the fact that echo mechanisms are embedded in
many protocols besides ICMP. Both TCP and UDP have echo ports, for
example. DECnet has an echo "mirror" mechanism as well. We might argue
about the detail protocol involved or whether it belongs as an intrinsic
feature of each protocol (as I believe) or belongs in a pervasive network
management, but I think we can all agree the mechanisms are necessary for
any real network. As one who often has had echo goo smeared up to my
clavicle, I can observe there have been numerous cases where something
was found to be working just fine at the IP level was broken at the
TCP/UDP level as diagnosed by the TCP/UDP echo mechansim. I submit
we shouldn't stop at ICMP and should strive for these mechanisms at each
and every level in the protocol stack.

DavU>

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 02:47:35 EST
From:      CASNER@VENERA.ISI.EDU (Stephen Casner)
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP in ISO

We have used ICMP echoes frequently in testing the Wideband Satellite Net
and paths through the gateways that attach to it.  Aside from simply probing
for connectivity, using ICMP echoes allowed us to measure packet loss and
misordering characteristics that would be harder to discern by examination
of the behaviour of a transport protocol.  It is easy for an ICMP echo
tester to send packets at a regular rate and observe the delay distribution
of the echo replies.  The transmission rate of a transport protocol will
likely be affected by network anomolies, clouding the measurement.  We had
observed unexpected behavior in the NETBLT protocol we were testing; with
ICMP echoes we were able to get a better understanding of the performance
of the network to serve as a basis for further NETBLT tests.

One drawback of testing with ICMP echoes is that the path must be a round
trip.  Network performance may be different under unidirectional load.
ICMP-like datagrams are useful for testing between a separate transmitter
and receiver as well, but transmission time is then only relative rather
than absolute unless synchronized clocks are available (oh so nice to have!).

							-- Steve Casner
-------

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 04:30:24 EST
From:      gds@SPAM.ISTC.SRI.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP in ISO


     We should not lose sight of the fact that echo mechanisms are embedded in
     many protocols besides ICMP. Both TCP and UDP have echo ports, for
     example.
     ...
     I submit we shouldn't stop at ICMP and should strive for these
     mechanisms at each and every level in the protocol stack.

Dave,

I agree with your points.  However it may be difficult to do this in
practice.  I took a random sampling of hosts I usually ping to measure
their round-trip times and tried connecting to their tcp echo ports
instead.  Out of all the hosts I tried, none but the Unix 4.3 hosts were
listening on the echo port (and even some of them were not listening).

It's trivial to write an echo server, but for some reason most hosts
don't seem to support it.  Transport-level echo services are not
required in the same sense that ICMP echo is required.  If we want to be
assured that we can do debugging at all layers, not only must we push
for debugging protocols at all levels of the protocol stack but
encourage everyone to implement and use these protocols.

--gregbo

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 08:37:36 EST
From:      jbvb@GAAK.LCS.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Ping & debugging tools

We include a Ping in every copy we ship.  It is the tool of choice for
dealing with support calls of the form "... I tried telnet and it just
timed out...", because it bypasses a lot of higher-level problems:
ICMP doesn't care if the PC is in its host table, trailers don't get
involved because the packets are short, everything including gateways
ought to respond to it, etc.  Our Ping displays extensive network
statistics, and can act as a server, and in this mode, we have used it
to diagnose various customer problems caused by a crazed machine
(not ours) generating excessive broadcasts of one kind or another. 

Other debugging tools we find useful on a workstation include programs
for explicitly checking nameservers, displaying who responded to a
query and what they responded with.  For instance, as of Wednesday,
4/15, DCN1's IEN-116 UDP service was giving 128.6.4.7 for
MVS.RUTGERS.EDU, whose un-transposed address is 128.6.7.4.  I could
tell I was getting a bogus address using other programs, but I would
have had to read through a lot of debugging trace to find out who, and
it wouldn't have been presented in easy-to-read formats.

James B. VanBokkelen
FTP Software Inc.
jbvb@ai.ai.mit.edu

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17 Apr 87 13:07:47 -0400
From:      Leo Lanzillo <leo@SH.CS.NET>
To:        Robert Tucker <TUCKER@sumex-aim.stanford.edu>
Cc:        TCP-IP@SRI-NIC.ARPA, PFernandez@sumex-aim.stanford.edu

Subject: Re: X.25 to Ethernet (TCP/IP) Gateway 
In-reply-to: Your message of Thu, 16 Apr 87 14:13:21 -0700.
             <12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU> 
Fcc: outbox
--------

	We need a gateway which will provide for terminal sessions
	between PADs and Hosts on X.25 Public Data Networks and
	Ethernets (using TCP/IP).  We are interested in both turn-key
	black-box schemes and software packages which might allow small
	UNIX machines currently on our Ethernet to perform this
	function.  The additional ability to support multi X.25 ports
	both for backup paths and sub-addressed hosts would be a help.

CSNET distributes under license software which provides a TCP/IP over
X.25 interface.  The software, known as XNI, runs under UNIX on a vax
and currently works with an Interactive Systems Incard X.25 device.
Work is under way to make the software work with ACC X.25 devices.

The software supports TCP/IP over the public data network and enables
the host to act as an IP gateway between other hosts on the PDN and
whatever is behind the host.

In addition to the TCP/IP support, XNI implements PAD functionality.
It can be used as a remote terminal  to connect to another host on the
PDN or to act as a tty port on the gateway host.  To reach other
machines behind the gateway from the PDN, one could either telnet from
the shell or have rlogin be your shell.

More info is available from cic@sh.cs.net

Leo Lanzillo
leo@sh.cs.net
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 11:32:40 EST
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP in ISO

Greg,

In a random search I found about half the dozen of so hosts I tried did
respond to the TCP Echo port, including all the 4.2s and 4.3s I tried
(but not the Suns). At least one Multics machine and all the Fuzzballs I
tried responded as well. The SATNET SIMPs have long been used as a tool
to debug reassembly implementations, since SATNET can fragment and
dis-order datagrams in glorious ways. Nevertheless, your comment is
accurate in that the TCP/UDP Echo service is certainly not ubiquitous.

It is interesting to note that a TCP/UPD Echo service is trivial to
implement, since all it takes is a swap of addresses (and ports in some
implementations), which makes it no more intrusive than ICMP Echo.
However, this defeats the purpose of the service, which is to verify
that the TCP/UPD protocol layer itself is working properly. An interesting
side issue is exactly how the echo service is implemented with respect
to source-route, record-route, TTL and so forth. Exploration of this
may shed some lumens on the general protocol model as well.

Dave

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 11:33:41 EST
From:      geof@imagen.UUCP.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm

Looks baroque, but ok, until I see:

 >      Note that failing to acknowledge a packet isn't necessarily enough
 >      information since if the remote site closes its window it can still
 >      indicate that it is alive by acknowledging old data.  However, the
 >      geometric backoff means that it might take a very long time to detect
 >      the reopened window.  A window opening ACK wouldn't be acceptable unless
 >      it opened the window farther than it had been before being closed.  Does
 >      anyone admit to actually closing windows?  This might be an argument to
 >      limit the maximum retransmission interval to say, two minutes.  Even
 >      then, you might want a connection to keep trying forever.

YES I CLOSE WINDOWS FOR A LOOOOOOONG TIME -- FROM WHEN THE PRINTER RUNS
OUT OF PAPER UNTIL SOMEONE PUTS MORE PAPER BACK IN.   THREE DAYS IS NOT
UNHEARD OF.  And every TCP implementation that incorrectly times out
just because of a protracted zero window (say 25 seconds) causes a job
to die and us to have an irate customer.  Presumably TCP terminal gw's
do the same thing if you type ^S on the keyboard (or if you attach them
to a printer that is out of paper).

Data that is not acknowledged because there is a zero window IS NOT THE
SAME THING as data that is not acknowledged because it wasn't received.
The sender KNOWS that it is sending into a zero window.  Thus it is
extremely silly for a sender to apply normal retransmission criteria to
a zero window condition.  During zero window, the sender should probe
the connection repeatedly with an interval of 2.5 minutes or so.  These
packets are guaranteed to generate an immediate response (that does
not ack the data), so the response can be used to keep the connection
alive EVEN THOUGH no data is acked.  This is the only place in the TCP
where it is mandated precisely when to send a packet which bears neither
data nor ack (the spec allows them to be sent anywhere, and good practise
mandates that they be sent occasionally, but there is no where else
where they are required).

If 2.5 minutes is too long for you (remember, [1] very few situations
generate a zero window, and [2] the receiver will almost certainly
volunteer a packet that opens the window) then start with a tighter
probe and back it off to 2.5 minutes after a little while.  But don't
use a long backoff as if you were in a congestion situation (when
you've been getting back packets all along) and DON'T RESET THE
CONNECTION.

Please please please fix your buggy implementations to do the right
thing when sending into a zero window.

- Geof

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 11:53:24 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Ping & debugging tools

Jim,

Just to underscore your point, I confirmed your observation that the dcn1
name server was in fact bog, but using my own flashy toolkit. Geez, you
mean somebody is still using old-style name servers? Well, it turned out
the new-style (domain) name server on dcn1 is bogged as well. The bug
several years old, but was revealed only by your tests just now.

Dave

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 12:31:09 EST
From:      leo@SH.CS.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   (none)


Subject: Re: X.25 to Ethernet (TCP/IP) Gateway 
In-reply-to: Your message of Thu, 16 Apr 87 14:13:21 -0700.
             <12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU> 
Fcc: outbox
--------

	We need a gateway which will provide for terminal sessions
	between PADs and Hosts on X.25 Public Data Networks and
	Ethernets (using TCP/IP).  We are interested in both turn-key
	black-box schemes and software packages which might allow small
	UNIX machines currently on our Ethernet to perform this
	function.  The additional ability to support multi X.25 ports
	both for backup paths and sub-addressed hosts would be a help.

CSNET distributes under license software which provides a TCP/IP over
X.25 interface.  The software, known as XNI, runs under UNIX on a vax
and currently works with an Interactive Systems Incard X.25 device.
Work is under way to make the software work with ACC X.25 devices.

The software supports TCP/IP over the public data network and enables
the host to act as an IP gateway between other hosts on the PDN and
whatever is behind the host.

In addition to the TCP/IP support, XNI implements PAD functionality.
It can be used as a remote terminal  to connect to another host on the
PDN or to act as a tty port on the gateway host.  To reach other
machines behind the gateway from the PDN, one could either telnet from
the shell or have rlogin be your shell.

More info is available from cic@sh.cs.net

Leo Lanzillo
leo@sh.cs.net

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Fri, 17-Apr-87 15:59:07 EST
From:      gkn@SDSC-SDS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Echo services

All of the VAXen here at SDSC have TCP Echo (port 7, RFC 862), TCP Discard
(port 9, RFC 863), and character generator (port 19, RFC 864) services on
them.  These were put in place to help debug (and proved invaluable) the
underlying communications software for the FTP client program on our Cray
X-MP/48.  In addition to these services there are a number of others, including
a "congested" version of the Echo and Discard services which proved to be
interesting obstacles in making the communications on the Cray as robust as
possible.

I doubt seriously that we could have made the stuff for the Cray work without
them.  I also wish that some of these services were available someplace besides
our local ethernet;  we were severly flamed for using an echo server on another
host elsewhere in the network (hence the "congested" versions).

gkn
--------------------------------------
Arpa:	GKN@SDSC-SDS.ARPA
Bitnet:	GKN@SDSC
Span:	SDSC::GKN (27.1)
USPS:	Gerard K. Newman
	San Diego Supercomputer Center
	P.O. Box 85608
	San Diego, CA 92138
AT&T:	619.534.5076

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Apr-87 01:17:16 EST
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Old-style nameservers

We allow up to three of each kind (domain and IEN-116), as well
as a host table in our configuration.  We distribute a public-domain
IEN-116 nameserver for 4BSD on our "Unsupported Network Software"
diskette, partly because we were sure we could do so legally, and
partly because it is much simpler (most people who want it aren't
on the Internet yet).  We would like to give out bind, as well, but
it has "Copyright Regents of..." all over it, and no release.  We
*do* have more room on the diskette, if anyone wishes to point me at
p-d goodies of general utility.  It would be nice to put all nine
4.3 patches on it, too...

As you probably know, Bridge, in their recent upgrading of some of
their product line, chose to use IEN-116.  It is definitely better
than hosttables.

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Apr-87 01:59:46 EST
From:      sy.Ken@CU20B.COLUMBIA.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm


  Looks baroque, but ok, until I see...

Don't know what all the discussion is about.  I was always of the mind that
'if it ain't baroque, don't fix it!'  (sorry).  /K
-------

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Apr-87 15:59:49 EST
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   BIND redistribution (was Re: Old-style nameservers)

Although BIND has copyright notices in it, there is no problem
with redistributing it.  Like all Berkeley-licensed code, there
are only 2 restrictions on redistribution: any rights of AT&T
in their original UNIX source must be protected (in this case, none),
and due credit must be given the University.  Maintaining the copyright
notices in redistributed source code is generally sufficient to satisfy
this restriction.

		Mike

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Apr-87 17:19:45 EST
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3 TCP keep-alive question

Curiously, I tried an experiment with keepalives a few weeks ago.
Your description of the comment in the 4.2 source isn't quite
accurate; the comment accurately describes what the code does,
but is wrong about the reasoning.  Both 4.2 and 4.3 send
	<SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK>
with one byte of (imaginary) data.  As you observed, sending
	<SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK>
with no data should be sufficient to elicit a response.  However,
although 4.3 systems and Sun 3.x systems responded to such probes,
Ultrix 1.2 (and 2.0 field test) systems failed to respond, which
rather annoyed the users whose windows would disappear after some
minutes of inactivity.  I haven't tested this with more systems
because of the one failure; I don't have any stock 4.2's left
nearby.  Curiously, I started looking at this because someone
from the Ultrix group found a bug in handling resets generated
in response to a keepalive.  The reset may not be accepted,
as the sequence number will be one to the left of the window
using the current keepalive format.

		Mike

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Sat, 18-Apr-87 20:10:12 EST
From:      cetron@utah-cs.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3 TCP keep-alive question


In article <...> karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes:

->Curiously, I tried an experiment with keepalives a few weeks ago.
->Your description of the comment in the 4.2 source isn't quite
->accurate; the comment accurately describes what the code does,
->but is wrong about the reasoning.  Both 4.2 and 4.3 send
->	<SEQ=SND.UNA-1><ACK=RCV.NXT-1><CTL=ACK>
->with one byte of (imaginary) data.  As you observed, sending
->	<SEQ=SND.UNA-1><ACK=RCV.NXT><CTL=ACK>
->with no data should be sufficient to elicit a response.  However,
->although 4.3 systems and Sun 3.x systems responded to such probes,
->Ultrix 1.2 (and 2.0 field test) systems failed to respond, which
->rather annoyed the users whose windows would disappear after some
->minutes of inactivity.  I haven't tested this with more systems

	After spending a week hacking keep-alives into the Tektronix TCP/IP
code, I too was quite frustrated when many ultrix users kept calling and 
complaining about there windows disappearing.  After much poring through both
the 4.2/4.3 keep alive code and comparing it against the ultrix 1.2 code it
became obvious that ONE SINGLE LINE OF CODE IS MISSING in the ultrix networking
code.  Seems it gets the keepalive, figures out it is a keep alive and then
doesn't have that ONE LINE OF CODE which tells the kernel to send out an ack.

	Looks to me like a typo deleted a line by mistake.  I posted this
fact here quite a while ago, passed it on to some friends at dec, and would
have filed an SPR but I don't have any Ultrix systems to file it under.  I
had hoped it would be fixed in V2.0 but I quess not.  Maybe if I shame the 
Ultrix people in Nashville next week :-)

-ed cetron

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Apr-87 00:05:36 EST
From:      ROODE@BIONET-20.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: X.25 to Ethernet (TCP/IP) Gateway

We put some ports (RS232) from our cisco EtherTip box  (TCP/IP)
on a CompuServe Network Nanonode.  I know this is not exactly
what you're describe, but I thought you might be interested
since it yields equivalent functionality.

-------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Sun, 19-Apr-87 01:16:46 EST
From:      srg@quick.UUCP
To:        comp.protocols.tcp-ip
Subject:   Submission for mod-protocols-tcp-ip

Path: quick!srg
From: srg@quick.UUCP (Spencer Garrett)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Time RFC 868
Summary: RTT can be estimated with 2 packets, not 4
Message-ID: <119@quick.UUCP>
Date: 19 Apr 87 06:16:45 GMT
References: <8704051517.a011510@Huey.UDEL.EDU> <194@cos.COM>
Organization: Quicksilver Engineering, Seattle
Lines: 11

In article <194@cos.COM>, howard@cos.UUCP (Howard Berkowitz) writes:
> the slave RETRANSMITS what it received.  The master
> then calculates the difference (in time units) between
> what it sent and what the slave received, and sends
> that as a correction factor.  ...

This same protocol could be done with 2 packets instead of 4.  The
originator (master) should estimate the round-trip time (RTT) using
its local clock instead of asking the responder (slave) to perform
that function.  The accuracy of the setting of the local clock is of
no consequence.  Only a time difference is needed.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Apr-87 08:07:13 EST
From:      richb.UUCP@dartvax.UUCP (Richard E. Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: network password protection/TCP spec


TO THE MODERATOR:

I tried to post this a while ago, but received a reply from
some mailer daemon that this message should be mailed to you, not
posted.  I never received any responses, so I'm suspicious:  did
it arrive and was it posted?  If not, would you post it now?  If
it was, thanks.

Rich Brown

------------ MY MESSAGE FOLLOWS -------

  A while back, there was a discussion of protecting passwords,
  which lead to a discussion of taking over someone's TCP
  connection.  One person noted that if a spoofer simply startd
  sending in-sequence messages, they could take over the session
  and the victim would be relatively helpless.  Another person
  responded that he thought TCP specified that an ACK with a
  sequence number that was too high would result in a RST to clean
  out the connection.  (Further discussion revealed that TCP does
  *not* specify this -- in fact, it allows the session to
  continue.)

  My question:  Is this behavior (sending RST if the ACKs get too
  high) desirable?  Are there any pitfalls to doing this?

  Here at Dartmouth, we have developed a stream protocol which
  runs over AppleTalk.  It is in use throughout the campus with
  our Macintosh terminal emulator, and several commercial vendors
  are also implementing this protocol.  If it is useful, a stroke
  of a pen will implement it (well, you know what I mean).  Thanks.

  Rich Brown
  Dartmouth College
  Kiewit Computer Center
  Hanover, NH 03755
  603/646-3648

  richb@dartmouth.edu
  richb@dartmth.bitnet
  richb@dartvax.UUCP
  A0183 on AppleLink

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Apr-87 16:31:00 EST
From:      JSLove@MIT-MULTICS.ARPA ("J. Spencer Love")
To:        comp.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm

No, you don't understand what I meant by "closing a window".  I am
asking, does anyone admit to taking away a window already granted.  That
is, first announcing that a nonzero window is available, and then later
announcing that a smaller window is available than is justified by
additional bytes acknowledged.  This amounts to backing up the edge of
the window, which is explicitly discouraged in the spec.  It is true
that if no additional data can be acknowledged, then the sending TCP
can't tell that the window has shrunk because of the rule for sorting
out old vs new window updates, which only provides for growing the
window if the sequence and acknowledgement fields do not change.

Thus, I am NOT addressing the possibly widespread bug that sending into
a zero window causes timeouts, which it shouldn't, but rather asking if
a connection should be kept alive indefinitely by receiving obsolete
acknowledgements when it *thinks* it has a nonzero window to send into.

This is a variant of the old keepalive controversy, I suppose.  The
question is, does anyone admit to illegally backing up the edge of the
window, not does anyone admit to running out of buffer space.
                                        -- Spencer

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Apr-87 16:55:42 EST
From:      KLH@SRI-NIC.ARPA (Ken Harrenstien)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm

The ITS TCP implementation, at least, often does reduce the window by
more than the amount of bytes acknowledged; what it would really like
to use is a packet count, rather than a byte count.  It is prepared to
recover (by compaction etc) if the sender does not take any notice of
the reduced window size, but this was still a conscious decision to
live dangerously for the sake of greater efficiency.
-------

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Apr-87 18:06:00 EST
From:      JSLove@MIT-MULTICS.ARPA ("J. Spencer Love")
To:        comp.protocols.tcp-ip
Subject:   Re: network password protection/TCP spec

I sent some of the messages on this topic, in particular the claim that
Multics sends RST segments when it receives precognitive
acknowledgements, and a subsequent justification of this behavior when
it turned out to be contrary to RFC 793.

If a precognitive acknowledgement is received, it comes from one of
three sources:  1) it is a paleolithogram which has been lying around in
the network exceeding its time-to-live, perhaps because of gateway
problems or sick hardware; 2) it indicates that the other end of the
connection has accepted data which you have not sent; or 3) someone is
trying to get you to reset the connection or update your window values.

The reason RFC 793 says that precognitive acknowledgements should be
ignored is that the authors only considered case 1 interesting.  Case 3
only exists in violation of the spec (a way to close windows) or can be
considered to be in the same category as case 2 in terms of tampering
with the connection.

My argument was that case 2 was possible and that handling it by sending
a RST was sensible.  The argument against it is that this might cause
case 1 to abort connections spuriously.  My counterargument is that RST
packets generated via case 1 are very unlikely to abort the connection.
This is because the RST packet's sequence number must be in the window
acceptable to the receiving TCP.  This sequence number is the
precognitive ACK which caused the RST.  If the sequence number is
out-of-window, then the RST packet is ignored.  This is described on
page 37 of RFC 793.

The range of valid sequence numbers for the RST extends from the highest
acknowledged sequence number to the window edge which is determined by
the available buffer space.  This window cannot in any case exceed
65,535 acceptable values, but is usually much smaller.  The range of
possible values is much larger; there are 4,294,967,296 possible values.
Thus, the probability that a paleolithogram-induced RST will be in the
window is actually quite small.  This is generally the case when initial
sequence numbers are chosen by a clock as described in RFC 793; it is
less true for implementations where all sequence numbers start at zero.
See pages 26 and 27 of the RFC.

If your protocol can sort out acceptable RST packets from a much larger
set of possible RST packets, then case 1 above won't be very likely to
destroy connections.  However, if your protocol doesn't have this
property, then perhaps some other mechanism for detecting and defeating
subversion attempts would be more appropriate.

This mechanism isn't really good enough to be a dependable hacker trap.
If you really want protection you should try using encryption.  For
example, you could encrypt TCP packets as announced by an extended
security option (as yet unspecified) which appears in the IP header and
is thus in the clear.  The cipher chaining could use some function of
the IP header's fragment reassembly identifier field so that each TCP
packet would start out differently even for equivalent port values and
sequence numbers (assuming DES).  Key selection would be on a host-host
basis with regard to security level and perhaps type-of-service but not
with regard to port numbers.  This might make it very difficult to
subvert connections, but I know of no research to test the robustness of
this scheme.

For AppleTalk, how big are your acknowledgement fields?  Can packets get
queued in gateways or device drivers from which they might emerge later
and cause trouble?  Is any of this TCP technology applicable at all?
TCP and IP have huge headers which contain most commonly used fields in
fixed places to minimize packet processing overhead, so that their users
can pass many many packets per second through very high speed
interfaces.  A more byte-oriented protocol with many optional fields
might have very different design constraints.  For example, if there
were no gateways, then perhaps case 1 can never arise, so precognitive
acks always indicate something very wrong.  On the other hand, some
protocols might consider any RST (abort) packet valid, so that you
should be very careful about possibly generating spurious aborts.

                    -- Spencer Love (617-253-2091 if email fails)

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Apr-87 21:22:28 EST
From:      narten@PURDUE.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP in ISO

>It is interesting to note that a TCP/UPD Echo service is trivial to
>implement, since all it takes is a swap of addresses (and ports in some
>implementations), which makes it no more intrusive than ICMP Echo.

While you might get away with this at the TCP layer, it leads to
interesting behavior when done with UDP or at lower layers.  A certain
dedicated IP gateway we have does this very thing when generating ICMP
errors, and answering ICMP echo requests.  Imagine further, a very
widely distributed version of ping that allowed one to send ICMP echo
requests to IP broadcast addresses.  While pings are harmless enough,
I have seen port unreachables fly across our Ethernet that "originate"
from an IP broadcast address.

Thomas

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Mon, 20-Apr-87 21:22:47 EST
From:      brescia@CCV.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   What is a window (was: A New TCP Retransmission Algorithm)


     The ITS TCP implementation, at least, often does reduce the window by
     more than the amount of bytes acknowledged; what it would really like
     to use is a packet count, rather than a byte count.

A little history comes to mind.  In early ARPANET days, NCP was the precursor
to TCP.  Each stream had what was termed an 'allocation', which was the set of
numbers used to enforce flow control.  A sender could not send more than the
allocation given it by the receiver.  "More what?", you ask.  Well, there were
2 numbers in the allocation, which had to be accounted each time you sent a
message.  There was the 'message count' and also the 'byte count'. (Maybe it
was a bit count, since NCP allowed arbitrary byte sizes.)  If a sender was
working with an allocation of 8 messages and 1000 bytes, it could send one 1000
byte message, or 8 one byte messages, or whatever else caused either the byte
or the message allocation to be used up.  The receiver, when buffers were
freed, would be expected to send back a new allocate, with incremental updates
to the numbers the sender was maintaining.  Hopefully, the receiver would hold
off a little while, and avoid sending an allocate for each message
received.  (Sounds like 'silly window syndrome'.)

In order to fix the problem of hung connections when allocate messages got
lost, there was a spec for a method to reset the allocations, but I don't
recall seeing it widely implemented.  The arpanet did not drop enough messages
to convince many people to put the work into their hosts.  (ARPANET still does
not drop many messages.)

"Those who do not learn from history, looostl.UU
21:0 G

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 87 22:22:47 D (Mon)
From:      Mike Brescia <brescia@ccv.bbn.com>
To:        TCP-IP@sri-nic.ARPA
Subject:   What is a window (was: A New TCP Retransmission Algorithm)
     The ITS TCP implementation, at least, often does reduce the window by
     more than the amount of bytes acknowledged; what it would really like
     to use is a packet count, rather than a byte count.

A little history comes to mind.  In early ARPANET days, NCP was the precursor
to TCP.  Each stream had what was termed an 'allocation', which was the set of
numbers used to enforce flow control.  A sender could not send more than the
allocation given it by the receiver.  "More what?", you ask.  Well, there were
2 numbers in the allocation, which had to be accounted each time you sent a
message.  There was the 'message count' and also the 'byte count'. (Maybe it
was a bit count, since NCP allowed arbitrary byte sizes.)  If a sender was
working with an allocation of 8 messages and 1000 bytes, it could send one 1000
byte message, or 8 one byte messages, or whatever else caused either the byte
or the message allocation to be used up.  The receiver, when buffers were
freed, would be expected to send back a new allocate, with incremental updates
to the numbers the sender was maintaining.  Hopefully, the receiver would hold
off a little while, and avoid sending an allocate for each message
received.  (Sounds like 'silly window syndrome'.)

In order to fix the problem of hung connections when allocate messages got
lost, there was a spec for a method to reset the allocations, but I don't
recall seeing it widely implemented.  The arpanet did not drop enough messages
to convince many people to put the work into their hosts.  (ARPANET still does
not drop many messages.)

"Those who do not learn from history, loop."

    Mike
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Apr-87 06:51:00 EST
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: What is a window (was: A New TCP Retransmission Algorithm)

Mike,

While it is true that the ARPANET does not very many messages, when it did,
the NCP connections got hung up either because of flow control confusion
(lost allocates) or lost messages which were not retransmitted at the NCP level.
It was that observation, plus the addition of more lossy nets such as Ethernet
and packet radio that motivated many of the TCP features.

Vint

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1987 07:51-EDT
From:      CERF@A.ISI.EDU
To:        brescia@CCV.BBN.COM
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: What is a window (was: A New TCP Retransmission Algorithm)
Mike,

While it is true that the ARPANET does not very many messages, when it did,
the NCP connections got hung up either because of flow control confusion
(lost allocates) or lost messages which were not retransmitted at the NCP level.
It was that observation, plus the addition of more lossy nets such as Ethernet
and packet radio that motivated many of the TCP features.

Vint
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Apr-87 13:05:48 EST
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP in ISO

Thomas,

An incoming packet, no matter what its protocol or port, with source
address a broadcast address, has been formally declared a Chernobyl
Packet, since it can lead to Ethernet meltdown. Your somarter gateway
(and mine, too, after encountering these things) includes these
things in the martian filter, which unceremoneously simply dumps
them on the floor of a containment vessel.

Dave

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Apr-87 15:24:47 EST
From:      victor@kuling.UUCP (Bjorn Victor)
To:        comp.protocols.tcp-ip
Subject:   Interpreting RFC 793

As I'm working on a TCP implementation, I have a question on the
interpretation of RFC 793 (please look in your copy):

On page 73 (Segment Arrives, otherwise clause, ACK bit clause), in
state FIN-WAIT-1, it says
    "..., if our FIN is now acknowledged then enter FIN-WAIT-2 and
    continue processing in that state."
On page 75 (Segment Arrives, otherwise clause, FIN bit clause), in
state FIN-WAIT-1, it says
    "If our FIN has been ACKed (perhaps in this segment), then enter
    TIME-WAIT, ..."

Now, could somebody please explain how we could possibly "execute" the
quoted sentence on page 75?  If our FIN *was* ACKed, we're no longer
in the FIN-WAIT-1 state!?

Also, if someone could point me to a more formal description of TCP,
I'd be more than happy.

--Bjorn Victor		       UUCP: {mcvax,seismo}!enea!kuling!victor
Dept. of Computer Systems      ARPA: Victor%Carmen.UU.SE@Seismo.CSS.GOV,
Uppsala University, SWEDEN	     victor%kuling.UU.SE@Seismo.CSS.GOV
-- 
--Bjorn Victor		       UUCP: {mcvax,seismo}!enea!kuling!victor
Dept. of Computer Systems      ARPA: Victor%Carmen.UU.SE@Seismo.CSS.GOV,
Uppsala University, SWEDEN	     victor%kuling.UU.SE@Seismo.CSS.GOV

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 87 11:51:00 GMT
From:      A.ISI.EDU!CERF%hslrswi.uucp%CERNVAX.BITNET@wiscvm.wisc.edu
To:        vu-vlsi@mvax.UUCP, liberty}!swatsun!schwartz@sun.uucp mod.protocols.tcp-ip
Subject:   Re: What is a window (was: A New TCP Retransmission Algorithm)

Mike,

While it is true that the ARPANET does not very many messages, when it did,
the NCP connections got hung up either because of flow control confusion
(lost allocates) or lost messages which were not retransmitted at the NCP level
It was that observation, plus the addition of more lossy nets such as Ethernet
and packet radio that motivated many of the TCP features.

Vint
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Apr-87 17:12:00 EST
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm

Sure, I'll admit to backing up the window, but not to doing it "illegally".
The spec says in the "Managing the Window" section that there is an
assumption that the window size is related to the currently available
data buffer space available for the connection;  that is in fact the
case - the user/application supplies one or more buffers to be filled
with data and the amount of space provided specifies the window.  The
spec also says in the "Data Communication" section that a Push requires
that any data be placed into the user's buffer and the buffer returned to
the user even if it is not full.  Consequently, the window is reduced by
the amount of unused space in the buffer returned to the user in response
to a Push.

Since there is justification in the spec for reducing the window, and the
spec requires senders to deal with it, it is also used in one other case.
If a packet is lost, as indicated by reception of several segments in the
window but not at the left edge, the window is reduced to the right edge
of the missing data to "encourage" the sender to retransmit the missing
data and to "discourage" it from sending additional new data or from
retransmitting data which was in fact received but couldn't be acked.
(If the sender ignores the hint, which we might call a NAK, nothing
goes wrong; the receiver will eventually send ICMP Source Quenches which
shouldn't be ignored and if that doesn't work packets will be flushed.)
This case can be viewed as a situation where the user has provided buffer
space but it cannot be used due to the missing segment(s).

If a connection is receiving something from the TCP at the other end,
even "obsolete acknowledgements", why shouldn't it be kept "alive"?

Charlie

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Tue, 21-Apr-87 18:02:00 EST
From:      JSLove@MIT-MULTICS.ARPA ("J. Spencer Love")
To:        comp.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm

By "illegally backing up the window," I mean sending an acknowledgement
which decreases the offered window but which contains the same sequence
number and acknowledgement fields as a previously transmitted
acknowledgement.  In this case, it appears to the sending TCP as if the
acknowledgement arrived out of order.  In other words, if two packets
arrive with the same sequence and acknowledgement fields, the one which
offers the larger window is held to be "more recent."

Windows are discussed on pages 42 and 43 of RFC 793.  While the behavior
described above is not mandatory, it is strongly hinted at.  In RFC 813,
some discussion of "artificially closing the window" appears in context
to refer to keeping the offered window edge fixed rather than backing it
up, in order to avoid silly window syndrome.

The specification does require that implementations cope with other
implementations closing the window in other situations which they may be
able to detect.  However, it does not require that implementations
actually repackage data on the retransmission queue, so this merely
means that the implementations are required to cease forming new packets
and withhold retransmissions.  Since implementations should generally
only retransmit the earliest unacknowledged packet, this merely prevents
the formation of additional packets, not the delivery of packets already
in flight.

Thus, your description of the circumstances under which you close the
window doesn't necessarily match my description of "illegal" behavior,
but it is behavior which the specification describes as "strongly
discouraged." In particular, discarding packets which are transmitted
into your formerly offered window is a good example of shooting yourself
in the foot.

Timing out connections which are receiving "obsolete", or if you prefer,
"redundant" acknowledgements while being unable to get the most recent
packet acknowledged is similar to the zero window probe situation.  It
is clear that a connection sending into a zero window shouldn't time out
as long as redundant ACKs are being received.  If a connection sending
into a nonzero window should also not time out when only receiving "old"
ACKs, then what effect, if any, should this have on the retransmission
backoff?  In the zero window probe scenario, we don't back off the
window probes geometrically, but rather retransmit them infrequently,
perhaps every two minutes.

This would combine with my previous proposal if the geometric backoff
were maxed out at the zero window probe interval, and the receipt of any
packet resets the unacknowledged packet counter without affecting the
retransmission interval.  Then the unacknowledged packet counter becomes
the basis for timing out connections.  (The unacknowledged packet
counter is also not incremented if the retransmission timer is set for
an interval of less than one second.)

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 1987 18:12-EDT
From:      CLYNN@G.BBN.COM
To:        JSLove@MIT-MULTICS.ARPA
Cc:        imagen!geof@DECWRL.DEC.COM, TCP-IP@SRI-NIC.ARPA
Subject:   Re: Re: A New TCP Retransmission Algorithm
Sure, I'll admit to backing up the window, but not to doing it "illegally".
The spec says in the "Managing the Window" section that there is an
assumption that the window size is related to the currently available
data buffer space available for the connection;  that is in fact the
case - the user/application supplies one or more buffers to be filled
with data and the amount of space provided specifies the window.  The
spec also says in the "Data Communication" section that a Push requires
that any data be placed into the user's buffer and the buffer returned to
the user even if it is not full.  Consequently, the window is reduced by
the amount of unused space in the buffer returned to the user in response
to a Push.

Since there is justification in the spec for reducing the window, and the
spec requires senders to deal with it, it is also used in one other case.
If a packet is lost, as indicated by reception of several segments in the
window but not at the left edge, the window is reduced to the right edge
of the missing data to "encourage" the sender to retransmit the missing
data and to "discourage" it from sending additional new data or from
retransmitting data which was in fact received but couldn't be acked.
(If the sender ignores the hint, which we might call a NAK, nothing
goes wrong; the receiver will eventually send ICMP Source Quenches which
shouldn't be ignored and if that doesn't work packets will be flushed.)
This case can be viewed as a situation where the user has provided buffer
space but it cannot be used due to the missing segment(s).

If a connection is receiving something from the TCP at the other end,
even "obsolete acknowledgements", why shouldn't it be kept "alive"?

Charlie
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 87 22:12:00 GMT
From:      G.BBN.COM!CLYNN%hslrswi.uucp%CERNVAX.BITNET@wiscvm.wisc.edu
To:        e@hslrswi.UUCP, to@hslrswi.UUCP, the@hslrswi.UUCP, missing@hslrswi.UUCP, segment@hslrswi.UUCP mod.protocols.tcp-ip
Subject:   Re: Re: A New TCP Retransmission Algorithm

Sure, I'll admit to backing up the window, but not to doing it "illegally".
The spec says in the "Managing the Window" section that there is an
assumption that the window size is related to the currently available
data buffer space available for the connection;  that is in fact the
case - the user/application supplies one or more buffers to be filled
with data and the amount of space provided specifies the window.  The
spec also says in the "Data Communication" section that a Push requires
that any data be placed into the user's buffer and the buffer returned to
the user even if it is not full.  Consequently, the window is reduced by
the amount of unused space in the buffer returned to the user in response
to a Push.

Since there is justification in the spec for reducing the window, and the
spec requires senders to deal with it, it is also used in one other case.
If a packet is lost, as indicated by reception of several segments in the
window but not at the left edge, the window is reduced to the right edge
of the missing data to "encourage" the sender to retransmit the missing
data and to "discourage" it from sending additional new data or from
retransmitting data which was in fact received but couldn't be acked.
(If the sender ignores the hint, which we might call a NAK, nothing
goes wrong; the receiver will eventually send ICMP Source Quenches which
shouldn't be ignored and if that doesn't work packets will be flushed.)
This case can be viewed as a situation where the user has provided buffer
space but it cannot be used due to the missing segment(s).

If a connection is receiving something from the TCP at the other end,
even "obsolete acknowledgements", why shouldn't it be kept "alive"?

Charlie
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Apr-87 05:14:42 EST
From:      feldman%mycroft@GSWD-VMS.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Ken Olsen vs MAP

GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: feldman%mycroft@gswd-vms.ARPA (Mike Feldman)
To: TCP-IP@sri-nic.arpa
Subject: Re: Ken Olsen vs MAP
Return-Path: <TCP-IP-RELAY@SRI-NIC.ARPA>
Redistributed: tcp-ip^.x
Received: from SRI-NIC.ARPA by Xerox.COM ; 10 APR 87 15:29:50 PDT
Received: from gswd-vms.ARPA by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 06:49:15-PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704101349.AA14705@gswd-vms.ARPA>
Original-Date: Fri, 10 Apr 87 07:47:18 CST
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV

> The answer to your question is that the MAP people do not fully understand
> all the sources of probabilistic delay that you catalog.  ...
> 
> In their defense however, they have always been concerned about the situation
> which might arise when a failure in a manufacturing process causes 500
> sensors to all start sending emergency warning messages at the same instant.
> This can lead to lockup on an Ethernet in a way which should not occur on a
> token bus.

I was envolved in designing an early token bus process control system for
a control system manufacturer in '69 - '70, when I first saw the Ethernet spec
and articles describing it.  I was a junior software engineer at the time,
and I suggested to the powers-that-be that Ethernet was much simpler to
implement, and that we were already doing it for the token recovery sequence
(silence on the wire).

It's my opinion that it was dogma among communications engineers even then
that you needed deterministic bus access time and guaranteed throughput for
control system muxes.  There were two cases where the system had to perform
under Ethernet-busting loads.  One was during customer accecptance testing,
and the other was when the reactor pressure relief valve failed open.

I got angry reactions when I suggested Ethernet would be cheaper and easier
to build and would have better performance almost all of the time.  They
were even more irritated when I suggested the if determinism and known
throughput were so important that they use time division multiplexing.

These days, there is a lot of support among control system suppliers for MAP.
There hope is that the semiconductor industry will see a large market and
implement all the hard, expensive lower layers in silicon, because so far it's
been too expensive for each system house to develop one that's a comercial and
technical success.  It might happen, but they still won't get the deterministic
round trip message delay needed to implement stable fast feedback loops.

These opinions are my own.

Mike Feldman
Gould Computer Systems Division
1101 East University Avenue
Urbana, IL 61801

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Apr-87 08:17:00 EST
From:      CLYNN@G.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Interpreting RFC 793

Bjorn,
	Technically, you can't; in fact, the next paragraph on page 75,
FIN-WAIT-2, says to do exactly the same thing as does the FIN-WAIT-1
state when the FIN has been acked.  I view the situation as an explicit
restatement of robustness -- a correct implementation shouldn't get into
that state, but if it does (software implementations have been known to
contain bugs) then there is a way to recover.  Maybe there should be a
statement to the effect that you shouldn't be here, write an entry into
the system error log.

Charlie

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 1987 09:17-EDT
From:      CLYNN@G.BBN.COM
To:        mcvax!enea!kuling!victor@SEISMO.CSS.GOV
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interpreting RFC 793
Bjorn,
	Technically, you can't; in fact, the next paragraph on page 75,
FIN-WAIT-2, says to do exactly the same thing as does the FIN-WAIT-1
state when the FIN has been acked.  I view the situation as an explicit
restatement of robustness -- a correct implementation shouldn't get into
that state, but if it does (software implementations have been known to
contain bugs) then there is a way to recover.  Maybe there should be a
statement to the effect that you shouldn't be here, write an entry into
the system error log.

Charlie
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Apr-87 13:43:00 EST
From:      howard@COS.COM (Howard C. Berkowitz)
To:        comp.protocols.tcp-ip
Subject:   Re: Submission for mod-protocols-tcp-ip

In article <8704190722.AA17818@uw-apl>, srg@quick.UUCP writes:
> Path: quick!srg
> From: srg@quick.UUCP (Spencer Garrett)
> Subject: Re: Time RFC 868
> Summary: RTT can be estimated with 2 packets, not 4
> 
> In article <194@cos.COM>, howard@cos.UUCP (Howard Berkowitz) writes:
> > the slave RETRANSMITS what it received.  The master
> > then calculates the difference (in time units) between
> > what it sent and what the slave received, and sends
> > that as a correction factor.  ...
> This same protocol could be done with 2 packets instead of 4.  The
> originator (master) should estimate the round-trip time (RTT) using
> its local clock instead of asking the responder (slave) to perform
> that function.  The accuracy of the setting of the local clock is of
> no consequence.  Only a time difference is needed.

Good suggestion.  If, however, both the master and the slave compute
the time difference, it is possible to isolate the time the slave
needs to set the clock. This is probably trivial, but is a refinement.
The round trip time contains three components: 

     outbound network delay
     slave processing
     inbound network delay

outbound (in the dial net) equals inbound; this is not necessarily true
in all networks.

We have not considered in this the effect of error control.
Clearly, in a real-time, time-stamped application such as this,
you do _NOT_ want to retransmit either a master or slave time
synchronization message!  A new one must be sent!

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Wed, 22-Apr-87 20:20:33 EST
From:      geof@apolling.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Re: A New TCP Retransmission Algorithm


 >      No, you don't understand what I meant by "closing a window".  I am
 >      asking, does anyone admit to taking away a window already granted.  That

Ooooooohhhhhhh!  Sorry.  Never Mind.

I just like to flame on that particular point.

We don't close the window in the way that you mention.

- Geof

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Apr-87 06:34:46 EST
From:      uucp@hslrswi.UUCP (Uucp)
To:        comp.protocols.tcp-ip
Subject:   (none)

$
Path: hslrswi!cernvax!mcvax!seismo!esosun!ucsdhub!sdcsvax!ucbvax!hslrswi.UUCP!A
From: A.ISI.EDU!CERF@hslrswi.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: What is a window (was: A New TCP Retransmission Algorithm)
Message-ID: <[A.ISI.EDU]21-Apr-87.07.51:49.CERF>
Date: 21 Apr 87 11:51:00 GMT
References: <brescia@ccv.bbn.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 10



Mike,

While it is true that the ARPANET does not very many messages, when it did,
the NCP connections got hung up either because of flow control confusion
(lost allocates) or lost messages which were not retransmitted at the NCP level
It was that observation, plus the addition of more lossy nets such as Ethernet
and packet radio that motivated many of the TCP features.

Vint

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Apr-87 11:12:35 EST
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   laws and things


just out of interest:

1. I just noticed a fragment of 4.2BSD kernel/comms source on this
list. I hope Berkeley know it goes out to the UK Academic
community.

2. The Whois service from NIC contains info about some UK users. If
the system is used (and rfinger similarly) in the UK it is in
contravention of the Data Protection Act unless the data with reasons for
holding it are registered with the "Data Protection Officer" (a
sort of Ombudsman). [THIS ONLY ENFORCABLE IF THE DATA IS HELD
IN THE UK, BECAUSE THE ACT DOES NOT COMPREHEND OF
NETWORKS].

Jon

("How many ISO standard bits does it take to define true").

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23-Apr-87 13:36:16 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Submission for mod-protocols-tcp-ip

Howard,

If you don't mind unslinging the big guns, see RFC-958 for techniques to
accurately measure roundtrip delay and clock offset, which is equivalent
to one-way delays. Improve sample estimates using a median filter as
described in RFC-956. Improve statistical estimates by including all
TCP segments, not just those allowing a single roundtrip estimate at
a time. This last requires state variables for all outstanding segments
that have not been ACKed.

This topic has come up about once a year since early this decade. The
last volley on this list (before Van Jacobson kicked off the current
game) was between John Nagle and myself. My conclusion after all this
is that the implementor should think more like a statistician and less
like a protocol engineer.

Dave

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 23 Apr 87 16:46:50 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   laws and things

just out of interest:

1. I just noticed a fragment of 4.2BSD kernel/comms source on this
list. I hope Berkeley know it goes out to the UK Academic
community.

2. The Whois service from NIC contains info about some UK users. If
the system is used (and rfinger similarly) in the UK it is in
contravention of the Data Protection Act unless the data with reasons for
holding it are registered with the "Data Protection Officer" (a
sort of Ombudsman). [THIS ONLY ENFORCABLE IF THE DATA IS HELD
IN THE UK, BECAUSE THE ACT DOES NOT COMPREHEND OF
NETWORKS].

Jon

("How many ISO standard bits does it take to define true").
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Apr-87 15:27:58 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Interpreting RFC 793

A great deal of time and trouble went into making "MIL-STD-1778"
("Military Standard Transmission Control Protocol") APPEAR to be more
formal than the RFC TCP spec.  It would be interesting to learn if
a relatively neutral observer thought it actually IS more formal--
and, as a purist's point, whether that makes it more useful, since
I doubt there's an a priori correlation between formality and utility.

Given that page ii says that "benefical comments" can go to
Defense Communications Agency
ATTN: J110
1860 Wiehle Avenue
Reston, VA 22090
and that I don't see any "ordering information" elsewhere (not that
it's necessarily not there, just that I don't see it), presumably
a request for a copy could go to that address as well with some chance
of being fulfilled.

cheers, map
-------

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 1987 16:27:58 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        mcvax!enea!kuling!victor@SEISMO.CSS.GOV (Bjorn Victor)
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Interpreting RFC 793
A great deal of time and trouble went into making "MIL-STD-1778"
("Military Standard Transmission Control Protocol") APPEAR to be more
formal than the RFC TCP spec.  It would be interesting to learn if
a relatively neutral observer thought it actually IS more formal--
and, as a purist's point, whether that makes it more useful, since
I doubt there's an a priori correlation between formality and utility.

Given that page ii says that "benefical comments" can go to
Defense Communications Agency
ATTN: J110
1860 Wiehle Avenue
Reston, VA 22090
and that I don't see any "ordering information" elsewhere (not that
it's necessarily not there, just that I don't see it), presumably
a request for a copy could go to that address as well with some chance
of being fulfilled.

cheers, map
-------
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24-Apr-87 18:38:31 EDT
From:      tai%hpltyj@HPLABS.HP.COM (Tai Jin)
To:        comp.protocols.tcp-ip
Subject:   ICMP echo

I have a question for those experienced in using ICMP echo for
debugging.  Does the spec specify how a system is supposed to reply to
an echo?

One implementation is to turn around and send the reply to the link
address of the sender (or gateway).  The other is to make a local
routing decision before sending the reply.  Which is better?

Another question is whether a system should reply to an ICMP echo sent
to a broadcast address.

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25-Apr-87 06:32:30 EDT
From:      sten@enea.UUCP (Sten Folkerman)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   TCP/IP source wanted


I would be grateful if anyone could tell me where to find (=buy) source
code packet comtaining ip, tcp, udp, telnet, ftp, and preferably rlogin,
rsh, rcp. We will port it to a 680[12]0 machine running System V. The
network is some kind of ethernet (I guess the main job is to implement
the driver).

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Sat, 25-Apr-87 11:40:37 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Agenda for Net Management Meeting

Here is the final agenda for the Network Management Working Group meeting 
on May 5th at TECHMART in Santa Clara.  The room got changed to Room 229 to 
accomodate a larger audience.  Please let me know if you plan to attend.

	     Agenda for Network Management Working Group


	 9:00  Welcome -- Dan Lynch (ACE)
         9:05  Background and Objectives -- Stan Ames (Mitre)
	 9:15  Management Framework -- Lee LaBarre (Mitre)
         9:45  User Concerns -- Lynch
	10:00  Practical Network Management Requirements -- Eric Benhamou
               (Bridge)
	10:30  Break
	10:45  Strawman System Management Protocol Architecture -- LaBarre
	11:15  Protocol for Management Exchanges  -- Al Sciacca (BBN)

	12:00  Lunch

	 1:30  IETF Control,Monitoring WG Activities -- Craig Partridge (BBN) 
	 2:00  TCP/IP Management Parameters  -- Glenn Trewitt (Stanford)
	 2:30  Break
	 2:45  Discussion: Scope, Goals, Schedule of Project (Ames)
	 4:00  Adjourn
-------

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 1987 12:40:37 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        LYNCH@A.ISI.EDU, sra@MITRE-BEDFORD.ARPA, cel@MITRE-BEDFORD.ARPA
Subject:   Agenda for Net Management Meeting
Here is the final agenda for the Network Management Working Group meeting 
on May 5th at TECHMART in Santa Clara.  The room got changed to Room 229 to 
accomodate a larger audience.  Please let me know if you plan to attend.

	     Agenda for Network Management Working Group


	 9:00  Welcome -- Dan Lynch (ACE)
         9:05  Background and Objectives -- Stan Ames (Mitre)
	 9:15  Management Framework -- Lee LaBarre (Mitre)
         9:45  User Concerns -- Lynch
	10:00  Practical Network Management Requirements -- Eric Benhamou
               (Bridge)
	10:30  Break
	10:45  Strawman System Management Protocol Architecture -- LaBarre
	11:15  Protocol for Management Exchanges  -- Al Sciacca (BBN)

	12:00  Lunch

	 1:30  IETF Control,Monitoring WG Activities -- Craig Partridge (BBN) 
	 2:00  TCP/IP Management Parameters  -- Glenn Trewitt (Stanford)
	 2:30  Break
	 2:45  Discussion: Scope, Goals, Schedule of Project (Ames)
	 4:00  Adjourn
-------
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 87 10:53:00 GMT+492:48
From:      <fritts@afotec>
To:        "tcp-ip-request" <tcp-ip-request@sri-nic.arpa>
Subject:   Mail List Address Problem?
I recently sent the message below to TCP-IP-RELAY@SRI-NIC.ARPA.  Apparently
it never reached the list because I never saw it on the list.  We are quite
interested in knowing if anyone else has had a similar problem so I am anxious
to get this message out on the mail list.  Was the address incorrect?  Perhaps,
I was caught by some momentary glitch in our mailer.  Whatever the reason, I
would greatly appreciate knowing if this message was addressed wrong and what
the correct address for the TCP-IP mail list is; in addition to getting this
message on the mail list.  Thank you.

Steve Fritts  FRITTS@AFOTEC.ARPA


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

We have recently experienced a problem in bringing up a new DDN host and
I would like to find out if others have had a similar experience.

We installed an ACC 6250 board on a DEC VAX 11/785 running VMS.  The board
came with an RS-232 port on it for connection to a modem.  The PSN we were
connecting to was about 4 miles away.  We used a 9.6KB circuit to get to
the PSN and connected to an RS-232 port on the BBN C/30.  The problem 
occurred when we tried to come up on the network.  The Network Operations
Center was able to check all the way through the 9.6KB circuit and loop 
back from the modem sitting next to our VAX; they said everything looked 
okay.  We could bring up the ACC 6250 board in loopback mode and it would
recognize itself; but no matter what we did, it was not able to come up
on the network.

The problem was finally resolved when we exchanged the ACC 6250 board with
the RS-232 port for the same ACC 6250 board with an RS-422 port.  We 
installed the board, put in an RS-422 to RS-232 converter box, then hooked
the RS-232 cable to the modem and it worked perfectly!

QUESTION:  Has anyone else had a similar experience with ACC's 6250 board
for standard X.25 DDN host connection when it is configured with an RS-232
port for connection to a PSN using modems?  We would very much like to 
know if ours was a singular experience.

You can reply to my mail box or put it on this mail list.  Thank you.

STEVE FRITTS    FRITTS@AFOTEC.ARPA
------
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Apr-87 16:25:43 EDT
From:      braden@ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Hi.  You have asked a question about ICMP Echo semantics that ought to be,
but isn't, contained in the RFC985-revision.  Sigh.

Here is my totally-prejudiced view on how ICMP Echo should behave (it is
the way my own TCP/IP code implemented ICMP Echo, of course!).  Anyone
who wants to beat me up about this should do so now... otherwise, this
interpretation is likely to find its way into the gateway specification
RFC.

   A host or gateway D that receives an ICMP Echo Request addressed to
   itself from host S should send an ICMP Echo Reply back to S,
   using the following rules:
   
      1.  If the Echo Request contained no source route, the Reply should
          be sent to S using the normal routing rules of D.  
          
	      As a result, the Reply may come back by a different path
	      than the Request took. 
	      
	  2.  If the Echo Request did contain a source route, the Echo
	      Reply will be sent using the return-route built up in the
	      source-routing option of the Echo Request.
	      
	      As a result, it is not possible to force a route for the
	      Reply which is different from the route used for the Echo.       

   A result of these rules is that ICMP Echo can be used to sample the
   complete round-trip path which any other higher-level protocol e.g.,
   TCP) will use for its data and ACK packets between D and S.  The
   rules generally follow from the assumption that ICMP is a protocol
   parallel to TCP and above IP, and needs no special routing mechanism.

   
Bob Braden

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Apr-87 18:52:51 EDT
From:      Vivian@SRI-NIC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   TCP-IP is being filtered

Someone is remailing the TCP-IP list back to itself.  Until it stops
(it's been happening to several large distribution lists for the past
week or so), I'm going to be hand filtering mail to TCP-IP.  Therefore
there will be an additional delay between the time you send messages to
TCP-IP and the time you can expect to see them.  Hopefully things will be
fixed soon, so I can let the list go back to direct distribution.

Vivian Neou
-------

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Mon, 27-Apr-87 18:54:00 EDT
From:      CLYNN@G.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Bob's statement is a nice start but doesn't mention anything about other
options.  I would like to suggest that it would be more generally useful
if a source route was NOT inverted by the receiver of an echo request
when it formed the echo reply (... that's the way I implemented it ...).
Maybe there should be two versions of source route ...

I would argue that the simplest implementation is the most useful --
just change echo request to echo reply and switch the IP source
and destination and send the packet back without changing the options
in any way (except, of course, for the processing that IP is required
to perform).

By returning the options (which some implimentations don't now do) one
gets to see, for example, information recorded in a record route option
(possibly in addition to a source route) and in a timestamp option.
If you want the time out and back along a specific route (Bob's case)
you can source route the packet out and back to yourself, get the
timestamp info, and have your host return the packet to you (which
should be local delivery).  By not returning along a recorded route
one can (if the gateways implement IP ...) find what route is being
used to reach you from point X in the internet.

It might also be nice to include in this discussion the suggestion
(not originally mine) that the pharse in the ICMP spec (4th paragraph,
page 1) "no ICMP messages are sent about ICMP messages" be amended to
"no ICMP messages are sent about ICMP error messages"; thus allowing
one to get error messages about ICMP ECHO, TIMESTAMP, INFORMATION, etc.,
and their corresponding REPLYs.

Charlie

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 1987 18:54-EDT
From:      CLYNN@G.BBN.COM
To:        braden@VENERA.ISI.EDU
Cc:        tai%hpltyj@HPLABS.HP.COM, postel@VENERA.ISI.EDU tcp-ip@SRI-NIC.ARPA
Subject:   Re:  ICMP echo
Bob's statement is a nice start but doesn't mention anything about other
options.  I would like to suggest that it would be more generally useful
if a source route was NOT inverted by the receiver of an echo request
when it formed the echo reply (... that's the way I implemented it ...).
Maybe there should be two versions of source route ...

I would argue that the simplest implementation is the most useful --
just change echo request to echo reply and switch the IP source
and destination and send the packet back without changing the options
in any way (except, of course, for the processing that IP is required
to perform).

By returning the options (which some implimentations don't now do) one
gets to see, for example, information recorded in a record route option
(possibly in addition to a source route) and in a timestamp option.
If you want the time out and back along a specific route (Bob's case)
you can source route the packet out and back to yourself, get the
timestamp info, and have your host return the packet to you (which
should be local delivery).  By not returning along a recorded route
one can (if the gateways implement IP ...) find what route is being
used to reach you from point X in the internet.

It might also be nice to include in this discussion the suggestion
(not originally mine) that the pharse in the ICMP spec (4th paragraph,
page 1) "no ICMP messages are sent about ICMP messages" be amended to
"no ICMP messages are sent about ICMP error messages"; thus allowing
one to get error messages about ICMP ECHO, TIMESTAMP, INFORMATION, etc.,
and their corresponding REPLYs.

Charlie
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 01:04:55 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Bob,

Your model is the one I understand to be in common use, although only the
TOPS-20 is known to me to implement the return route in the way you
suggest (are there others?). However, there is still the question of
options, such as security, etc. Your model, taken prima facie, implies
the respondent simply flips the IP addresses and source-route and
tosses it back in the net, presumably leaving the options alone. I think
this is the right thing, but believe it should be explicitly stated.

On the question of reciprocal routes, unless the ICMP Echo message
was explicitly source-routed, the return route will not necessarily
fly back the reciprocal path. Ordinarily one might expect this and,
indeed, there are many well-behaved segments of the Internet where this
is so. However, in the flooding NSF swamps it has been my observation
that routes are reciprocal only sometimes. In such cases it would be
useful to have an enriched record-route facility. A sneaky way to do
this might be to simply continue the record-route past the echo server.

A final tid: Should the TTL be reset at the echo server? If not, the
sender would have a non-ambiguous way to measure the number of hops.
He could, of course, also use record-route.

Finally, how about a new ICMP Echo/Echo Reply message that operates
as the present one, but where the echo server captures the IP header,
etc., in the same way as ordinary ICMP error messages before returning
to sender?

Dave

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 01:09:46 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Charlie,

As far as I know, your suggestion (originally attributed to Mike Brescia,
I believe) to amend the spec to allow error messages about non-error messages
was approved for incorporation into the MILSTD protocol documents some time
ago. In point of fact, every gateway I know of, including the BBN LSI-11
and Butterflies, fuzzbugs and others, in fact operate as you suggest.

Dave

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 03:32:39 EDT
From:      fritts@AFOTEC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Mail List Address Problem?

I recently sent the message below to TCP-IP-RELAY@SRI-NIC.ARPA.  Apparently
it never reached the list because I never saw it on the list.  We are quite
interested in knowing if anyone else has had a similar problem so I am anxious
to get this message out on the mail list.  Was the address incorrect?  Perhaps,
I was caught by some momentary glitch in our mailer.  Whatever the reason, I
would greatly appreciate knowing if this message was addressed wrong and what
the correct address for the TCP-IP mail list is; in addition to getting this
message on the mail list.  Thank you.

Steve Fritts  FRITTS@AFOTEC.ARPA


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

We have recently experienced a problem in bringing up a new DDN host and
I would like to find out if others have had a similar experience.

We installed an ACC 6250 board on a DEC VAX 11/785 running VMS.  The board
came with an RS-232 port on it for connection to a modem.  The PSN we were
connecting to was about 4 miles away.  We used a 9.6KB circuit to get to
the PSN and connected to an RS-232 port on the BBN C/30.  The problem 
occurred when we tried to come up on the network.  The Network Operations
Center was able to check all the way through the 9.6KB circuit and loop 
back from the modem sitting next to our VAX; they said everything looked 
okay.  We could bring up the ACC 6250 board in loopback mode and it would
recognize itself; but no matter what we did, it was not able to come up
on the network.

The problem was finally resolved when we exchanged the ACC 6250 board with
the RS-232 port for the same ACC 6250 board with an RS-422 port.  We 
installed the board, put in an RS-422 to RS-232 converter box, then hooked
the RS-232 cable to the modem and it worked perfectly!

QUESTION:  Has anyone else had a similar experience with ACC's 6250 board
for standard X.25 DDN host connection when it is configured with an RS-232
port for connection to a PSN using modems?  We would very much like to 
know if ours was a singular experience.

You can reply to my mail box or put it on this mail list.  Thank you.

STEVE FRITTS    FRITTS@AFOTEC.ARPA
ec.v 

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28 Apr 87 08:56:10 PDT
From:      gary@ACC-SB-UNIX.ARPA (Gary Krall)
To:        tcp-ip-rebroadcast@SRI-NIC.ARPA

**All users of ACC's ACP 6250 and ACP 5250 boards** 

ACC has found a design problem with the RS232 
electrical interface connection, and an ECO has been
implemented to address this problem. Because this problem
can cause unreliable operation, ACC recommends
the return of the ACP processor board,
ribbon cable and distribution panel for up-dating.
Please note that the ECO will require modification of both the 
processor board and distribution panel, therefore please return
the complete system.

This is a no cost up-date to the equipment.  Concerned users
should call (805) 963-9431 (in California, Hawaii, or outside the 
U.S.) or (800) 222-7308 to obtain a return authorization (RA) number.

All Service One customers will be provided with replacement
units on a priority basis to minimize the impact of this update.
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 1987 10:27-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        tcp-ip@sri-nic.ARPA
Cc:        Mills@udel.edu, CLYNN@g.bbn.com, tai%hpltyj@hplabs.hp.com, braden@venera.isi.edu, postel@venera.isi.edu
Subject:   Re:  ICMP echo
    From: CLYNN@G.BBN.COM :
    I would argue that the simplest implementation is the most useful --
    just change echo request to echo reply and switch the IP source
    and destination and send the packet back...

    From: Mills@UDEL.EDU :
    Your [Bob Braden's] model, taken prima facie, implies the respondent
    simply flips the IP addresses and source-route and tosses it back in
    the net, presumably leaving the options alone. I think this is the right
    thing, but believe it should be explicitly stated.

Although the ICMP spec does say to simply reverse the IP source and
destination addresses, that is incorrect when the original IP destination
is a multicast or broadcast address.  In that case, the IP source address
of the Echo Reply (or Timestamp Reply, Information Reply, or Address Mask
Reply) should be set to one of the replying host's individual addresses
(presumably the one corresponding to the interface from which the reply
is sent).  I realize that many of you already know this, but it is a
common bug and this seemed like a good opportunity to point it out.

Let me also remind people that ICMP *error* messages (i.e., Destination
Unreachable, Source Quench, Redirect, Time Exceeded, or Parameter Problem)
should never be sent in response to a packet with a multicast or broadcast
IP destination.

Steve Deering
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 10:27:55 EDT
From:      gross@GATEWAY.MITRE.ORG (Phill Gross)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo


> A final tid: Should the TTL be reset at the echo server? If not, the
> sender would have a non-ambiguous way to measure the number of hops.
> He could, of course, also use record-route.

Have we really given up on the original meaning of TTL?  The Braden/Postel
RFC985-update still talks about TTL in seconds, possibly decremented by
more than one second at any gateway hop.  If vendors take this as seriously
as they are supposed to, then TTL will no longer be an unambiguous hop count.
In either case, I would argue on principle that the TTL should be reset in 
the echo reply.

Phill

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 11:49:03 EDT
From:      braden@ISI.EDU (Bob Braden)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

From Dave Mills:
	
	Finally, how about a new ICMP Echo/Echo Reply message that operates
	as the present one, but where the echo server captures the IP header,
	etc., in the same way as ordinary ICMP error messages before returning
	to sender?
	
Yeah, that sounds like the germ of a Good Idea.  The ANSI guys are
probably right, more effort is required to design the
monitoring/diagnostic tools we REALLY need. (But that doesn't mean we
need a 17-layered management architecture before we can make any
progress!).


Here is another example of a testing paradigm we cannot handle now.
In the testing Steve Casner and Mark Lambert have been doing across the
Wideband Net ("Fatnet"), they have wished they could do "one-way
pinging".  That is, they wanted to collect the same data that a normal
Mike Muuss pinger gets, but with no return trip, assuming they could
access the hosts on both ends.  
	
Bob Braden

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 11:55:49 EDT
From:      gary@ACC-SB-UNIX.ARPA (Gary Krall)
To:        comp.protocols.tcp-ip
Subject:   (none)


**All users of ACC's ACP 6250 and ACP 5250 boards** 

ACC has found a design problem with the RS232 
electrical interface connection, and an ECO has been
implemented to address this problem. Because this problem
can cause unreliable operation, ACC recommends
the return of the ACP processor board,
ribbon cable and distribution panel for up-dating.
Please note that the ECO will require modification of both the 
processor board and distribution panel, therefore please return
the complete system.

This is a no cost up-date to the equipment.  Concerned users
should call (805) 963-9431 (in California, Hawaii, or outside the 
U.S.) or (800) 222-7308 to obtain a return authorization (RA) number.

All Service One customers will be provided with replacement
units on a priority basis to minimize the impact of this update.

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 12:01:32 EDT
From:      braden@ISI.EDU (Bob Braden)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

The ICMP Echo Reply packet should start out with a new TTL value (in
your terms, yes, the TTL should be reset).  This follows from my
assumption that ICMP is a protocol layered above IP.

   Bob Braden
   

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 12:57:00 EDT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Bob,

    Well, I don't see why that would be more generally useful.  Presumably
    you use source route because you want to force a particular path, or
    to override some inadequate routing mechanism; it seems most likely that
    the same problem will hold along the path back to the source host.

This is exactly the point of using echo as a diagnostic tool in an
environment where routes out and back are NOT the same.  By forcing a packet
to a spot in the internet, using a source route to get it there via whatever
path you have found to work, you can explore/diagnose the "inadequate routing
mechanism", aka the default routing.

    I have heard other people talk about source routing a packet out and back
    to yourself, but this doesn't seem sensible to me.  As my message said, a
    host should send an Echo Reply only if the Echo Request message is
    DESTINED to it.  If, on the other hand, a host merely appears as an
    intermediate step in the source route, that datagram is not destined for
    that host, and the host should never look at the ICMP level of the
    datagram.

We agree that an echo request should only be turned into an echo reply by
the host to which it was destined.  Most systems allow messages to be sent
to themselves -- you can telnet, ftp, smtp, and ping (with ICMP echo requests)
to your own host (many systems bypass the net in such cases, allowing "loop-
back" tests to measure host & protocol throughput, cpu load, etc.).  The
scenario I was suggesting is to ping your own host, but force the outgoing
echo request through some portion of the net through use of a source route.
Why do this? Because some hosts have better diagnostic tools than others --
if you are trying to collect information using IP options and the desintation
host flushes them when forming an echo reply, you get nothing; but if your
host either doesn't flush the opions or allows you to see echo requests
that it receives, then you can get the information without the cooperation
of the other host.  (If collecting timing information you may win even more
due to the ability to estimate skew in clocks along the way.)

    Did I hear "network management"?
	
Certainly!  Haven't all the uses for ICMP echos which we have been reading
the last few weeks been for some form of fault or performance management?
Isn't "management" the reason that ICMP was created?

Also, I agree that Dave's point of not resetting the IP TTL is a good
idea, and that leaving the options alone should be explicitly stated.

If we are allowed to add to the wish list, ...
    I'll second Dave's suggestion for a way to capture the packet a la
ICMP error messages.  How about an option (possibly to Dave's) which would
cause each IP entity which processed the packet to send back such a reply
(analogous to the 1822 trace bit?);  launch a single probe and several
packets get returned showing the packet's progress through the internet
(beware of recursion!).
    I would like to suggest an internet parameters option: processed
by each IP entity along the path, it has fields for MTU, maximum bandwidth
(physical or "available"?), error rate, and "typical delay".  The 
originator sets the initial values for MTU and bandwidth to big values,
error rate and delay to small;  each IP entity along the path checks the
local parameters (for the inbound and outbound patha) and overwrites the
MTU or bandwidth fields if the local parameters are smaller, and the error
rate and delay if the local parameters are larger.  The recipient can then
find out some of the (admittedly instantaneous) characteristics of the
communications path.

I think the MTU information would be useful, especially given the
inherent problems associated with IP-level fragmentation, if only as
something to be used if a) IP decides to send an ICMP fragmentation
timeout message (piggyback the parameters option and the sender can
try something better), or b) TCP is having to do a lot of
retransmissions and wants to try something better.

The bandwidth parameter could be used to limit the maximum send data
rate -- no need to fill all the gateway queues before the bottleneck,
keep the data at the source so others can use the bandwidth of the
cross-paths.  (One of the hooks in our tcp was to pass a process's
controlling tty speed to TCP -- it could then send data at a rate
which wasn't too much for the user's terminal; it worked much better
than window-type flow control as the delay in the feedback path was
"eliminated", the response to telnet interrupts was much improved too
- little data in the pipe.)

Charlie

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 13:27:00 EDT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo


    From: CLYNN@G.BBN.COM :
    I would argue that the simplest implementation is the most useful --
    just change echo request to echo reply and switch the IP source
    and destination and send the packet back...

    From: Mills@UDEL.EDU :
    Your [Bob Braden's] model, taken prima facie, implies the respondent
    simply flips the IP addresses and source-route and tosses it back in
    the net, presumably leaving the options alone. I think this is the right
    thing, but believe it should be explicitly stated.

Although the ICMP spec does say to simply reverse the IP source and
destination addresses, that is incorrect when the original IP destination
is a multicast or broadcast address.  In that case, the IP source address
of the Echo Reply (or Timestamp Reply, Information Reply, or Address Mask
Reply) should be set to one of the replying host's individual addresses
(presumably the one corresponding to the interface from which the reply
is sent).  I realize that many of you already know this, but it is a
common bug and this seemed like a good opportunity to point it out.

Let me also remind people that ICMP *error* messages (i.e., Destination
Unreachable, Source Quench, Redirect, Time Exceeded, or Parameter Problem)
should never be sent in response to a packet with a multicast or broadcast
IP destination.

Steve Deering

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Tue, 28-Apr-87 22:35:40 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Bob,

Byte my tongue if I can't resist responding to your challenge. THe fuzzies
have been using one-way pings (between themselves)  since 1979. I discovered the
value of these things at 0500 the morning of the SATNET demonstration at NCC
while trying to bring up TOPS-20s in California, facsimile machines in London
and fuzzballs scattered all over, all this in the midst of power failures
at ISI, wandering satellite antennas in Maryland and buzzy amplifiers on
the convention floor. The one-way buggers were useful, since the satellite
channel was very flaky and we only needed it from London to Washington
for a packet-voice and facsimile demo.

All this was almost eight years ago when ICMP was really a wart on the side
of GGP. But that's a story for another time.

Dave

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Apr-87 21:05:58 EDT
From:      bob@nih-csl.UUCP
To:        comp.protocols.tcp-ip
Subject:   PCIP (TCP/IP for the IBM PC) problems


Problem:  Using MIT's PCIP software on an IBM XT or AT equipped 
          with the Enhanced Color Display occasionally causes the
          screen to go blank--that it, the screen is still
          being written to, but the intensity turns off.  Striking
          the function key F10 twice turns the intensity back on,
          for some reason.  Other problems occur when using PCIP
          with gnu-emacs.

Solution:  Is there one?

                                        Bob Dew
                                        National Institutes of Health
                                        Bethesda, MD 20894
                                        (301) 496-5361
                                        UUCP: seismo!elsie!nih-csl!bob

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29-Apr-87 22:07:26 EDT
From:      seasterb@CS.UCL.AC.UK (Steve Easterbrook)
To:        comp.protocols.tcp-ip
Subject:   tcp smooth rtt function

Whilst building a tool to monitor tcp's behaviour under various conditions
I came across an interesting feature of the smooth round trip time function.
As expected, this hovers around a value, responding to such things as
rtx time-outs, etc. However, when running tcp across a local net, (i.e. with
very small round trip time), I noticed a series of apparently random 'kicks'
where the SRTT suddenly shoots up to a relatively enormous value, coming
down only slightly less quick. After some careful analysis, I discovered
the cause. On the test I was doing, the round trip time was small enough
for the SRTT to reach zero occasionally. Examination of the tcp code reveals
that when modifying the SRTT, a test is made to see if it is zero, and if
so the usual RSRE smoothing function isn't used. 

The question is this: Can anyone give me some pointer as to what the
philosophy behind this is, and maybe some reference as well. I gather
its main purpose is to prevent the SRTT from staying at zero, as this
will cause tcp to be a bit keen on the retransmissions, but it seems
to me that substitute value is a little on the overkill side.

Ta muchly,
Steve

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Wed, 29 Apr 87 17:36:29 +0100
From:      Steve Easterbrook <seasterb@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   tcp smooth rtt function
Whilst building a tool to monitor tcp's behaviour under various conditions
I came across an interesting feature of the smooth round trip time function.
As expected, this hovers around a value, responding to such things as
rtx time-outs, etc. However, when running tcp across a local net, (i.e. with
very small round trip time), I noticed a series of apparently random 'kicks'
where the SRTT suddenly shoots up to a relatively enormous value, coming
down only slightly less quick. After some careful analysis, I discovered
the cause. On the test I was doing, the round trip time was small enough
for the SRTT to reach zero occasionally. Examination of the tcp code reveals
that when modifying the SRTT, a test is made to see if it is zero, and if
so the usual RSRE smoothing function isn't used. 

The question is this: Can anyone give me some pointer as to what the
philosophy behind this is, and maybe some reference as well. I gather
its main purpose is to prevent the SRTT from staying at zero, as this
will cause tcp to be a bit keen on the retransmissions, but it seems
to me that substitute value is a little on the overkill side.

Ta muchly,
Steve
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Apr 87 07:22:39 -0400
From:      tmallory@CCV.BBN.COM
To:        braden@VENERA.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, tmallory@CCV.BBN.COM
Subject:   Re: ICMP echo
Bob,

The LSI-11 gateways already have much of the one-way functionality you
probably need.  The gateway will send a trap message for each ICMP echo reply
received (you can turn this off).  The trap messages are timestamped (internal
format, but adequate for inter-packet arrivals) and include, among other
things, the 16-bit IP id field so that individual packets may be watched.  Of
course, you need access to the INOC...

Perhaps a little more work is needed.

Cheers,

Tracy
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 05:09:10 EDT
From:      mike@BRL.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

I have a routine called TTCP which is useful for testing both TCP and
UDP (inspired by a program of the same name that Excelan once sent a
friend to test *his* TCP).  By default, it acts much like a UNIX pipe,
extended to the network on one side;  optionally, it can source/sink a
given quantity of patterns.  Only occasionally useful as a
communications tool, it's great for tests and debugging. For your fatnet
tests, I'd use it in UDP mode with the source/sink option. While it will
tell you about packet loss, CPU and clock time used, it does not assume
the clocks are synchronized, so it does not try to make one-way timing
assessments.  That could be very easily added if times can be believed.

TTCP is my standard tool for conducting performance measurements;  on
various occasions I have used it to test TCP performance, effects of
window sizes, performance/overhead differences between various Ethernet
interfaces on the same machine, gateway performance, and end-to-end
InterNet performance.

The most interesting communications use of this tool is for sending
huge quantities of data painlessly between UNIX systems.  On rcvr,
run
	ttcp -r | tar xvf -
on sender run
	tar cvf - . | ttcp -t destinationhost

It has also been very useful for setting up "TCP relays" to avoid the
GGP extra-hop problem, and/or the EGP packet-fragmentation-induced
routing problem, when having to move > O(10 Mbytes) of data on our
troubled InterNet.

	Best,
	 -Mike

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 07:31:56 EDT
From:      jch@omnigate.clarkson.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Suffering


Tead Mean <mead@tut.cc.rochester.edu> writes:
>
>	There seemed to be a consensus that having diskless workstations and
>file servers on a network would cause havoc to an Ethernet.

I'd like to solicit comments on a configuration that our School of Engineering
has proposed:

They would like to purchase an Aliant super-mini-computer, a Sun 3/160 server
and 12 diskless 3/50s, 8 Opus Clipper systems (a PC/AT with a 32032 processor
board running a System V port (I belive)), and 83 IBM PC/AT clones running
Sun's PC/NFS.  The Opus system are supposed to be disk servers for the
PC/NFS systems where most of the computing is supposed to take place.  Most
of the PC/ATs will not have any hard disk, they will rely fully on the Opus
systems for disk storage.

All this equipment, in 4 buildings, will be linked with 3 fiber repeaters, 
making one large ethernet.

Our limited experience shows that one or two diskless 3/50s doing disk
intensive work (compiling programs or coping disk files around) significantly
affect the performance of both other diskless 3/50s and PCs on the same net
that do not make use of the file server (i.e. DECnet-DOS to a VMS system).

(The Imperial ;-)) We in the computing center would like to see some
partitioning of the ethernet into departmental segments connected to a
School of Engineering backbone with at least level II bridges.  In our
minds this would localize traffic to some degree, isolate potential
physical problems (shorted or broken cable, accidental or malicious)
and provide some measure of security.  This would not address problems
of the "Chernobyl" effect.

Does anyone have experience with a similar configuration of diskless
workstations and/or PCs that they can comment on?

Thanks

Jeff

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 08:46:02 EDT
From:      tsuchiya@GATEWAY.MITRE.ORG.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

> If we are allowed to add to the wish list, ...
>     I'll second Dave's suggestion for a way to capture the packet a la
> ICMP error messages.  How about an option (possibly to Dave's) which would
> cause each IP entity which processed the packet to send back such a reply
> (analogous to the 1822 trace bit?);  launch a single probe and several
> packets get returned showing the packet's progress through the internet
> (beware of recursion!).
>     I would like to suggest an internet parameters option: processed
> by each IP entity along the path, it has fields for MTU, maximum bandwidth
> (physical or "available"?), error rate, and "typical delay".  The 

I have been following the ICMP messages with interest, and note an
interesting turn in the trend.  Most of the earlier messages seemed
to me to praise ICMP Echo for its simplicity.  As Mills said, just
flip the source and destination address and shove it back out.
It seems to me that the beauty of Echo is that it is a very basic
and simple tool that can yield 90% of the information that one might
want with 10% of the effort.  Messages have shown that it can be
used for several quite different kinds of debugging.

We have discussed the "1822 trace bit" option in X3S3.3, and are
concerned about its Chernobyl-potential.  The internet parameters option
seems more like something a routing protocol or more sophisticated
(application layer) management function should provide.

In the standards environment, we have to provide pretty good justification
for putting management protocols at the network layer instead of at the
application layer.  One could probably justify a simple echo-probe at the
network layer for debugging purposes when that application layer has
failed, but echo-PLUS functions might be a little hard to swallow.

	Paul Tsuchiya		tsuchiya@gateway.mitre.org
	The MITRE Corp.		tsuchiya@mitre-gateway.arpa

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 09:45:00 EDT
From:      CLYNN@G.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: tcp smooth rtt function

Steve,
	It is well known that a TCP receiving an ack for a segment
does not know if the ack is for the original transmission or one of
the retransmissions.  The spec does not offer much help to the
implementor, consequently different algorithms have been explored.  IF
one measures the rtt from the most recent (re)transmission, then the
possibility exists that an ack of one of the prior transmissions may
arrive "about the same time" as the "next" retransmission.  If it is
just a little before, the segment acked, it is not retransmitted, and
the rtt is "reasonable", so one uses it; if it is just a little after,
who knows ...  one hopes for the best (and frequently looses); if it
arrives at the "same time", who knows.  It sounds like the
implementation you were measuring decided that it was a case of the
retransmission being acked and therefore didn't want to corrupt the
srtt by including what the implementors thought was bogus data.

Aside: I believe one can prove that if the rtt is not measured from
the original transmission (and no other information is available to
decide what is being acked) then it is possible for the srtt to
converge to a value less than the "correct" value; this causes every
packet to be retransmitted, even if it isn't lost.  I think there is
enough latitude in the protocol to allow an implementer to cause the
other end to unknowingly provide some good "hints" about what is being
acked, but that is another discussion.

Charlie

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 1987 09:45-EDT
From:      CLYNN@G.BBN.COM
To:        seasterb@CS.UCL.AC.UK
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: tcp smooth rtt function
Steve,
	It is well known that a TCP receiving an ack for a segment
does not know if the ack is for the original transmission or one of
the retransmissions.  The spec does not offer much help to the
implementor, consequently different algorithms have been explored.  IF
one measures the rtt from the most recent (re)transmission, then the
possibility exists that an ack of one of the prior transmissions may
arrive "about the same time" as the "next" retransmission.  If it is
just a little before, the segment acked, it is not retransmitted, and
the rtt is "reasonable", so one uses it; if it is just a little after,
who knows ...  one hopes for the best (and frequently looses); if it
arrives at the "same time", who knows.  It sounds like the
implementation you were measuring decided that it was a case of the
retransmission being acked and therefore didn't want to corrupt the
srtt by including what the implementors thought was bogus data.

Aside: I believe one can prove that if the rtt is not measured from
the original transmission (and no other information is available to
decide what is being acked) then it is possible for the srtt to
converge to a value less than the "correct" value; this causes every
packet to be retransmitted, even if it isn't lost.  I think there is
enough latitude in the protocol to allow an implementer to cause the
other end to unknowingly provide some good "hints" about what is being
acked, but that is another discussion.

Charlie
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 10:26:00 EDT
From:      CLYNN@G.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  ICMP echo

Bob,

    The ICMP Echo Reply packet should start out with a new TTL value (in
    your terms, yes, the TTL should be reset).  This follows from my
    assumption that ICMP is a protocol layered above IP.

I do not agree with the "This follows" logic.  There are instancces in
the suite where a protocol "above" IP obtains information from the IP
header and later returns it for use in a subsequent IP datagram; the
two most obvious examples are the source and destination address, and
one could even consider the IP type-of-service and protocol fields to
be in this category.

I think the desire should be to specify a tool so that it provides as
much information as possible (without "external" knowledge of the
implementation details of particular components in the system).  The
information gained by resetting the TTL is variations over time in "x"
on the way back (where "x" is hops or seconds or some combination);
one learns nothing about the way out.  The information gained by not
resetting the TTL is both variations in "x", summed over out and back
AND, since you specified the original TTL, the absolute amount by which
"x" changed (out and back).  Resetting gives one-way second-order
information while the not resetting it gives two-way first and second
order information.  The question is, if we can only have one, which is
more generally useful?

Charlie

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 1987 10:26-EDT
From:      CLYNN@G.BBN.COM
To:        braden@VENERA.ISI.EDU
Cc:        Mills@LOUIE.UDEL.EDU, postel@VENERA.ISI.EDU tai%hpltyj@HPLABS.HP.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  ICMP echo
Bob,

    The ICMP Echo Reply packet should start out with a new TTL value (in
    your terms, yes, the TTL should be reset).  This follows from my
    assumption that ICMP is a protocol layered above IP.

I do not agree with the "This follows" logic.  There are instancces in
the suite where a protocol "above" IP obtains information from the IP
header and later returns it for use in a subsequent IP datagram; the
two most obvious examples are the source and destination address, and
one could even consider the IP type-of-service and protocol fields to
be in this category.

I think the desire should be to specify a tool so that it provides as
much information as possible (without "external" knowledge of the
implementation details of particular components in the system).  The
information gained by resetting the TTL is variations over time in "x"
on the way back (where "x" is hops or seconds or some combination);
one learns nothing about the way out.  The information gained by not
resetting the TTL is both variations in "x", summed over out and back
AND, since you specified the original TTL, the absolute amount by which
"x" changed (out and back).  Resetting gives one-way second-order
information while the not resetting it gives two-way first and second
order information.  The question is, if we can only have one, which is
more generally useful?

Charlie
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 13:22:47 EDT
From:      tmallory@CCV.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: ICMP echo

Bob,

The LSI-11 gateways already have much of the one-way functionality you
probably need.  The gateway will send a trap message for each ICMP echo reply
received (you can turn this off).  The trap messages are timestamped (internal
format, but adequate for inter-packet arrivals) and include, among other
things, the 16-bit IP id field so that individual packets may be watched.  Of
course, you need access to the INOC...

Perhaps a little more work is needed.

Cheers,

Tracy

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 15:53:27 EDT
From:      seasterb@CS.UCL.AC.UK (Steve Easterbrook)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp smooth rtt function


>   It sounds like the
>   implementation you were measuring decided that it was a case of the
>   retransmission being acked and therefore didn't want to corrupt the
>   srtt by including what the implementors thought was bogus data.

Ah, excellent point, but I've managed to rule this one out. I'm monitoring
retransmissions as well, and there aren't any happening at the right time to
account for the behaviour I described. It seems
the SRTT is falling to zero purely due to rounding errors with very
small round trip times. However, this doesnt preclude the resulting
behaviour being due to the implementors allowing for the circumstances
you describe. 

There seems to be two possible approaches (given that it is undesirable to
have a SRTT of zero):
Let the SRTT do whatever it wants, but never let the RTT be rounded to zero,
or do something different with the SRTT if it does reach zero. Clearly
the second approach (whether intentionally or not) is taken in the tcp
I'm using. 
Given this, what alternative value should it be set to? Has anyone
tackled this problem before? And what happens if it *is* left at zero?
(I shall now go away and find out the answer to the last question!)

Steve

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 16:51:47 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: tcp smooth rtt function

I presume that you are using 4.3BSD; discussions of implementation
quirks are easiest to follow if the implementation is identified.
Things will behave strangely in 4.3 TCP if the smoothed round-trip
time becomes zero after the connection is established; it would do
just what you described.  The value of 0 is used to mean "unknown",
and causes the default (fairly long) value to be assumed.  The first
RTT sample (from first send of SYN to its ack) becomes the initial
value of the smoothed RTT.  It was assumed that the smoothed RTT
would never again be 0, as the RTT starts at 1.  I don't understand
how this can happen.

To respond to an early point in this discussion: this implementation
discards RTT estimates for segments that are retransmitted.  This
sometimes reduces the number of RTT estimates that are obtained,
but is much better than restarting the RTT timer when retransmitting.

		Mike

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30-Apr-87 22:26:44 EDT
From:      root@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Suffering

We use diskless Suns extensively.  We have around 40 diskless machines
on one Ethernet.  There is evidence that this causes more load than
one would prefer.  On the other hand, it is also not a disaster.  I'm
sceptical of 2 machines causing serious problems.  We'd rather keep it
to about 25.  Because of the critical dependence of Suns on their
Ethernets, and the wierd things that some TCP/IP implementations do to
the Ethernet, we keep diskless Suns on separate Ethernets dedicated to
just Suns.  We use a real IP gateway between the Ethernets.  Level 2
bridges would certainly help with the load, but would not necessarily
provide isolation from wierd packets.  Whether this is a problem
depends upon how confident you are in your TCP/IP implementations.

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Thu, 30 Apr 87 16:48:57 +0100
From:      Steve Easterbrook <seasterb@Cs.Ucl.AC.UK>
To:        CLYNN@g.bbn.com
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: tcp smooth rtt function

>   It sounds like the
>   implementation you were measuring decided that it was a case of the
>   retransmission being acked and therefore didn't want to corrupt the
>   srtt by including what the implementors thought was bogus data.

Ah, excellent point, but I've managed to rule this one out. I'm monitoring
retransmissions as well, and there aren't any happening at the right time to
account for the behaviour I described. It seems
the SRTT is falling to zero purely due to rounding errors with very
small round trip times. However, this doesnt preclude the resulting
behaviour being due to the implementors allowing for the circumstances
you describe. 

There seems to be two possible approaches (given that it is undesirable to
have a SRTT of zero):
Let the SRTT do whatever it wants, but never let the RTT be rounded to zero,
or do something different with the SRTT if it does reach zero. Clearly
the second approach (whether intentionally or not) is taken in the tcp
I'm using. 
Given this, what alternative value should it be set to? Has anyone
tackled this problem before? And what happens if it *is* left at zero?
(I shall now go away and find out the answer to the last question!)

Steve

END OF DOCUMENT