The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 02:03:10 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with UNIX tcp

On our emulation of Berkeley sockets (on a DOS PC), select() will indicate
that a connection is readable, writeable, and/or has an exception, depending
on which conditions were select'ed, if the connection has died.  The theory
is to cause the caller to do an I/O specific to that connection, whereupon
he will get an error.

In the process of determining what to do, it was discovered that this behaviour
is not consistent across real Unix implementations.  What does POSIX say?

James VanBokkelen
FTP Software Inc.

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1988 08:26-EST
From:      RWATKINS@G.BBN.COM
To:        tcp-ip@SRI-NIC.ARPA
Cc:        rwatkins@RCCB.BBN.COM
Subject:   Ethernet Terminal Servers

Does anyone have handy the phone number of Encore and Cisco ?

Is anyone using Bridge CS200's (in particular, hanging printers off of
ports) ?  Are you loading them via a Bridge Server, a PC Server or a Sun ?

Does the Encore and Cisco product allow loading and remote port configuration
from a Unix/Ultrix machine ?  Does anyone have printers connected to those ?

Thank you 

Ron Watkins
BBN
617-873-2817
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 1988 13:35-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        bzs%bu-cs.bu.edu@BU-IT.BU.EDU
Cc:        wb6rqn!brian@SUN.COM, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Exchanging serial numbers
From the ENTIRE IETF:

"Applause!"

Mike
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 11:58:19 GMT
From:      mf@savax.UUCP (Marc Fleischmann)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP vs. VMS & long passwords

In article <8802292102.AA06989@macduff.ultra.com> shj@ultra.UUCP (Steve Jay) writes:
>
>when attempting to use FTP server on a VAX VMS system, and the password
>for the VAX account is over 8 characters long.
>
>This has been observed with VAX's running Wollongong (versions 3.1 & 4.0)
>and Excelan (EXOS Version 4.5) servers.  Client FTP on a BSD 4.3

 I am running Excelan Release 3.3 V3-3Vv2 which has the server
EXOS Version 4.5 Mon Sept 8 8:41:17 PDT 1986 and have no problems with 
passwords of 16 characters using FTP clients from EXcelan, Ultrix V2.0-1
and Apollo.  

I am running MicroVMS V4.6.


/marc
---

-- 
Marc Fleischmann
Sanders Associates, Inc. - Nashua N.H.  (603) 885-5050
UUCP: ihnp4!decvax!savax!mf

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 01 Mar 88 17:16 EST
From:      "Mark D. Eggers (219) 239-7258"      <CF4A8X%IRISHMVS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Convergent Technologies
We are installing a campus network based on proNET 80,
tcp/ip, and DECnet. One of the first colleges to connect
will be the College of Engineering. They have several
Convergent Technologies 'miniframe' boxes that run System V
Unix and have tcp/ip. According to the grad student in
charge of their networks, they have the latest tcp/ip
software from Convergent Technologies.

Unfortunately, there are problems.

1. The 'miniframes' do not seem to understand any other
   class B addresses than xxx.yyy.0.zzz. Class C addresses
   seem to work fine. Class A addresses must be xxx.0.0.yyy.
   Would someone comment on the feasibility of using
   xxx.yyy.0.zzz as a subnet ?

2. No subnet support. Engineering currently has two subnets,
   and the 'miniframes' cannot communicate from net A to net
   B.

3. No route support (goes with the above).

4. No ARP.

Another annoying habit is that ftp between the 'miniframes'
and an Ultrix 1.2 microVAX hangs on files larger than 1019
bytes (and yes, I have turned off trailers on the microVAX).

Any possible solutions to the above problems (including
using the boxes for boat anchors) would be greatly
appreciated.

/mde/
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 13:26:00 GMT
From:      RWATKINS@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Ethernet Terminal Servers


Does anyone have handy the phone number of Encore and Cisco ?

Is anyone using Bridge CS200's (in particular, hanging printers off of
ports) ?  Are you loading them via a Bridge Server, a PC Server or a Sun ?

Does the Encore and Cisco product allow loading and remote port configuration
from a Unix/Ultrix machine ?  Does anyone have printers connected to those ?

Thank you 

Ron Watkins
BBN
617-873-2817

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 15:00:41 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Exchanging serial numbers

Brian,

With all due respect, this is a terrible idea and is not worth even the
effort to determine if other implementations will/will not break if the
option is used. The IP Security Option is a much better mechanism and
understood by most implementations known to me. If your scheme is less
than ubiquitous using this option, the Protocol Police would even be
expected to cooperate, since there are a lot of folks who are concerned
about the issue. If the option does not satisfy your needs and you have
a concrete proposal to add another, ubiquitous option that does, then
please honk and I expect the INENG and/or INARC Task Forces will take it
seriously. As it is, a copy-protect option that works only at TCP initial-
connection time will not be taken seriously.

Notwithstanding my view taken here, I would very much like to encourage
you to pursue the issue vigorously. In particular, I suggest you take it
up with Steve Kent's Privacy Task Force and with Deborah Estrin's
Autonomous Networks Task force. I will certainly keep it nearby in the
INARC Task Force.

Dave

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 16:52:32 GMT
From:      rossw@nezsupp.icl.co.nz (Ross Wakelin)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   tn3270, what and where

Hi, people here are just starting to mumble about 3278 type terminals,
connected to (yeuch) IBM type main(larf larf)frame machines, connected to
unix boxes over the ethernet.

Apparently there are boxes to convert "channel" to tcp/ip, but this tn3270 
thing is needed on the unix box.

Can anyone enlighten me please.

Thanks in advance,    Ross Wakelin

Ross Wakelin	uucp:                  uunet!vuwcomp!nezsupp!rossw
Unix Support Consultant                rossw@nezsupp.icl.co.nz
ICL (NZ) Ltd	                audio: +64  4   724 884
Wellington, NEW ZEALAND		snail: PO Box 394
				       Wellington, NEW ZEALAND 
"It's life Jim, but not as we know it, not as WE know it!!"

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 17:26:16 GMT
From:      bhoward@SOL.ENGIN.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)

Has anyone implimented support for SLIP on SVr3 or other SV variants?

			Bruce Howard
			Computer Aided Engineering Network
			University of Michigan

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 19:00:59 GMT
From:      shj@ultra.UUCP (Steve Jay)
To:        comp.protocols.tcp-ip
Subject:   Answer to FTP vs. long passwords

Thanks to those who responded to my query about long passwords
& FTP.  It turns out this is a known restriction in pre 4.3 clients,
which apparently use the standard C library routine "getpass" to prompt
for the password. "getpass" is restricted to 8 characters.  FTP was
fixed in 4.3, although obviously there are a lot of systems with the
problem still out there (latest Ultrix & UTS still have problem.)

Bob Bradford of Software Kinetics in Ontario (bradford@skl-crc.arpa)
pointed out that the "quote" command in FTP can be used to get around
the problem in pre 4.3 systems.  Open the connection, then enter
"quote user username" and "quote pass password" to the ftp prompt.  The
only disadvantage is the password is echo'd to the terminal.

Thanks again to those who responded.

-Steve

Steve Jay                       domain: shj@ultra.com
Ultra Network Technologies	Internet: ultra!shj@ames.arc.nasa.gov
2140 Bering drive               uucp: ...ames!ultra!shj
San Jose, CA 95131		
408-922-0100

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 19:11:57 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   Exchanging serial numbers


>The intention behind exchanging serial numbers is very simple: to keep
>the software from being useful if it is copied.  It protects by
>preventing an operator from gaining an advantage from the copy while the
>original is still running.  In this way it is definitely a form of copy
>protection.  The intention is to provide a scheme that will help protect
>our software in a manner that is totally transparent to the user.
 
>Now I will ask my original question again.  Will the appearance of a
>strange option in the TCP header cause a problem for other
>implementations of TCP?
 
>Brian Lloyd, President
>Sirius Systems, Inc.

What I don't understand is given as you feel so comfortable with the
idea of imposing various copy protection schemes to ensure maximizing
profits etc (or your prediction that it will maximize profits, whether
it will make your software fundamentally undesireable is argueable)
why do you expect free advice to further your profits on this network?

To respond in kind, many of us charge good money for consultations to
provide the information you desire, I suggest you change your request
to a help-wanted ad and put it somewhere appropriate. If it's not
worth anything to you it's surely not worth anything to us.

Check. Your move.

	-Barry Shein, Boston University

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 21:35:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re:  Exchanging serial numbers

From the ENTIRE IETF:

"Applause!"

Mike

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 21:48:47 GMT
From:      jsdy@hadron.UUCP (Joseph S. D. Yao)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.windows.misc
Subject:   rlogin from windows

On a heterogenous (System V / Ultrix) TCP/IP network, several people
use 'rlogin' from windows, and are surprised when the computer on the
far side believes that they have the full complement of lines and
columns.  My suggested solution was to add to the third rlogin
protocol setup line (for which I can find no definition) a third
field, so it would look like:
	<$TERM>/<baud-rate>/<lines>x<columns>
Since the System V terminfo uses environment variables $LINES and
$COLUMNS, we could use those on the System V machines; and we'd have
to get the Berkeley machines somehow to modify $TERMCAP based on
$LINES and $COLUMNS.

But, first, I thought I'd turn to the net and see whether anyone else
had any solutions.  Has anyone else had to address this problem?

Thanks muchly.  Please reply by E-mail, as I am sufficiently swamped
as not to get to these newsgroups very often.

	Joe Yao		jsdy@hadron.COM (not yet domainised)
	hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM}
	arinc,att,avatar,blkcat,cos,decuac,dtix,\
	ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy
	kcwc,lepton,netex,netxcom,phw5,rlgvax,	 /
	seismo,sms,smsdpg,sundc,uunet		/

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 22:16:00 GMT
From:      CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers  239-7258", 219)
To:        comp.protocols.tcp-ip
Subject:   Convergent Technologies

We are installing a campus network based on proNET 80,
tcp/ip, and DECnet. One of the first colleges to connect
will be the College of Engineering. They have several
Convergent Technologies 'miniframe' boxes that run System V
Unix and have tcp/ip. According to the grad student in
charge of their networks, they have the latest tcp/ip
software from Convergent Technologies.

Unfortunately, there are problems.

1. The 'miniframes' do not seem to understand any other
   class B addresses than xxx.yyy.0.zzz. Class C addresses
   seem to work fine. Class A addresses must be xxx.0.0.yyy.
   Would someone comment on the feasibility of using
   xxx.yyy.0.zzz as a subnet ?

2. No subnet support. Engineering currently has two subnets,
   and the 'miniframes' cannot communicate from net A to net
   B.

3. No route support (goes with the above).

4. No ARP.

Another annoying habit is that ftp between the 'miniframes'
and an Ultrix 1.2 microVAX hangs on files larger than 1019
bytes (and yes, I have turned off trailers on the microVAX).

Any possible solutions to the above problems (including
using the boxes for boat anchors) would be greatly
appreciated.

/mde/

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 22:45:32 GMT
From:      philipp@GMUVAX2.GMU.EDU ("Philip Prindeville")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Servers

All of the support telnet, I take it.  Most support rlogin.  Do any
support supdup also (on a try-sudpup-first-fallback-on-telnet basis)?

Thanks,

-Philip

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 23:29:03 GMT
From:      portal!cup.portal.com!rlhowe@uunet.uu.net
To:        tcp-ip@sri-nic.arpa
Subject:   Re: FTP vs. VMS & long passwords
In your discussion of long passwords on the VAX you said that you were
running EXOS version 4.5.  Is this really the case?  I ask this because the
latest version we have is 3.3.

Thank for any info.

Roger Howe
rlhowe@cup.portal.com
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 88 23:59:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   maximum Ethernet throughput

Someone recently asked:
    If anyone has figures on maximum through-put of 10 Mbps Ethernet, I could
    make good use of them.

The snide answer is "10 Mbit/sec".  Actually, the theoretical maximum is
about 9.9 Mbit/sec, because of the inter-packet gap, and perhaps closer
to 9.8 or 9.7 Mbit/sec if you count the addresses and CRC as wasted bits.

That's probably not quite what you wanted to know, but the question as
put does not have a single answer.  For example, do you want the
aggregate maximum or the maximum for a single pair of hosts?

For the latter, I believe Bill Nowicki of Sun has obtained 5 Mbit/sec
using TCP between Suns, and the Sprite people at Berkeley have
reached somewhere near 5.6 Mbit/sec using their kernel-to-kernel
RPC.  These numbers are both from memory; perhaps someone can confirm
or improve them.

The best numbers that I am aware of, for communications between a pair
of hosts, comes from Dave Boggs.  Using a pair of 15 MIPs processors
with an interface and software of his own design, and without much
of an operating system or any protocol (aside from the Ethernet data
link headers), he can get about 7.5 Mbits/sec obeying the Ethernet
spec, or at least 8.6 Mbits/sec if he "cheats" by sending 4Kbyte
packets.  (He once got >9 Mbits/sec with even larger packets, but
his current code doesn't support that.)

The limiting factor in his measurements seems to be that his interface
can only send one packet at a time; i.e., he must process one interrupt
per transmitted packet, which takes a few hundred microseconds.  The
interface can receive up to 16 packets using only one interrupt.  With
a more elaborate interface design, the theoretical limit should be
attainable.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2 Mar 88 9:04:05 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Flames to Brian Lloyd
I'm a little unhappy with the flames being sent to Brian Lloyd.  I understood
the basic form of his question to be:

  "If I invent my own option, is it likely to break other implementations?  If
   anyone tells me that even one implementation is sure to break I won't invent
   my own option."

This seems to me like the kind of reasonable and responsible behavior the folks
on the tcp-ip list ought to be trying to encourage.  It seems to me that we are
not likely to encourage it if our response is to make nasty comments about Mr.
Lloyd's motives.

Mr Lloyd attempted to explain why he was thinking of inventing his own option.
Lots of people told him why they thought it was silly, would be hard to
implement properly, that there were alternatives, and so on.  All those
comments seem quite proper, and this message is not trying to suggest
otherwise.  If he wants to hang his ideas out in public he should expect them
to draw critical comments.  I think he acknowledged this in his last message.
But I don't think its reasonable, or even in the group's own self interest, for
us to flame him for asking the question.

Cheers,
Alex McKenzie
 
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 1988 14:25-PST
From:      STJOHNS@SRI-NIC.ARPA
To:        terry@DEC-VAX-11-750.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP Options/Copy Protect
Terry,  Jon  Postel  has  decreed  that  for both TCP and IP, any
additional options will be of  the  second  type...   I.e.   self
encoding the length.

Mike
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Wed, 02 Mar 88 13:33:35 EST
From:      terry@DEC-VAX-11-750.ARPA
To:        tcp-ip@sri-nic.arpa
Cc:        terry@dec-vax-11-750.arpa
Subject:   Re: TCP Options/Copy Protect
All,

If there is an update to this, feel free to flame me, but please
be gentle.

****----

Brian Lloyd,

Mil-Std-1778, 12-Aug-1983, Page 92:

    There are two cases for the format of an option:

         a) A single octet of option-kind.

         b) An octet of option-kind, an octet of option-length,
            and the actual option-data octets.

The option-kind field determines the option being processed.  This
option-kind MUST be known, otherwise there is no way to tell whether
the next octet is a new option, or the length of the current option.

Therefore, further option processing cannot occur. 

Your Question: Will this upset any TCP implementations?
My Answer:     YES

In MY TCP implementation, an unknown option will cause a
message to be placed in a log file along with all of the 
remaining bytes in the TCP header.  If a valid option, such as 
maximum segment size, occurred after the unknown option the 
valid option would be ignored.  This could be serious.

I would take a guess and say that ALL TCP implementations are probably
not as gracious as mine.  Some probably would ignore the packet, others
might curl up and die, or worse.

*****-----

Non-TCP-Related-Topic:

There is a place for copy protection schemes in the world.  However,
your scheme only prevents your TCP from talking to itself, not to other
TCP implementations.  Besides the problem I stated above, it seems to
me that if you want to copy protect your software, do it right.  Don't
do it halfway.  There are several methods of controlling software execution
available.  Pick One.  If your company doesn't have the people to do the
job, hire someone.

****----

 Terry Robb
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Wed,  2 Mar 88 17:53 EDT
From:      AB Stine <ABSTINE@clvms.clarkson.edu>
To:        TCP-IP@sri-nic.arpa
Subject:   re: tcp/ip terminal servers
Here at Clarkson, we've been evaluating a number of TCP/IP terminal servers.
We've had the Bridge CS/100 in for a while, and its worked out rather well.
Haven't had any problems with it at all... it talks to all of our hosts
(BSD4.2,4.3, VMS (under CMU TCP), Gould UTX, Sun/OS, Alliant, PC's).
     
We are now evaluating a Cisco box. My first impressions of it are good... seems
to work very well... i'm not sure if it can really handle all 32 ports at
high speed though (its only got a 68000... i understand that they now have
a 68020 also). it also does Rlogin, which the bridge does not (yet).
     
In addition, we tried a Micom Server. We didn't do much with it though...
it was kinda slow, not very configurable. cheap though...
     
     
art stine
network engineer
clarkson u
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 14:04:05 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Flames to Brian Lloyd

I'm a little unhappy with the flames being sent to Brian Lloyd.  I understood
the basic form of his question to be:

  "If I invent my own option, is it likely to break other implementations?  If
   anyone tells me that even one implementation is sure to break I won't invent
   my own option."

This seems to me like the kind of reasonable and responsible behavior the folks
on the tcp-ip list ought to be trying to encourage.  It seems to me that we are
not likely to encourage it if our response is to make nasty comments about Mr.
Lloyd's motives.

Mr Lloyd attempted to explain why he was thinking of inventing his own option.
Lots of people told him why they thought it was silly, would be hard to
implement properly, that there were alternatives, and so on.  All those
comments seem quite proper, and this message is not trying to suggest
otherwise.  If he wants to hang his ideas out in public he should expect them
to draw critical comments.  I think he acknowledged this in his last message.
But I don't think its reasonable, or even in the group's own self interest, for
us to flame him for asking the question.

Cheers,
Alex McKenzie
 

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 15:43:31 GMT
From:      shore@REASON.PSC.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Convergent Technologies

I never had any problem with class B addresses (128.135.12.x).

The arp problem can be fixed by using adb to change the value of
"oldmap" to 0x7fffffff.  The code assumes that if the address is
greater than some value (I forget what) the hardware address can be
obtained by glomming together the first few bytes of your own Ethernet
address and the last two bytes (in the case of a class B network) of
the IP address of the host you're trying to reach.

Melinda Shore
Pittsburgh Supercomputing Center

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 17:05:29 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   rsh equivalent

I can't promise RFC conformance, but there is a way to make the
Berkeley r programs secure, and at least this change is documented.

I'm talking about the Kerberos authentication service.  It was
developed at MIT by Cliff Neuman, Jeff Schiller, and Jenifer Steiner
among others, and is a trusted third-party key distribution system, as
described by Needham and Schroeder.  It allows a client and a server
to both authenticate the entity at the other end of a connection, and
to exchange a session key which may be used for encryption.  Passwords
are never sent over the network in cleartext.

MIT's Project Athena has local versions of all of the Berkely r
programs that attempt to exchange Kerberos authenticators, before
falling back to the old-style authorization of .rhosts files.

For more info, see "Kerberos: An Authentication Service for Open
Network Systems" in the Winter 1988 Usenix Proceedings, or send mail
to steiner@ATHENA.MIT.EDU.  The new vesion of the code is going into
beta release now, and will be generally available later this year.
					-Mark

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 17:06:41 GMT
From:      fennell@inco.UUCP (Tim Fennell)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   XENIX TCP/IP software (IBM PC)



	HELP!!!

	I need to  know if and  where  I can find TCP/IP
	to run on the IBMPC/AT under XENIX OS. I currently 
	have a 3COM board but I only have a MS-DOS driver,
	I also  need a XENIX driver  with the TCP/IP.

	My time frame is real  short. As usual, my managers
	have assigned this to me and they need it yesterday.

	Any help would be appreciated.


					Thanks,
					Tim Fennell
					(800) 368-4626

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 17:33:19 GMT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

Unix has a near-equivalent of the RSH protocol in rexec().  One difference
is the port number (rexec() uses 512, RSH uses 514).  The other is that
rexec() always requires a password, where RSH has no mechanism for one.

We include a client program for rexec() in our DOS PC package, and I wrote
a primitive client program for Unix (that uses the library function).  It
amounts to about 50 lines of code.  We support the PC version because we
feel the security hole gets even worse when single-user PCs are involved.

As far as RFCs go, I don't know of any equivalent simple remote execution
protocol described by an RFC, and the only documentation for the 4BSD
protocols that I know of is in the man pages.

James VanBokkelen
FTP Software Inc.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 18:33:35 GMT
From:      terry@DEC-VAX-11-750.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Options/Copy Protect

All,

If there is an update to this, feel free to flame me, but please
be gentle.

****----

Brian Lloyd,

Mil-Std-1778, 12-Aug-1983, Page 92:

    There are two cases for the format of an option:

         a) A single octet of option-kind.

         b) An octet of option-kind, an octet of option-length,
            and the actual option-data octets.

The option-kind field determines the option being processed.  This
option-kind MUST be known, otherwise there is no way to tell whether
the next octet is a new option, or the length of the current option.

Therefore, further option processing cannot occur. 

Your Question: Will this upset any TCP implementations?
My Answer:     YES

In MY TCP implementation, an unknown option will cause a
message to be placed in a log file along with all of the 
remaining bytes in the TCP header.  If a valid option, such as 
maximum segment size, occurred after the unknown option the 
valid option would be ignored.  This could be serious.

I would take a guess and say that ALL TCP implementations are probably
not as gracious as mine.  Some probably would ignore the packet, others
might curl up and die, or worse.

*****-----

Non-TCP-Related-Topic:

There is a place for copy protection schemes in the world.  However,
your scheme only prevents your TCP from talking to itself, not to other
TCP implementations.  Besides the problem I stated above, it seems to
me that if you want to copy protect your software, do it right.  Don't
do it halfway.  There are several methods of controlling software execution
available.  Pick One.  If your company doesn't have the people to do the
job, hire someone.

****----

 Terry Robb

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1988 00:44-EST
From:      CERF@A.ISI.EDU
To:        karn@UCSD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Acking out-of-order packets?
My recollection of intent in RFC 793 was to have the TCP invite
the proper next packet by responding with the "next packet" ACK
and not with an ACK that references anything about the out of order
packet. 

Perhaps others will either remember differently or have a better
notion for how to behave under the circumstances described.
Obviously, if TCP had "out of order" acking and selective
retransmission, the response would be more complex.

Vint
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 20:46:47 GMT
From:      latzko@athos.rutgers.edu (Alex )
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP for AT&T 3B2'S

In article <46200003@ntvax> jacob6@ntvax.UUCP writes:
>Iam wondering if any of you folks know about any PD source
>of TCP-IP for AT&T 3B2 machines.  Your response in this matter
>UUCP: convex!ntvax!jacob6

Surely, you jest.  Seriously,  there is non or I would have it.  it
costs $$ from ATT

cheers
/S*

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 21:53:00 GMT
From:      ABSTINE@CLVMS.CLARKSON.EDU (AB Stine)
To:        comp.protocols.tcp-ip
Subject:   re: tcp/ip terminal servers

Here at Clarkson, we've been evaluating a number of TCP/IP terminal servers.
We've had the Bridge CS/100 in for a while, and its worked out rather well.
Haven't had any problems with it at all... it talks to all of our hosts
(BSD4.2,4.3, VMS (under CMU TCP), Gould UTX, Sun/OS, Alliant, PC's).
     
We are now evaluating a Cisco box. My first impressions of it are good... seems
to work very well... i'm not sure if it can really handle all 32 ports at
high speed though (its only got a 68000... i understand that they now have
a 68020 also). it also does Rlogin, which the bridge does not (yet).
     
In addition, we tried a Micom Server. We didn't do much with it though...
it was kinda slow, not very configurable. cheap though...
     
     
art stine
network engineer
clarkson u

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 88 22:25:00 GMT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Options/Copy Protect

Terry,  Jon  Postel  has  decreed  that  for both TCP and IP, any
additional options will be of  the  second  type...   I.e.   self
encoding the length.

Mike

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Thu, 03 Mar 88 08:32:04 -0500
From:      haverty@CCV.BBN.COM
To:        Phil Karn <karn@UCSD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM
Subject:   Re: Acking out-of-order packets?
Phil - even if a TCP sends 'do-nothing' ACKs, nothing should depend on
that behavior, since the ACK is unreliable - as a datagram, it might get
lost in transit.  Jack
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 02:03:30 GMT
From:      ehrlich@blitz (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Link level Ethernet bridges (Modified)! does that mean joke?

Once upon a time, in another job far, far, away I also encountered
these mysterious aa:0:4:0:xx:xx addresses.  Read on.  Maybe someone
can explain to me why DEC does what it does.  :-)

In article <8802232312.AA02132@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes:
>...
>
>	segment #1				segment #2
>
>  8:0:20:1:33:1e  Ha--|                        |--Hz    8:0:2b:3:92:23
>  		      |                        |
>  8:0:20:1:47:d2  Hb--|                        |--Hz-1  8:0:20:1:d7:e5
>		      |icmp              icmp  |--Hy    2:7:1:0:a6:59
>   8:0:9:0:65:3d Hp*--|echo->            echo->|--Hx    aa:0:4:0:da:4 hummmm.  
                                                         ^^^^^^^^^^^^^

This mystery number is from a VAX running DECnet, either under VMS or
Ultrix.  It could also be from another vendor that has implemented
DECnet's host->ethernet address mapping.  DEC in their infinite wisdom
uses one of the maintenance functions in the DE[QU]NA to change the
physical ethernet address from what is in the ROM to this magic
number.  I do not know if they have gotten around to documenting how it
is computed, but if memory serves me correctly it goes something like
this:

	aa:0:4:0	is a magic constant that appears on any VAX
			running DECnet.

	da:4		is, get ready, the DECnet host and area number
			(byte swapped of course).  Educated guess says
			that this is DECnet host 1.218.  (Area number)
			* 1024 + (Host number).

When I asked DEC why they do this I got numerous excuses.

    "Keeping a table mapping DECnet host numbers to Ethernet addresses
     would soak up too much memory"
     "We do not have anything like ARP and do not expect to in the
      near future"
     "Whoes name is on the fron of the 'Blue Book' anyway?".

All of these are from the 1986 time frame and as I have not had reason
to ask the question of late do know know if the responses are still
valid.

>   		       nada            <-reply |
>		      .                        .
>		      .                        .
>		      .                        .
>  8:0:20:1:66:6a  Hq--|                        |--Hr    8:0:2b:3:91:5c 
>      		      |----?[DEC lanBridge]?---|
>      	    
>        SUBNET 1 of Class B network 128.165, mask==0xfffffc00
>
>There is probably alot of irreverent/irrelevant, but, it was fun.
>...
Dan Ehrlich <ehrlich@psuvax1.{psu.edu,bitnet,uucp}>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 02:36:20 GMT
From:      jwkhong@grand.waterloo.edu (James W. Hong)
To:        comp.protocols.tcp-ip
Subject:   Implicit acks in TCP?


I wonder if someone could clarify a point for me regarding acks in
TCP.  Are implicit acks allowed in TCP?  What I mean by an implicit
ack is that each request or response message serves as an implicit
ack for the previous response or reqeust message from that client,
respectively.

What BSD4.3 version TCP seems to do is to ack a request packet immediately
and sends the requested data in a separate packet.  This requires 
4 packet exchanges rather than 2 if an implicit ack is used.

Does the TCP spec. disallow using implicit acks?  Or does it depend on
TCP implementations?

----------------------------------------------------------------------------
James W. Hong                              	  jwkhong@grand.waterloo.cdn
Dept. of Computer Science              	        jwkhong%grand%waterloo.csnet
Univ. of Waterloo      	       jwkhong%grand%waterloo.csnet@csnet-relay.arpa
Tel: (519) 885-1211 x6178

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 02:58:20 GMT
From:      karn@UCSD.EDU (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Acking out-of-order packets?

During conversations with Van Jacobsen here at the IETF meeting, I discovered
an abiguity in the TCP spec (RFC-793 at least), to wit:

What response (if any) should you make when you receive an out-of-order
segment? RFC-793 says pretty clearly that you should return an empty ACK
(indicating the sequence number you expect to receive next) if the packet
is "unacceptable" (i.e., not in the window) but it doesn't say whether
you should respond if the packet is in the window but not the next one
expected. It says only that they should be kept for future processing.

My TCP in fact makes no response to an out-of-order data segment. Others
apparently respond with "do-nothing" ACKs. One of Van's performance tricks
depends on that behavior. Any guidance on what is the Right Thing here?

Thanks,

Phil Karn

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 03:53:11 GMT
From:      wcs@ho95e.ATT.COM (Bill.Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
:The reason I am interested in something other than rsh is because
:here at UNM we are strongly considering disallowing the r* programs
:(rsh/rcp/rlogin) because they do NOT conform to the RFC's
:[(machine name case independent).]
:as well as being BIG security problems (.rhosts).

My big gripe with the r* programs is that they lose UNIX semantics.
For instance, rsh doesn't return the condition code from the remote process -
	rsh foovax false
returns true if the connection succeeded.  Less important but harder to fix,
rsh is non-interactive; I've gotten real used to Datakit's remote execution
capabilities ("dk other3b /bin/ksh").  It would also be nice to have a
convenient rcp-variant that didn't update modification times.

I'm less bothered by machine-name-case dependence - r* are specifically
UNIX utilities, and case dependence is appropriate.  (By contrast, HP's
NS-9000, NS-VAX, NS-etc. utilities are supposed to be transparent between
systems; it took us several days of cable-testing to find that the 350
didn't accept it's name in uppercase, as generated on a VMS microvax.)
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 03:55:06 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Creating TCP options

Thanks for the feedback.  Although some of you were a bit vociferous I think
that all the responses I received were useful and well thought out.  We did
do an implementation of the concept (adding a serial number as a TCP option
field) and it worked fine when talking to a 4.3 bsd system.

I think that we are going to take a different tack.  The UDP broadcast idea
seems to be the most reasonable I have heard so far.  I will let you know
where we go.

Again, thanks for the feedback.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 05:44:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?

My recollection of intent in RFC 793 was to have the TCP invite
the proper next packet by responding with the "next packet" ACK
and not with an ACK that references anything about the out of order
packet. 

Perhaps others will either remember differently or have a better
notion for how to behave under the circumstances described.
Obviously, if TCP had "out of order" acking and selective
retransmission, the response would be more complex.

Vint

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 06:04:07 GMT
From:      karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent


> I am looking for PD version of code that accomplishes the same thing
> as rsh but conforms to the RFC's (machine name case independent).
> We have users who like to pipe BIG jobs from one machine to another
> machine via rsh's.  

Conforms to *what* RFCs?  In particular, machine name case independence
isn't the subject of any RFC, and has no bearing on remote login or
execution facility protocols or specification.  It's a user-interface
issue.  Incidentally, when using the nameserver for hostname lookup,
this interface *is* case insensitive.  You seemed to have picked upon
the most trivial of criteria for judging such protocols and implementations.

(None of the above should be construed as defense of the rlogin and rsh
facilities.  The main reason that I haven't made any attempt to document
these "protocols" publically is that it might help to keep them from
proliferating.  I've been lobbying a few people to try putting a few options
into telnet that would give it every capability of rlogin and many more,
so that we could toss rlogin out.  The current wish-list is negotiation
of local or remote flow control, automatic user-name propagation and login,
and maybe even exporting the Unix environment, which rlogin doesn't do either.
Sun's "on" program does this, but I haven't looked at it much.  Automatic
switching between character and line mode with local echoing may be a win,
and can already be done by our current telnet clients.)

> The reason I am interested in something other than rsh is because
> here at UNM we are strongly considering disallowing the r* programs
> (rsh/rcp/rlogin) because they do NOT conform to the RFC's as well
> as being BIG security problems (.rhosts).

The .rhosts file isn't the problem; you're picking on the wrong things.
However, see the reply about Kerberos.

		Mike

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 1988 1459-PST (Thursday)
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        tcp-ip@sri-nic.ARPA
Subject:   Ethernet speeds revised
Two days ago I sent a message describing some experiments Dave Boggs
had been doing to see what kind of host-to-host throughput the
Ethernet could carry.  Science marches on; since I sent that message,
he has revised his results twice (once by clever programming; once
by turning on the compiler optimizer).  Again, this is for data sent
from one host to another over a 10 Mbit/sec Ethernet, not using any
protocols aside from the data link header, nor much of an operating
system.

The new numbers are:

	1536-byte packets			9.2 Mbits/sec
	(maximum "legal" Ethernet packet)

	4000-byte packets			9.6 Mbits/sec
	(don't try this at home)
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 13:30:08 GMT
From:      jmg@cernvax.UUCP (jmg)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP vs. VMS & long passwords

In article <8802292102.AA06989@macduff.ultra.com> shj@ultra.UUCP (Steve Jay) writes:
>
>   "530 Login failed (bad Username or Password), give new USER and PASS "
>
>when attempting to use FTP server on a VAX VMS system, and the password
>for the VAX account is over 8 characters long.

Same problem seen on trying to FTP to a Vax from the IBM TCP/IP on our
VM system.
(After hacking attacks many people go beyond 8 characters!)
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 13:32:04 GMT
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?

Phil - even if a TCP sends 'do-nothing' ACKs, nothing should depend on
that behavior, since the ACK is unreliable - as a datagram, it might get
lost in transit.  Jack

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 14:04:13 GMT
From:      pgc@newcastle.ac.uk (P. G. Cutting)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   campus ethernet help?


As a research group at Newcastle University England, investigating the monitoring and management aspects of our prospective campus network (ethernet backbone). We would like to hear from other universities / sites on the following in particular:

a) Internetworking using Bridge Links via Backbone.

b) Information regarding Network Monitering and Management methods in use.

c) synopses of users of the network - equiptment/software/loading.

d) problems eg bottlenecks in the Network.

We would be interested to hear from users of any large campus - not specifically using ethernet.

Thanks in advance,

CSSD@UK.AC.NEWCASTLE

Computing Laboratory,
The University of Newcastle,
Newcastle Upon Tyne,
NE1 7RU,
ENGLAND.

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 16:15:54 GMT
From:      karn@UCSD.EDU (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?

Nothing really "depends" on those do-nothing ACKs, in the sense that the
protocol still operates correctly even if they are lost.

I should probably let Van describe his own technique, but basically it
involves interpreting a flurry of do-nothing ACKs as an indication that
an early packet was lost. This triggers a retransmission before the timer
would ordinarily expire and do it.

This appears to be a big performance win over networks with large 
bandwidth*delay products (e.g., the Wideband net).

Phil

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 20:48:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?

[I wasn't on the design team.]  I would strongly suggest that any
next-packet ACKs generated by out of order segments wait until the
network input queue is empty.  For a multitude of reasons, the medium
or the implementation may reverse some packets on you.  (E.g., in past
releases, the 3600 had LIFO transmit and receive queues, but since
transmitting a packet is fast the transmit queue is effectively FIFO,
and the receive queue is processed by a process/task.  We now reverse
the receive list.)  I agree that encouraging the sender to retransmit a
packet that should have arrived helps performance.  I'm asking that
people be careful in making the "should" determination.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 21:15:27 GMT
From:      dzoey@TERMINUS.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

> Less important but harder to fix,  rsh is non-interactive; 

There's nothing in the rsh/rexec protocol that says it's not
interactive.  It is possible to write your own rsh/rexec program that
accepts and issues character i/o.  After all, rsh/rexec protocols just
describe how to establish data streams and do some trivial
authentication.  If you invoke an interactive process with your rsh
command you can do interactive processing (with some exceptions). 
Certain programs (like more) will not work correctly since there is no
terminal attatched.  Rsh/rexec are not virtual terminal protocols
and the BSD server does not establish a pty for the process.  
Programs will work if they only look at environment variables for
terminal information.

I've only tried this in a BSD (or derivitive) environment.  I don't know
how other OS's handle rsh/rexec requests.


                                Joe Herman
                                PC/IP project.
                                The University of Maryland
                            

dzoey@terminus.umd.edu

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 21:24:22 GMT
From:      dewey@auscso.UUCP (Dewey Coffman)
To:        comp.protocols.tcp-ip
Subject:   TLI?



	Does anyone have any information or pointer to information about
	a new product called TLI out of AT&T(?) that is supposed to
	replace tcp/ip on UNIX? E-mail is preferable, but post if
	of general interest.

	dewey coffman
	austin, texas
	auscso!dewey

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 21:39:25 GMT
From:      rfox@AMES-NAS.ARPA (Richard Fox)
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?


>During conversations with Van Jacobsen here at the IETF meeting, I discovered
>an abiguity in the TCP spec (RFC-793 at least), to wit:
>
>What response (if any) should you make when you receive an out-of-order
>segment? RFC-793 says pretty clearly that you should return an empty ACK
>(indicating the sequence number you expect to receive next) if the packet
>is "unacceptable" (i.e., not in the window) but it doesn't say whether
>you should respond if the packet is in the window but not the next one
>expected. It says only that they should be kept for future processing.
>
>My TCP in fact makes no response to an out-of-order data segment. Others
>apparently respond with "do-nothing" ACKs. One of Van's performance tricks
>depends on that behavior. Any guidance on what is the Right Thing here?

Getting a packet out-of-order can mean 1 of 2 things:
	1. Preceding packets were dropped or corrupted and dropped.
	2. The preceding packets are taking a different path than the one
		just received.

In case 1, responding with a "do-nothing" ACK, would get the original
sender to resend the packets before the timeout period elapses. In the case
of a high delay large bandwidth link this is very advantageous to do. Our
TCP will keep out-of-sequence packets on a queue and try to reassemble packets
as they come in until we are caught up. This is a win situation if you delay
your acks. If you immediately send a "do-nothing" ACK the sender will resend
whats already been sent again. Since the packets need to be resent anyways,
being that they will never make it, sending a "do-nothing" packet seems to
be a winner. Also, we might assume that the packet was lost/dropped
because of congestion ( since less than 1% of dropped packets is due to
corruption due to link errors) and then this would set the congestion
control algos. into action much quicker. Thus, congestion can be stopped
much quicker!

As an aside:
So the question at this point is do
we really want to keep the extra complexity of doing reassembling of packets
in the TCP layer as well as the IP?

In case 2, responding with a "do-nothing" ACK would, like in case 1, get the
sender to resend the packets before the timeout period elapses. But since
the packets are going to make it, just a little later than the out-of-seq
packet, this would cause excess packets to be sent over the net. If we
assume that the packets took different paths because of congestion on
a particular link, this could potentially aggravate the congestion problem.
Of course, Van;s algorithm will back off a bit to control the congestion.
Ultimately this could mean that the receiver would tell the sender to re-xmit
all of the packets again, the sender will assume that the network is
congested and should use caution in resending the packets, the receiver
receives all of the packets before the sender has time to re-xmit them all.
The receiver then sends an ACK for all of the data and the sender will not
have to re-xmit all of the packets and can go on transferring new data
by opening back up its congestion window.

I think in case 2 this will work if the assumption that the packets took 
different routes because of congestion, with the use of Van's algo. If 
a gateway puts packets on different links for the purpose of load
balancing and congestion avoidance then the scenario above for case 2
would break down and the best solution would be to delay any acking for
a period to see if the data is still yet to come. W might still want to
wait for a small period, being that the period be less than the normal
timeout periods currently used.

I am not convinced that load balancing is a good idea, thus, would like to
be able to assume that the only time a packet would travel on a different
route than the previous packet is due to congestion. Then I think
immediately sending a "do-nothing" ACK would be feasible even for
out-of-seq packets that are in the window.


>Perhaps others will either remember differently or have a better
>notion for how to behave under the circumstances described.
>Obviously, if TCP had "out of order" acking and selective
>retransmission, the response would be more complex.
>
>Vint

Up above I have stated that sending a "do-nothing" ACK immediately is
probably the correct thing to do because to try and do anything else would
require more complexity, complexity that TCP was not intended to handle.
If we want the extra complexity, this would mean moving towards a transport
level protocol like VTMP or something like a NETBLT type protocol, which
is quite different than TCP. In the future I think we will need to move
in the direction of a VTMP like protocol so would like to keep it out of
TCP. 



Rich

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 88 22:08:20 GMT
From:      rfox@AMES-NAS.ARPA (Richard Fox)
To:        comp.protocols.tcp-ip
Subject:   Re:  Implicit acks in TCP?

TCP is a byte stream protocol. This means that it works based on bytes
being sent, not packets per se. Thus, you'll notice that the ACK field
is acking bytes not packets sent. To ack each byte individually would
take forever, so the ack is stating which byte it expects to receive
next ( or as you put it, it is implicity ACK'ing all data up to a certain
point). Since each packet of data contains an ACK, if you notice that
you are sending 4 packets instead of 2, where 2 would suffice if ACKS
are piggybacked, then it is your implementation adding the extra
packets, not the protocol. 

I believe the problem you stated with your implementation is happening
because you have delayed acking turned off. This means as soon as you
know you can ack something received do so, then go ahead and process
the request ( ie: get and send the data).

Hope this helps some,
rich

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 15:17:47 GMT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Exchanging serial numbers

In article <669@taurus.BITNET>, leonid@TAURUS.BITNET writes:
> In article <8802251906.AA04676@wb6rqn.UUCP> brian@wb6rqn.UUCP writes:
> >Here at Sirius Systems we have been discussing a means to protect our
> >TCP/IP software without placing undue strain on the users. ...
> 
> May I mention a very much similar solution done by Sun Microsystems in their
> PS-NFS 2.0 product, and please excuse me if this has already been mentioned.
> They just used ICMP discard packets to broadcast the serial number of each
 [...]
> To tell you the truth, I'm not really sure weather they use ICMP discard or
> UDP discard packets...

We use UDP discard packets (UDP port 9), and we wind up sending one about
once an hour (depending on usage pattern). It hasn't broken any nets yet,
as far as I know (and I'm sure the flames would have come thick and fast :-).
And like Leonid I'd prefer an "official" solution. Anyone interested in
talking about it?
> 
> Leonid

Geoff Arnold
PC-NFS architect


-- 
Geoff Arnold, Sun Microsystems     | "Universes are just one of those things
SPD at ECD (home of PC-NFS)        | that happen from time to time..."
UUCP:{ihnp4,decwrl...}!sun!garnold | [Dunno who said it - if you know, pass it
ARPA:garnold@sun.com               | on. G.A.]

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 15:59:41 GMT
From:      slevy@UC.MSC.UMN.EDU ("Stuart Levy")
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?

Be aware that packets may have other reasons for arriving out of order than
that they've followed multiple paths.  One possible strategy for giving
interactive traffic priority over bulk data on a crowded link is to 
preferentially forward small packets.  I don't know of any specification
that says this shouldn't be done.  We've used an Ethernet bridge that actually
does this, and caused a 4.2 TCP bug to be exercised (when a FIN arrived earlier
than some trailing data, the FIN was ignored.  The peer TCP had a bug that
caused it to never retransmit a FIN, and so...).

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 16:09:53 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for AT&T 3B2'S


>In article <46200003@ntvax> jacob6@ntvax.UUCP writes:
>>Iam wondering if any of you folks know about any PD source
>>of TCP-IP for AT&T 3B2 machines.  Your response in this matter
>>UUCP: convex!ntvax!jacob6
>
>Surely, you jest.  Seriously,  there is non or I would have it.  it
>costs $$ from ATT

As a callow youth I wrote a udp/ip and tftp for the 3B which can be
picked up from BU-IT.BU.EDU's anon area, src/network/udp.3b/*. I have
no idea of it works under current releases although other than the
ethernet device assumptions (/dev/ni if I remember right) I can't
imagine it's too far off. Feel free, I certainly have no interest in
supporting it etc as we don't use 3B's anymore, mostly due to its
lack of TCP/IP...

	-Barry Shein, Boston University

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 16:40:38 GMT
From:      clyde@ut-emx.UUCP (Head UNIX Hacquer)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet Terminal Servers

We here have Encore Annexes, most of which are connected to our Encore
Multimax, but we are using one for general Ethernet access.  They seem
to work fairly well, and you can upload/download port configurations
from any UNIX host, since Encore supplies the source for the Annex
administrator program.  An Annex has 16 serial ports and one parallel
printer port.  We are using Printronix P300 (I think) on a parallel port.

You can remote access serial ports on an Annex from a network host via telnet,
if they have been set up so, and from the UCB line printer system.  If you
want to run a simple serial printer this way, it will work - I don't know
about "smarter" printers such as Apple LaserWriters.

The Annex boxes are nice, but for general usage I would probably look at
the Cisco boxes, for they have (on paper at least) more useful features
(such as Serial Line IP).

	Encore phone #: 1-800-336-2673

	-Clyde Hoover
-- 
Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas  
	clyde@ngp.utexas.edu; ...!ut-sally!ut-ngp!clyde
"It's a sort of a threat, you see.  I've never been very good at them
myself, but I've told they can be very effective."

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 17:56:51 GMT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   Mil-Standards draft docs available

The Defense Communications Engineering Center (DCEC) Protocol Laboratory
invites comments from the Internet community on the following draft
documents.  These documents outline the conformance tests developed
for the DoD Mil Std protocols.  The comments can be about any aspect of
the document, but in particular, opinions are requested on the accuracy and
completeness of the test procedures.  The documents are unrestricted so
comments will be accepted from the entire Internet community.

THE DOCUMENT TITLES ARE:

	1.  DCEC Protocol Laboratory Internet Protocol 
	      MIL-STD-1777 Certification Tests Index, DRAFT
	2.  DCEC Protocol Laboratory Transmission Control Protocol (TCP)
	      MIL-STD-1778 Traceability Matrix, DRAFT
	3.  DCEC Protocol Laboratory File Transfer Protocol (FTP) 
	      MIL-STD-1780 Certification Tests Index, DRAFT
	4.  DCA Protocol Laboratory Simple Mail Transfer Protocol (SMTP) 
	      MIL-STD-1781 Traceability Matrix, DRAFT
	5.  DCEC Protocol Laboratory TELNET Protocol (TELNET)
	      MIL-STD-1782 Certification Tests Index, DRAFT

HOW TO OBTAIN THE DOCUMENTS:

Online versions are available through FTP or through SERVICE, the NIC's 
automatic mail service.  The pathnames and byte sizes are:


	PROTOCOLS:MSTD-1777-TESTS1.DOC		 394602 bytes
	PROTOCOLS:MSTD-1777-TESTS2.DOC		 356791
	PROTOCOLS:MSTD-1778-TESTS.DOC		 102460
	PROTOCOLS:MSTD-1780-TESTS.DOC		 62915
	PROTOCOLS:MSTD-1781-TESTS.DOC		 75244
	PROTOCOLS:MSTD-1782-TESTS.DOC		 55962


The DDN NIC can provide hardcopies of the set of documents for $50
(USA and Canada) and $90 overseas to cover the cost of reproduction,
postage and handling.

Send a written request, accompanied with payment in the form of check,
money order, or company purchase order (made payable to SRI International)
to:

	SRI International
	DDN Network Information Center
	Room EJ291
	333 Ravenswood Avenue
	Menlo Park, CA  94025

Please include your full name, business address, and zip code.
California residents should add 6.5% sales tax to their order total
(except military users).  


SENDING YOUR COMMENTS:

Comments are to be sent via electronic mail to COMMENTS@EDN-UNIX.ARPA
Please be sure to indicate to which document or documents your comments
refer.
-------

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 18:34:31 GMT
From:      taylor@ATOM.HPL.HP.COM (Dave Taylor)
To:        comp.protocols.tcp-ip
Subject:   TCP / Berkeley Networking Suite wanted...

[Please Reply To: motsj1!nswed5!efb, motsj1!nswed5!unicom!dlt]

Hello.

The following is a forwarded message from a chap with the USN in Port Hueneme,
California, and another chap at UNICON in Santa Ana, California about TCP/UDP 
sources and the related protocol suite.

As I believe this group to be the appropriate forum for answering this
question, I am herein forwarding the message sent to me.  I should also
point out that neither I, Everett, or Dan currently receive this mailing 
list, so replies should be sent direct (to them, not me, please).

Thank you very much.
						-- Dave Taylor
--------

From: hplabs!motsj1!nswed5!efb (Everett F. Batey II),
      hplabs!motsj1!nswed5!unicon!dlt (Dan Taylor)
Subject: A question about TCP / UDP sources
Date: Thu, 3 Mar 88 14:39:23 PST

[...] We have a Unix 5.2 / 5.3, Motorola 68020 (VME 10 / 1100 ), 
and hold AT&T / Motorola, V68 5.3.3 Source license with RFS.  

Dan Taylor, of UNICON, Santa Ana, a VME sw/hw system development shop 
has examined the 5.3 sources and the CMC, Santa Barbara, sources which
Motorola resells for VME / V68 system:

> You are aware of the tools that are not supplied by CMC, both TCP/IP and
> the total lack of UDP/IP support.
>
> I am hoping to find is a complete TCP, UDP, and IP protocol suite, generic,
> that is coded for a UNIX host ( if you find one, it will probably be bsd), 
> and sources for the associated utilities.  Given that so much development 
> of those protocols was funded by the government, I was hoping to avoid 
> large fees.

We are trying hard not to reinvent the public domain wheel.

Can anyone suggest a source for the TCP and UDP utility socket source code?

Everett F. Batey II - USNSWSES EDMICS V Project
sun!tsunami!nswed5!efb - Port Hueneme,CA     805/982-5881
--------

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 19:23:47 GMT
From:      markl@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?


   Date: Fri, 4 Mar 88 09:59:41 CST
   From: "Stuart Levy" <slevy@uc.msc.umn.edu>

>   Be aware that packets may have other reasons for arriving out of order than
>   that they've followed multiple paths.

I recall that at one point Wideband Network BSATS also had a tendency
to re-order packets--by pushing to the end of the queue those packets
which had missed their satellite reservations.

markl

Internet: markl@ptt.lcs.mit.edu

Mark L. Lambert
MIT Laboratory for Computer Science
Distributed Systems Group

----------

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 20:38:11 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Implicit acks in TCP?

In article <17229@watmath.waterloo.edu> jwkhong@grand.waterloo.edu (James W. Hong) writes:
>I wonder if someone could clarify a point for me regarding acks in
>TCP.  Are implicit acks allowed in TCP?  What I mean by an implicit
>ack is that each request or response message serves as an implicit
>ack for the previous response or reqeust message from that client,
>respectively.

Your question indicates that you misunderstand TCP.  TCP does not have
any notion of "request" and "response" messages; some higher-level
protocols, such as RPC (Remote Procedure Call), may have them, though.
TCP implements a reliable bidirectional stream of octets on top of a
lower-level unreliable datagram facility (generally IP).  TCP doesn't
require that every transmission in one direction be followed by a
transmission in the other direction.

Every TCP datagram includes an explicit ack, so there can be no
"implicit" acknowledgements.  However, for ease of implementation,
most implementations send an empty acknowledgement datagram as soon as
they receive a datagram.  While they could wait and try to piggy-back
it on the next outgoing datagram to that host, they would also have to
set a timer so that an empty ack could be sent out sooner if no
outgoing data is sent soon.  For applications where a large amount of
data is going one way and very little goes the other way (e.g. mail
transfer) this could reduce throughput, because acks would not come as
soon as the receiver was actually ready to receive more.  And if the
acks are sent too late, the sender might end up retransmitting packets
that were actually received intact.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 88 23:59:06 GMT
From:      gordan@maccs.UUCP (gordan)
To:        comp.protocols.tcp-ip
Subject:   Re: Link level Ethernet bridges (Modified)! does that mean joke?


In article <3343@psuvax1.psu.edu> ehrlich@blitz.cs.psu.edu (Dan Ehrlich) writes:
-Once upon a time, in another job far, far, away I also encountered
-these mysterious aa:0:4:0:xx:xx addresses.  Read on.  Maybe someone
-can explain to me why DEC does what it does.  :-)
-
-This mystery number is from a VAX running DECnet, either under VMS or
-Ultrix. [...]  DEC in their infinite wisdom uses one of the maintenance
-functions in the DE[QU]NA to change the physical ethernet address from
-what is in the ROM to this magic number.

I wondered about those funny addresses myself when I found this in one
of my log files some time ago (it appeared to have snuck in as a
multicast packet).  Then those lists of Ethernet packet types were
posted to this group, and 6003 was listed as "DEC/DNA Routing".  Out of
sheer idle curiosity, anybody know what the protocol header fields are
for this packet?


aa 00 04 00 02 04 aa 00 04 00 01 04 60 03 1d 00 	............`...
81 26 00 00 aa 00 04 00 02 04 00 00 aa 00 04 00 	.&..............
01 04 00 00 00 00 04 0a 18 0a 04 5d 86 00 00 00 	...........]....
00 00 00 00 00 00 00 00 00 00 00 00             	............

Ethernet   --  aa  0  4  0  1  4  -->  aa  0  4  0  2  4 
Packet type (hex) : 6003

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 88 00:46:13 GMT
From:      wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.windows.misc
Subject:   Re: rlogin from windows

In article <707@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
:On a heterogenous (System V / Ultrix) TCP/IP network, several people
:use 'rlogin' from windows, and are surprised when the computer on the
:far side believes that they have the full complement of lines and
:columns.  My suggested solution was to add to the third rlogin
 [....]
:Since the System V terminfo uses environment variables $LINES and
:$COLUMNS, we could use those on the System V machines; and we'd have
:to get the Berkeley machines somehow to modify $TERMCAP based on
:$LINES and $COLUMNS.

I run into this problem with my AT&T Datakit network and 5620 window terminal.
Datakit has two separate remote login equivalents, plus "live" remote exec.

For machines with a "real" hardware interface, there's a variable called 
"DKEXPORT", which is a list of the environment variables you want passed
to the remote machine on remote login and remote execution.  So I set
	DKEXPORT="TERM,LINES,COLUMNS,WHATEVER"
and the current value of those variables is set in the remote environment.

For machines that only have RS-232 connections, you get a "cu" equivalent,
with no special support.  When I'm talking to one of them, my .profile
prints an escape sequence that the terminal program responds to with
	LINES=xx; COLUMNS=yy; export LINES COLUMNS 
which is boring but almost always enough, and offeres a csh-variant.

Neither of these programs tells the remote system to set the various
ioctl modes associated with the windowing terminal, but the most
applications look for the environment variables first.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 88 01:35:30 GMT
From:      jerry@oliveb.olivetti.com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <2028@ho95e.ATT.COM> wcs@ho95e.UUCP (46323-Bill.Stewart,2G218,x0705,) writes:
>My big gripe with the r* programs is that they lose UNIX semantics.
>For instance, rsh doesn't return the condition code from the remote process -
>	rsh foovax false
>returns true if the connection succeeded.

This is a real anoyance when writing automated procedures.  I did find a
work around though.  Run something like:
	rsh foovax "command && echo CMDOK" | grep CMDOK
The returned status will now be that of the grep and will reflect the
success of the remote (but not its actual status).  This is good enough
for scripts that need to check command success on remote systems.

>                                           Less important but harder to fix,
>rsh is non-interactive; I've gotten real used to Datakit's remote execution
>capabilities ("dk other3b /bin/ksh").

I don't understand what you mean by non-interactive.  Certainly there is
no tty or terminal type so screen oriented editors and such don't work.
But I frequently run "rsh foovax sh -i" when I need to poke around on
another system.  Certainly that qualifies as interactive, at least as
compared to batch.  Certain programs do cause problems as they buffer
their I/O when run under rsh but enough work for examining or fixing
file modes, ownership, and such.

>					It would also be nice to have a
>convenient rcp-variant that didn't update modification times.

It wasn't all that long ago that "cp" acquired its "-p" option.  In
practical terms I usually find that I want to move multiple files and
preserve more than even "cp -p" does.  I usually run:

	tar cF - files ... | rsh 'cd dir && tar xpF -'

This keeps dates, ownership, directory, and link structure.  And then
there is "rdist".
				Jerry Aguirre

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 88 03:02:06 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TN3270 on Terminal Servers

An open letter to all those involved in the design of TCP/IP terminal
servers...
Is there some logical reason why none of the currently available TCP/IP
terminal servers do not employ a TN3270 mode? I have long thought this
would be a major selling point, now that the IBM 'frame environment is
becoming an ever-present player in the scheme of interoperability. I am
fully aware of the "cpu hog" nature of the 3270 to ASCII conversion but,
let's face it, we've got some pretty capable CPU chips in these boxes.
Am I the only one who sees that the need has yet to be filled(this is
certainly the classic "rhetorical question". I make no claims to fore-
sight but I AM a well-recognized Monday morning quarterback...).
		Have I missed a point somewhere?
	Please address replies and/or comments to me personally and I will
forward appropriate text to the net.
		Thanks in advance,
				  Chris VandenBerg
				  Advanced Computer Communications(ACC)
				  chris@acc-sb-unix.arpa
Disclaimer - Comments are my own and do not reflect the viewpoints of
my employer or (frankly) ANYONE ELSE I know.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 88 18:51:03 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   (none)

From tom@tut.cis.ohio-state.edu Sat Mar  5 09:39:17 1988
Received: by ACC-SB-UNIX.ARPA (5.51/4.7)
	id AA03947; Sat, 5 Mar 88 09:39:12 PST
Received: by tut.cis.ohio-state.edu (5.54/2.0)
	id AA12473; Sat, 5 Mar 88 12:38:51 EST
Date: Sat, 5 Mar 88 12:38:51 EST
From: tom@tut.cis.ohio-state.edu (Tom Easterday)
Message-Id: <8803051738.AA12473@tut.cis.ohio-state.edu>
To: chris@acc-sb-unix.arpa
Subject: 3270 terminal servers
Status: R


Chris,

 Bridge Corporation makes a TCP/IP terminal server called the CS1-SNA which
 does 3270 emulation on various terminal types.  We (Ohio State) have one
 installed, connected to our CICS system.  It works well but has some 
 disconnection problems.  Also, many of its advertised features do not yet
 work although Bridge says the next software release will implement these
 and correct the disconnect problems.  A word of warning (which is solely
 my opinion) Bridge has promised alot but has yet to deliver, also it is
 tough to get much technical help from them (at least in our area).  The
 box is still worth a try and who knows, that software could show up on the
 door step anyday :-) Let me know if you hear of any others as we would
 likely be interested in trying them.  Thanks.

                                               Tom Easterday
                                               The Ohio State University
                                               Instruction & Research Comp Cntr
                                               tom@tut.cis.ohio-state.edu

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 88 23:43:36 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [?])
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Servers

Well, if the terminal is hardwired to a port, you could configure
that port's information to include a terminal type.  Also, the
server could download into itself termcap(-like) information
to support supdup, which would do the appropriate translation.
Terminals?  Everything: hp-26*, vt{52,100,200}, ansi, tvi*, etc.

As for supporting supdup, I'm not sure.  Just about every place
I've worked has installed it (mostly universities).  And the
standard BSD distribution comes with supdup in the /etc/services
file, even if the /etc/inetd.conf doesn't include a server.

My guess is that if it were supported by a terminal server
manufacturer, it would be a real win, and they might get a
leg up on the competition.  But please, oh please, make
scrolling the default.

-Philip

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 88 23:45:23 GMT
From:      philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [?])
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Servers

Sorry, that last one should have been private...

-Philip

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 88 04:50:48 GMT
From:      mb@tulane.tulane.edu (Mark Benard)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   TELNET character mapping problem

I have a LAN with a mixture of vendor products: Sun, Pyramid, and a VAX
running VMS and using EXCELAN's EXOS product.  I am having trouble with
the mapping of two control characters (^C and ^M) from the users
connected across the network from the VAX via Excelan's TELNET.

For the VAX to Pyramid connection, ^M is appearing as ^J.

For the VAX to Sun connection, when running Gnu Emacs, ^C is appearing
as a ^@.  Outside of Emacs, it still generates SIGINT.  ^M is mapped ok.

In both cases I am setting my terminal to be VT100 across the board.

Any ideas on how I can alter the mapping?  And why is it happening?
Is it just slightly different (i.e., incompatible) implementations
of TELNET?
-- 
Mark Benard
Department of Computer Science     INTERNET:   mb@TULANE.EDU
Tulane University                  USENET:     pyramid!tulane!mb
New Orleans, LA 70118              BITNET:     mb%TULANE.EDU@RELAY.CS.NET
				    (or pyramid!tulane!mb at DECWRL.DEC.COM)

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Sun 6 Mar 88 12:55:45-PST
From:      Alan Larson <LARSON@KL.SRI.COM>
To:        karn@ka9q.bellcore.com
Cc:        van@LBL-CSAM.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP rate control?
> To see this, consider the case of 10 simultaneous FTP/TCP transfers
> taking place through a common bottleneck link.  The gateway feeding this
> link has only 5 packet buffers.  Even if the ten TCPs have their
> congestion windows permanently set to 1 packet, there will be room for
> only half of their packets in the buffer queue at any one time...

Phil,

  This seems an important point.  What would people think of a system
where only 50% of the senders will transmit in a time window would be
appropriate?  Who transmits could be determined by having each of the
senders transmit with 50% probability.

  The senders would need to determine the correct probability of send
in any given interval.  This might just be the result of the congestion
window calculation when it is less than one segment.

	Alan
-------
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 88 06:44:18 GMT
From:      karn@KA9Q.BELLCORE.COM (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   TCP rate control?

Van,

It was fun to talk to you in San Diego.  Now I'm sorry I didn't go to
the earlier IETF meetings. 

Many thanks for the patient explanations of your TCP congestion control
techniques; I'm continuing to implement them in my own TCP.  However, I
still think something further may still be required, at least on the
(admittedly pathological) packet radio links I use. 

My reasoning goes as follows.

You never allow the congestion window to decrease below one MSS.  You
argue that letting it go lower would increase header overhead, wasting
link (and network) bandwidth when it can least be spared.  I agree. 
However, this limits your ability to throttle the connection's bandwidth
further should even one MSS-sized packet per connection be too much. 

To see this, consider the case of 10 simultaneous FTP/TCP transfers
taking place through a common bottleneck link.  The gateway feeding this
link has only 5 packet buffers.  Even if the ten TCPs have their
congestion windows permanently set to 1 packet, there will be room for
only half of their packets in the buffer queue at any one time, and
there will be a steady-state 50% packet loss.  True, the link itself
will be efficiently utilized, but the upstream links will be carrying
lots of retransmissions.  Even if these links aren't themselves
congested this seems undesirable. 

Here's another way to look at the problem.  Assume the link bandwidth is
10 packets/second.  Then the maximum queuing delay that can be imposed
on the sending TCPs by the gateway is 5 packets / 10 packets/sec = 1/2
sec.  Since the bandwidth required by any one TCP is the window size (1
packet in this case) divided by the round trip time (1/2 sec -- we'll
assume that the smaller acks encounter negligible delay) each of the ten
TCPs will still attempt to generate two packets per second, for a total
offered load of 20 packets per second.  This is twice the link's
capacity, so half of the generated packets will be dropped. 

So it seems that some sort of rate control timing is necessary.  In
other words, if packets are still being lost even with a 1-packet
window, then the sending TCP should insert increasing amounts of delay
between incoming ACKs and outgoing data packets.  I suppose there are
lots of ways this could be done (I'll probably have the retransmission
timer do double-duty) but as you point out it's important to adjust
the delays so as to produce linear changes in the offered load. 

If I heard correctly, certain gateways on the Internet can only buffer
two packets at a time, so perhaps this scheme would help in places other
than my pathological 1200 baud packet radio channels.

Comments? Rebuttals? (I'd be happy if you proved me wrong so I could
avoid implementing this!)

Phil

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 88 15:07:37 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  campus ethernet help?

One does not Internetwork using bridge links.  Tis a non sequitur.

Phil Wood cpw@lanl.gov
LANL

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 88 20:24:29 GMT
From:      budden@tetra.NOSC.MIL (Ray A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

definition to give a straight answer.

Unless you know what reference model layer, you can't properly
reply.

Similarly, the number of nodes on the net makes an awful lot of difference.

OK, to the ethernet problem.  10 Mbit/sec at the physical layer turns
into about 4 Mbits at the network layer (neglecting trivial cases of
only two nodes on the network).  This decrease is due to the carrier
sense multiple access characteristics of ethernets.

At the transport layer, this tends to decrease further to around 1 Mbit
due to transport overhead.  The figure is plastic depending on whose
TCP you are using.  Unless you've got a lot of overhead in the
higher layers, this 1Mbit figure is pretty much the application-to
application value.

So what does this all mean?  At the network layer, a '4 Mbit' 802.5
token ring gets just as much data thru as a '10 Mbit' ethernet.  Caveat
emptor when the salesman comes to call.  As higher speed networks become
common -- FDDI starts out at 100 Mbit at the physical and network layers,
the Transport layer becomes an even more obvious bottleneck.  Indeed,
it appears that the bottleneck may be shifting from the LAN media toward
the DMA hardware.

Rex Buddenberg

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 88 21:35:26 GMT
From:      kurt@hi.unm.edu (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   EGP networks reachable

I would like to add a network to a MILnet gateway's EGP'er.
Technically, I have everything ready to go.  But, I assume,
some sort of registration is needed.  Hints would be greatly
appreciated.  Thanks

-- 
	Kurt (zeilenga@hc.dspo.gov)

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 09:09:00 PST
From:      "Keith McCloghrie" <kzm@twg.arpa>
To:        "karn" <karn@ka9q.bellcore.com>
Cc:        <van@lbl-csam.arpa>,<tcp-ip@sri-nic.arpa>, <kzm@twg.com>
Subject:   Re: TCP rate control?
Phil,

Your comments to Van state :

> You never allow the congestion window to decrease below one MSS.  You
> argue that letting it go lower would increase header overhead, wasting
> link (and network) bandwidth when it can least be spared.  I agree. 
> However, this limits your ability to throttle the connection's bandwidth
> further should even one MSS-sized packet per connection be too much. 
> 
> To see this, consider the case of 10 simultaneous FTP/TCP transfers
> taking place through a common bottleneck link.  The gateway feeding this
> link has only 5 packet buffers.  Even if the ten TCPs have their
> congestion windows permanently set to 1 packet, there will be room for
> only half of their packets in the buffer queue at any one time, and
> there will be a steady-state 50% packet loss.  True, the link itself
> will be efficiently utilized, but the upstream links will be carrying
> lots of retransmissions.  Even if these links aren't themselves
> congested this seems undesirable. 
 
Your analysis of steady-state 50% packet loss, does not take into
account the retranamission timeout and backoff, ie. each packet
dropped by the net causes the next packet (on the dropped packet's
TCP connection) to be a retransmission which is inserted into the
network at a later time than it would have been if the original
packet had gotten through and been acked.  Also, the returning
acks are themselves subject to be queued/dropped in the gateways.

But, I agree with the conclusion you are drawing : that the network
has a finite amount of buffering (say N packets), and so once there 
are more than N active TCP connections, it is impossible to reach
the steady-state where one packet per connection is buffered in the
net; in this situation the network has only one way to compensate
which is to drop packets; and without a rate-based control, the senders
have no way to reduce their offered load below the one packet per
active connection.

> So it seems that some sort of rate control timing is necessary.  In
> other words, if packets are still being lost even with a 1-packet
> window, then the sending TCP should insert increasing amounts of delay
> between incoming ACKs and outgoing data packets.  

Exactly.

Keith.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Mon, 07 Mar 88 09:50:31 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Kurt Zeilenga <hi!kurt@HC.DSPO.GOV>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: EGP networks reachable

     I would like to add a network to a MILnet gateway's EGP'er.

If you have registered the network with the NIC (hostmaster@sri-nic.arpa) to
acquire a valid net number , and registered the gateway also to acquire a
valid autonomous system number, you are ready.

If you notify 'gateway@bbn.com' when you actually start coming up, we know who
to contact if we see problems, or who to expect a call from if you see them.

Mike Brescia, for 'gateway@bbn.com'
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 88 10:39:46 MST
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        wpl%at6-03@LANL.GOV
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re:  Slow response in rlogin to Brookhaven
I have received a number of complaints about the connection between nets
128.165.32 and 192.12.15.  Does anyone have an inkling as to why the echo
turnaround is over 10 seconds or non existent?
An example complaint:

> "It's always been bad.  I tried it last yesterday.  It's not working at
>  all at the moment.  Is there any trick ... "

Is there an official channel to voice complaints?

Phil Wood  (cpw@lanl.gov)



-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 04:53:26 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, BEAME@MCMASTER.BITNET
Subject:   Re: IEEE 802.3 LAN Considerations vs. 802.5 Token Ring


The early Ethernet design studies claimed you could get at least
9Mbits out of Ethernet.  However you normally don't want to configure
networks so that they are working that way.  THis is true for any
network, whether Ethernet or token.  In order to give people good
response on demand, you want peak capacity to be about a factor of 10
above what you expect typical useage to be.  In fact people are now
getting transfers in excess of 1Mbit over Ethernet.  (I've heard
claims of several Mbits with highly tuned software on fast machines,
but 1Mbit is fairly common these days.)  In order to allow several
things to go on at once, this says you really do want a medium that's
at least 10Mbit.  This is why the whole business about token
delivering predictable response is so wierd.  Even if it is true that
a heavily loaded token system splits bandwidth evenly, nobody in his
right mind would configue a network so that it runs at full capacity
for anything more than a few milliseconds at a time.  (And anecdotal
evidence is that token rings aren't really any more predictable
anyway.)  The main argument for IBM token ring is when you have lots
of IBM equipment and want to do things like have your IBM 3270 cluster
controllers talk over the LAN.  This is quite a reasonable thing to
do.  On one of our campuses we expect to set up a token ring for
administrative use.  However we expect to limit it to that.  It will
handle 3270's and IBM PC's on administrative desks.  For security
reasons, we don't want any student traffic on the same LAN.  So we'll
use Ethernet and related technology for most of the general traffic.
Unless you have this sort of specific need for IBM-related networking,
Ethernet has the advantages of ubiquity and robustness.  That is, you
can get Ethernet support for everything.  Token ring hasn't been a
great success in the market.  According to all the guys in Datamation
it's been about to wipe out Ethernet for the last 5 years now, but
somehow it has never taken off.  Ethernet was also designed to be very
robust.  You can install new taps without disrupting traffic.  People
have violated the specs in all sorts of ways and still gotten it to
work.  It is very conservative technology, and very well understood.
One of the chief designers for a well-known token ring company gave a
talk here a few years ago.  He showed a bunch of performance
statistics and sort of surprised people by saying that as far as he
was concerned at 10Mbits and lower, token ring has only a minor
performance advantage.  Certainly IBM's attempt to convince people
that 4 > 10 is simply absurd.  It would be impossible to do Ethernet
at 100Mbits (cables would be restricted to 50 meters in length), so
all new protocols being designed are token ring.  But that has led
some people to think that somehow token ring is a newer and better
technology.  Not so.  It's that we are beginning to move to faster
technology, and token rings make sense there.  For 10Mb and slower,
the tradeoffs are different, and there are situations where each is
faster.  In general Ethernet is better for a random mix, e.g. terminal
traffic and random FTP's, whereas token ring would be better for
certain kinds of graphics applications or real-time control work.  For
most LAN's I'd say you're going to be better off to stick with
Ethernet unless you have good reason to do otherwise.  The magic
initials IBM do carry some weight.  When they first released the token
ring, I can see why people thought it was bound to succeed.  But IBM
does sometimes fail to dominate an industry. Look at their attempt to
foist PL/I on us all.  Token ring looks like one of these cases.

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 05:13:56 GMT
From:      eric@otc.oz (Eric Dutkiewicz)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Fax number wanted


Does anyone know the Fax Number of Siecor Electro-Optic Products
who are located at Research Triangle Park in North Carolina, USA ?

If so, please reply directly to me by E-mail. Thanks in advance!

			    Eric Dutkiewicz
			    |||| OTC ||

			ACSnet:  eric@otc.oz
			  UUCP:  tuunet,mcvax}!otc.oz!eric
			 Snail:  GPO Box 7000, Sydney 2001, Australia

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Mon,  7 Mar 88 11:55:44 EST
From:      "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
To:        munnari!vuwcomp!nezsupp!rossw@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: tn3270, what and where
TN3270 is a special subset of Telnet, that sends and receives data in
EBCDIC block-mode, with 3270 control sequences embedded.  Non-EBCDIC
machines effectively need a 3270 emulator between the network connection
and the local display.  Greg Minshall did a 'tn3270' for Unix which does
this function.  'tn3270's are also available for DOS PCs, from us and
IBM, and most IBM mainframe TCP/IP implementations come with both a
client and a server.

Note that the recent RFC detailing a "tn3270" standard is *not* the one
that is actually in general use.  The RFC has not yet been implemented
anywhere that I know of (unless someone inside IBM has done so).  I'm
not going to do it until I have a server I can test against...

James VanBokkelen
FTP Software Inc..
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Mon,  7 Mar 88 11:56:34 EST
From:      "James B. VanBokkelen" <JBVB@AI.AI.MIT.EDU>
To:        chris@ACC-SB-UNIX.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TN3270 on Terminal Servers
I assume that memory is a question, too, because the server vendors
really want to do it like Greg Minshall did, with support for many
different asynch terminals, which needs 1) the 3270 emulator, with
one or more screen images worth of buffering, 2) a curses-like module,
with more buffering and code, and 3) a TCP which can handle decent-sized
data transfers efficiently.  Many of them still rely on small windows
to cram N ports into 256K RAM or something like that.

James VanBokkelen
FTP Software Inc.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 88 14:56:34 EST
From:      bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein)
To:        munnari!vuwcomp!nezsupp!rossw@uunet.uu.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   tn3270, what and where

>Hi, people here are just starting to mumble about 3278 type terminals,
>connected to (yeuch) IBM type main(larf larf)frame machines, connected to
>unix boxes over the ethernet.
>Thanks in advance,    Ross Wakelin

You're talking about sitting at a 3278 talking to an IBM mainframe and
then telnet'ing to a Unix (or other full-duplex ASCII system.)

Basically, you can't *really* do it, although I can tell you how...

The problem is that the 3278 is a half-duplex device. When you type in
characters they are not sent to the host until an ENTER or other PF
key is struck, the plain text chars are buffered locally in the
terminal controller. Much of the software on Unix and other hosts
depend on seeing every character as it is typed to perform properly
(although full-screen editors are the most extreme case even simply
deleting a character on a line-oriented command expects this
capability.)

There is TCP software/hardware that supports Telnet available on the
IBM mainframe, for example Wiscnet (the current IBM TCP/IP product)
for VM or ACC's products for MVS.

You can telnet with this to a Unix or similar host. It will be very
similar to logging in from a paper terminal. No full screen (eg.
editors) software will be useable. I would imagine there are people
for whom this is satisfactory (eg. you just want to recompile and run
a program who's input/output is all to disk files.) We all did live
with this sort of environment for years.

The only other way I know of defeating this are black boxes which
splice into your 3278 coax and present an RS232 out the side. There's
a switch (similar to an A/B port selector), in one position you are
using the 3278 as such onto the IBM via the coax, in the other
position the black box uses the 3278's screen/keyboard more or less
directly to emulate a VT100 over the RS232 line which must then be
attached to something else (eg. a terminal server.)

If there are any other solutions (eg. mods on the 3270 controllers) I
too would be curious, time marches on, who knows, someone may have
something new.

	-Barry Shein, Boston University

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 10:14:23 GMT
From:      pdb@sei.cmu.edu (Patrick Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Terminal Servers

In article <8802292140.AA14355@scotty.dccs.upenn.edu> hagan@SCOTTY.DCCS.UPENN.EDU (John Dotts Hagan) writes:
>I would also go on record as saying the Bridge products we evaulated about
>12 months ago were not good at all.  However, a new major release of software
>is out and I have no experience with it.

Note that Bridge's new software release, TCP 20000, needs at least 512K
of memory to run on the CS/100.  I have a few 256K CS/100's, and found
out about this some time after Bridge promised that TCP 20000 would solve
the problems I was having with the older versions, and would include a
domain name resolver to boot.

My sales rep tells me there'll be a TCP 19000 out "soon" that works as
well as TCP 20000, but will run on a 256K CS/100.  Of course, they had
to cut out a few features to make it fit.  Like the domain name resolver,
for instance....

Sigh...Since it would cost Far Too Much to upgrade them to 512K, we're
probably just going to scrap them at this point and buy Annexes.

--Pat.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Mar 88 15:24:40 EST
From:      Mills@UDEL.EDU
To:        ineng-interest@isi.edu
Cc:        tcp-ip@sri-nic.arpa
Subject:   NTP update
Folks,

As a result of several comments received from the true clockwatchers among
us, I have updated the new Network Time Protocol draft document announced
recently. The latest revision includes several editorial changes, several
amendments and clarifications to the protocol specification and an extensive
discussion and comparison of NTP and other proposed time-synchronization
protocols and models, including Unix 4.3bsd timed and other schemes based
on convergence and consistency (agreement) algorithms.

For those brave enough to endure a 127K-octet transfer or foolish enough to
care about such an esoteric (but fun) subject, the document is anonymously
ftpable from louie.udel.edu as the file pub/ntp.doc. I would like to make
this the final resist before the RFC etch.

As always, your comments and suggestions are welcome. As one of the intended
applications of this technology is at gigabit speeds, your comments on the
generic self-organizing, hierarchical master-slave, returnable time (to
put it gloriously, but accurately) architecture would be most interesting.

Dave
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 12:38:52 GMT
From:      peter@nuchat.UUCP (Peter da Silva)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc,comp.windows.misc
Subject:   Re: rlogin from windows

The right thing to do for this one is to have the terminal program send a
NEWSIZE escape sequence to the application when you resize the window.
Something like "\E[%d;%dZ". After the application has sent a newsize-on
sequence to the terminal program, of course. The terminal should probably
send one newsize message immediately upon receiving that message to get
things synched up right in the first place.

Flames always welcome :->.
-- 
-- a clone of Peter (have you hugged your wolf today) da Silva  `-_-'
-- normally  ...!hoptoad!academ!uhnix1!sugar!peter                U
-- Disclaimer: These aren't mere opinions... these are *values*.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 14:50:31 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP networks reachable


     I would like to add a network to a MILnet gateway's EGP'er.

If you have registered the network with the NIC (hostmaster@sri-nic.arpa) to
acquire a valid net number , and registered the gateway also to acquire a
valid autonomous system number, you are ready.

If you notify 'gateway@bbn.com' when you actually start coming up, we know who
to contact if we see problems, or who to expect a call from if you see them.

Mike Brescia, for 'gateway@bbn.com'

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 15:57:41 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Digital DECnet <-> Ethernet address translation

The AA:00:04:xx:xx addresses are indeed DECnet Phase IV addresses.
The low two bytes are the 16-bit DECnet node address, with the low 10
bits node, and the high 6 bits area.  It is inserted in PDP-11/VAX
byte order, so it looks backwards printed Ethernet/big-indian.  (All
of DECnet uses PDP-11 byte order.)

Note that they are setting the locally administered bit in the prefix
(02 in the first byte), so they are not claiming that these addresses
are globally unique.  Presumably they paid their $300 for that block
from Xerox.

Well, from my understanding, the architects did not know that ARP
existed, so that option did not present itself to them.  They chose
this scheme because it was simple.  It is documented in "DECnet DNA
Phase IV Ethernet Data Link Functional Specification", AA-Y298A-TK.

This is not required in DECnet Phase V.  Since it will use ISO CLNS as
a network protocol, it will support big long ISO addresses (12
bytes?).  The little old 6 byte Ethernet address gets wrapped up
somewhere inside these big addresses, so they can use the PROM
address.

Phase V will also eliminate their need for name-to-address translation
tables, by provide a well-designed naming service.  It looks much more
flexible and dynamic than the Internet's Domain Name System.

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 18:41:55 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE 802.3 LAN Considerations vs. 802.5 Token Ring


	Hedrick, as always, makes a clear and concise exposition of
Ethernet versus Token Ring.  I think most users don't have a choice
with network technology, you take what your vendor gives you.  802.5
for Big Blue, 802.3 for DEC and Un*x.
	I see great usefulness for Token Ring bandwidth allocation
schemes, such as proposed in the IEEE MAN work, for allocating
bandwidth and minimizing packet delays for voice traffic versus data.
I'm not really looking to integrate voice/data on the campus, but it
will be indispensible in the MAN standard.  Coupled with the need for
high bandwidth and the preference for fiber (what ever happened to the
promises of the CATV evangelists?), Token Ring (not 802.5) is a clear
technology winner.  This means that TR will trickle down to eventually
supplant Ethernet, although there is no technical reason to do so
until 50Mbps link speeds are required for workstations.  (Can't wait!)

	Kent England
	Boston University

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 20:54:31 GMT
From:      rkh@mtune.ATT.COM (964[jak]-Robert Halloran)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI?

In article <2584@auscso.UUCP> dewey@auscso.UUCP (Dewey Coffman) writes:
>	Does anyone have any information or pointer to information about
>	a new product called TLI out of AT&T(?) that is supposed to
>	replace tcp/ip on UNIX? E-mail is preferable, but post if
>	of general interest.

TLI (Transport Level Interface) is NOT a replacement for TCP/IP.  It
is an program-level interface to the protocol, and is intended as
an alternative to the BSD socket library.  It is implemented for
the AT&T-supported local networks such as TCP/IP, Starlan and Datakit
(insert appropriate trademarkings here) as of System V release 3, with 
a common set of routines for open/close/read/write/etc.  The WIN/3B
package for TCP/IP on the 3Bx machines provides most of the system calls
for SVr2 machines, as well.

Hope this clarifies things.
						Bob Halloran
						Distributed Programming
						  Tools Group
=========================================================================
UUCP: {ATT-ACC, rutgers}!mtune!rkh		DDD: (201)957-6034
Internet:   rkh@mtune.ATT.COM			       
USPS: AT&T DSG, 200 Laurel Ave Rm 3G-314 Middletown NJ 07748
Disclaimer: If you believe I'm speaking for anyone but myself,
		you're sadly mistaken.
Quote: "Good morning, the Russians still beating the pants off us in space?" 
		-- Opus to Oliver, "Bloom County"
=========================================================================

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 21:38:53 GMT
From:      kurt@hi.unm.edu (Kurt Zeilenga)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP networks reachable

In article <23535@hi.unm.edu>, kurt@hi.unm.edu (Kurt Zeilenga) writes:
> I would like to add a network to a MILnet gateway's EGP'er.
> Technically, I have everything ready to go.  But, I assume,
> some sort of registration is needed.  Hints would be greatly
> appreciated.  Thanks

Thanks for all the comments.  I found the problem.  Time.  When
I was playing with the EGP'er I was expecting the core to pick up
on the routes quickly.  After leaving the EGP'er up all night,
everything was working fine in the morning.

Happy netting....

-- 
	Kurt (zeilenga@hc.dspo.gov)

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 88 22:05:12 GMT
From:      andrew@mitisft.Convergent.COM (Andrew Knutsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Convergent Technologies

in article <8803020723.AA11973@ucbvax.Berkeley.EDU>, CF4A8X@IRISHMVS.BITNET ("Mark D. Eggers  239-7258", 219) says:
> 
> We are installing a campus network based on proNET 80,
> tcp/ip, and DECnet. One of the first colleges to connect
> will be the College of Engineering. They have several
> Convergent Technologies 'miniframe' boxes that run System V
> Unix and have tcp/ip. According to the grad student in
> charge of their networks, they have the latest tcp/ip
> software from Convergent Technologies.
> 
> Unfortunately, there are problems.
> 

        Unfortunately, the Miniframe is an obsolete product. It has an
ethernet interface different from the MightyFrame line, so the actual
latest software does not run on it.  The software you have is probably
several years old, and is based on 4.2BSD rather than 4.3, as our Streams
(latest) product is.

        Actually, you shold not be having problems with (non-subnet) route
or ARP. Perhaps you meant routed; true, that isnt supported but should port
easily.  There does seem to be a bug with some kinds of internet addresses,
and subnets were not supported in 4.2.  I dont know about the Ultrix hang;
you might want to try ifconfig'ing -trailers on the Mini...

	If you are interested, I can check into getting you a source
release of just the network part of the Mini kernel, so you can upgrade it.
I'm an engineer though, so no promises.

Andrew Knutsen
Convergent Technologies
(408) 435-3623

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Tue, 08 Mar 88 10:18:33 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "C. Philip Wood" <cpw%sneezy@LANL.GOV>
Cc:        wpl%at6-03@LANL.GOV, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Slow response in rlogin to Brookhaven

     complaints about the connection between nets 128.165.32 and 192.12.15.

You need to start with the people in charge of the gateways on arpanet
(rochester) and milnet (lanl), and trace out the route.  For each gateway,
find out if it is dropping packet, or suffering from long queueing delays.
This will be an interesting exercise in following the pointing fingers.

If you find a direct problem involving the core gateways, call the Network
Operations Center (NOC) at 800-492-4992, and be clear about describing what
sort of gateway problem you suspect.  Most of the people who would answer are
more adept at handling the PSN problems in Arpanet and Milnet.

     Is there an official channel to voice complaints?

I hope you will be voicing observations rather than gripes.  Name (and
address) of gateways and nets will help.

Mike
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 04:48:52 GMT
From:      bakken@hrsw2.UUCP (David E. Bakken)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.sys.ibm.pc.rt
Subject:   SLIP on the IBM RT (w/AIX) or Apollo workstations


Does anyone know of a port of SLIP to the IBM RT (running AIX) or
the Apollo workstations?  If so, please email me with the 
details.  Thanks!!!!

-- 
Dave Bakken   Boeing Commercial Airplanes		(206) 277-2571
uw-beaver!apcisea!tahoma!hrsw2!bakken
Disclaimer: These are my own views, not those of my employers.  Don't
let them deter you from buying the 747 you've been saving hard for.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Mar 88 15:21:54 EST
From:      "Drew M. Powles" <dpowles@ccd.bbn.com>
To:        tcp-ip@sri-nic.arpa
Cc:        dpowles@ccd.bbn.com
Subject:   IP/DDN X.25 implementation survey
I am doing a survey on available TCP/IP implementations over DDN
Standard X.25 and would appreciate any and all information on the
following aspects (the vendor guide form the NIC doesn't go into
sufficient detail):

1) which implementations negotiate precedence for a DDN Standard X.25
call as defined on page 1-481 (volume 1) of the DDN Protocol Handbook
and the mapping of precedence from IP to DDN Standard X.25 as defined
on 1-494 of the same.  Additionally, what mechanisms are provided
allow a user or application process (i.e. FTP, Telnet, etc) to specify
the precedence of a session so that the precednce level is passed down
to the IP layer?

2) which implementations can utilitize DDN X.25 Logical addressing as
specified in pages 1-495 thru 1-498 of the DDN Protocol Handbook -
which includes mapping from IP addresses (either fully implemented or
partially implemented)?

many thanks for your help!

Drew Powles
BBN Communications

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 1988 20:44-PST
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Jon Peha <peha@spam.istc.sri.com>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: remote broadcasts
Jon,

Concerning "remote broadcast" (also known as "directed broadcast"), you
wrote:

	I am quite aware of the dangers of such packets.
	One caused a broadcast storm on our ethernet effectively
	bring down the net.  As far as I know there is no defence
	against one of these packets coming in from the Internet.

Could you explain in more detail what that one broadcast packet contained
that effectively brought down your network, and why the fact that it came
from another network was significant?  I realize that there are lots of
bugs out there in the way hosts handle broadcasts (and multicasts), but
surely it's time to fix the bugs and make our hosts a little more robust
in the face of unwanted packets, rather than imposing arbitrary gateway
controls to protect the hosts from their own stupidity.  As you observed,
multi-destination datagrams can be a valuable tool; rather than imposing
gateway controls, I suggest that the right defence is:

	1) Fix hosts to ignore (i.e., silently discard) packets that
	   they are not equiped to handle properly.

	2) Insist on the use of multicast, rather than broadcast, so
	   that unwanted packets can be ignored efficiently.

Steve Deering
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 14:51:37 GMT
From:      swb@TCGOULD.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   X.400<->RFC822

I know work has been going on for a while on gateways between X.400
mail and RFC822 mail (ISO and DoD IP-based Internet).  Could someone
give me pointers and contacts to find out how the work is progressing,
what is available, and what will be available this year?
					Thanks very much....Scott

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 15:18:33 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Slow response in rlogin to Brookhaven


     complaints about the connection between nets 128.165.32 and 192.12.15.

You need to start with the people in charge of the gateways on arpanet
(rochester) and milnet (lanl), and trace out the route.  For each gateway,
find out if it is dropping packet, or suffering from long queueing delays.
This will be an interesting exercise in following the pointing fingers.

If you find a direct problem involving the core gateways, call the Network
Operations Center (NOC) at 800-492-4992, and be clear about describing what
sort of gateway problem you suspect.  Most of the people who would answer are
more adept at handling the PSN problems in Arpanet and Milnet.

     Is there an official channel to voice complaints?

I hope you will be voicing observations rather than gripes.  Name (and
address) of gateways and nets will help.

Mike

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 15:42:32 GMT
From:      kevin@vger.NBI.COM (Kevin Brooks)
To:        comp.protocols.tcp-ip
Subject:   tcpdump

I'm in the process of looking into either building or purchasing a
tcp-ip network monitor.  The question is does any one know of any 
sources to a public domain monitor?  I know of the pcip package 
but I'm really looking for something to run on a UNIX based system.

I've heard some talk of a package called tcpdump?  What does it do?
Is it public domain?  Any help in this area would be most appreciated.
-- 
Kevin Brooks

	Usenet: ...{pyramid!isieng}uunet|hao!nbires}!vger!kevin

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 19:37:47 GMT
From:      mdm@TRWRB.DSD.TRW.COM (Michael D. Marcinkevicz)
To:        comp.protocols.tcp-ip
Subject:   PRIME TCP/IP OS software

Folks,
	I've a user group that is interested in connecting his two Primes to
our Ethernet backbone.  What can you tell me about TCP/IP options from Prime?

Thanks.

	Michael Marcinkevicz			(213) 812-2154
	TRW Space and Defense Sector, Communications services
	trwrb!mdm@trwind.TRW.COM		(ARPA)
	...{decvax,ihnp4,ucbvax}!trwrb!mdm	(UUCP)

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 19:41:15 GMT
From:      mdm@TRWRB.DSD.TRW.COM (Michael D. Marcinkevicz)
To:        comp.protocols.tcp-ip
Subject:   CDC TCP/IP and CDCnet


Does anyone have an opinion about CDCnet and TCP/IP interface software
support by Control Data Corp..  Here at TRW, we have some CDC Cybers with
CDCnet that could potentially be connected to the rest of the campus
via Ethernet.  What kind of TCP services do you get with the CDC package.

Please answer.

	Michael Marcinkevicz			(213) 812-2154
	TRW Space and Defense Sector, Communications services
	trwrb!mdm@trwind.TRW.COM		(ARPA)
	...{decvax,ihnp4,ucbvax}!trwrb!mdm	(UUCP)

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 20:21:54 GMT
From:      dpowles@CCD.BBN.COM ("Drew M. Powles")
To:        comp.protocols.tcp-ip
Subject:   IP/DDN X.25 implementation survey

I am doing a survey on available TCP/IP implementations over DDN
Standard X.25 and would appreciate any and all information on the
following aspects (the vendor guide form the NIC doesn't go into
sufficient detail):

1) which implementations negotiate precedence for a DDN Standard X.25
call as defined on page 1-481 (volume 1) of the DDN Protocol Handbook
and the mapping of precedence from IP to DDN Standard X.25 as defined
on 1-494 of the same.  Additionally, what mechanisms are provided
allow a user or application process (i.e. FTP, Telnet, etc) to specify
the precedence of a session so that the precednce level is passed down
to the IP layer?

2) which implementations can utilitize DDN X.25 Logical addressing as
specified in pages 1-495 thru 1-498 of the DDN Protocol Handbook -
which includes mapping from IP addresses (either fully implemented or
partially implemented)?

many thanks for your help!

Drew Powles
BBN Communications

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 88 22:00:00 GMT
From:      CASNER@VENERA.ISI.EDU (Stephen Casner)
To:        comp.protocols.tcp-ip
Subject:   Re: Acking out-of-order packets?

Mark Lambert remarked that the Wideband Network would re-order packets
that missed their satellite reservations.  This is true, but such
packets are not "pushed to the end of the queue" as Mark stated.  A new
reservation is sent for the packet as soon as the BSAT determines that
the previous reservation was lost.  In a sense the packet sits at the
head of the queue, but with the high data rate and long delay time of
the satellite channel, several later packets whose reservations were not
lost may be transmitted while the unfortunate packet is waiting for the
repeated reservation to be received.
							-- Steve Casner
-------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 01:02:01 GMT
From:      peha@SPAM.ISTC.SRI.COM (Jon Peha)
To:        comp.protocols.tcp-ip
Subject:   remote broadcasts

Can any one tell me any thing about "remote broadcasts"
in TCP/IP.  By that I mean having a packet broadcast on
a network other than the one to which you are directly
attached.  I am quite aware of the dangers of such packets.
One caused a broadcast storm on our ethernet effectively
bring down the net.  As far as I know there is no defence
against one of these packets coming in from the Internet.
On the other hand, if the packet were a UDP packet that 
did not engender a response (i.e. network monitoring info, 
routing tables, etc.), it could be a valuble tool, which may 
even prove useful in some of my present work.  Is there any 
attempt in the Internet to regulate or block such packets.  
If so, where and how?  If not, has any one considered it?  I would
think that if there is any control over remote broadcasts,
it must take place in the gateway attached to the destination
network, but perhaps the overhead would be too great.

Jon Peha

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 01:49:21 GMT
From:      david@uowcsa.cs.uow.oz (David E A Wilson)
To:        comp.sys.pyramid,comp.protocols.tcp-ip
Subject:   SLIP on a Pyramid


Has anyone managed to configure SLIP to work on a Pyramid (90xe, OSx4.0).
After a bit of hacking into the sun/vax version I have now found that it
uses IFF_ROUTE which has been removed from net/if.h and the bit reused
for IFF_LOOPBACK. Please e-mail me if you have SLIP running on a Pyramid,
explaining what you did to get it going (and what sort of performance
we could expect if it were running ((and how easy it is to interface
the Pyramid supplied higher level packages to it))).

David E.A. Wilson		ACSnet:	david@uowcsa.oz
Dept. of Computing Science	UUCP:	...!munnari!uowcsa.oz!david
Uni. of Wollongong		ARPA:	david%uowcsa.oz@uunet.UU.NET

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 03:21:09 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   CBD - SNIPE



----- Begin Forwarded Message -----

Subject: CBD - SNIPE  3/2/88
Date: Thu, 03 Mar 88 17:18:50 PST

1952549

	   SDI  NETWORK  INTERFACE  PROCESSING  ELEMENT (SNIPE) POC  

Donna   Masi,   Contr  Officer,  315/330-2308  or  Mark  Zonca,  Program  Mgr,
315/330-2805.

Completion:  12 months. Build prototype  pocket-oriented  data  switches  that
interconnect IEEE 802.3 networks via Tl carrier trunk lines using MIL-STD-1777
IP protocol.

These prototypes, called SDI Network Interface Processing  Elements  (SNIPEs),
will  be  evaluated  as the potential design for production units that will be
used to implement SDI net.

This effort will include the hardware and  software  design  as  well  as  the
construction  of  deliverable prototype SNIPEs.  Foreign firms should be aware
that restrictions may be imposed which could preclude their  participation  in
this cont. See Note 11 (however, size standard is changed to 1,000 employees).

Responses  must  reference  Code  B-8-3563-M-2 and include your Commercial and
Govt Entity (CAGE) number.  All responsible firms may submit a proposal  which
shall be considered. (060)
 
SPONSOR: Rome Air Development Center, Griffiss AFB, NY 13441-5700

SUBFILE: PSE  (U.S. GOVERNMENT PROCUREMENTS, SERVICES)

SECTION HEADING: A  Experimental, Developmental, Test and Research Work

PUBLICATION DATE: MARCH 2, 1988        ISSUE: PSA-9538 

----- End Forwarded Message -----

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 04:02:31 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

I've heard a second-hand report that Van Jacobson recently claimed an
8.2Mbit/sec TCP transfer between two Sun 3/50's using a very
aggressively tuned 4.3 BSD TCP.  If I got that right, it's quite
impressive, considering that a 3/50 is by current standards not that
fast a machine.  This suggests

 - that 10 > 4  (i.e. that you can get an Ethernet transfer that
	is faster than the maximum transfer on a 4Mbit token ring)

 - that you don't necessarily have to abandon robust, long-haul
	protocols such as TCP in order to get good performance

I wonder if we could nominate Van for a Nobel prize?  It seems to me
that he deserves something for all the work he has been doing for
TCP/IP.

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 04:44:00 GMT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: remote broadcasts

Jon,

Concerning "remote broadcast" (also known as "directed broadcast"), you
wrote:

	I am quite aware of the dangers of such packets.
	One caused a broadcast storm on our ethernet effectively
	bring down the net.  As far as I know there is no defence
	against one of these packets coming in from the Internet.

Could you explain in more detail what that one broadcast packet contained
that effectively brought down your network, and why the fact that it came
from another network was significant?  I realize that there are lots of
bugs out there in the way hosts handle broadcasts (and multicasts), but
surely it's time to fix the bugs and make our hosts a little more robust
in the face of unwanted packets, rather than imposing arbitrary gateway
controls to protect the hosts from their own stupidity.  As you observed,
multi-destination datagrams can be a valuable tool; rather than imposing
gateway controls, I suggest that the right defence is:

	1) Fix hosts to ignore (i.e., silently discard) packets that
	   they are not equiped to handle properly.

	2) Insist on the use of multicast, rather than broadcast, so
	   that unwanted packets can be ignored efficiently.

Steve Deering

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 06:07:32 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  remote broadcasts

Jon,

I thought it would be cute if the fuzzball implementation exploded
letter bombs to the broadcast address and they do that. Great fun and
a good headscratcher to figure out what happens when you do that
to a bunch of TCPs. However, it sure turned out to be a Real Bad
Idea to allow that to happen past a gateway. Thus, the fuzzballs
carefully nuke any broadcast-apparent packet that attempts to
transit from one net to another. See RFC-1009.

Dave

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 08:00:02 GMT
From:      alan@mn-at1.UUCP (Alan Klietz)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

In article <8803012359.AA00957@acetes.dec.com> mogul@DECWRL.DEC.COM (Jeffrey Mogul) writes:
<The best numbers that I am aware of, for communications between a pair
<of hosts, comes from Dave Boggs.  Using a pair of 15 MIPs processors
<with software of his own design he can get about 7.5 Mbits/sec obeying
<the Ethernet spec, or at least 8.6 Mbits/sec if he "cheats" by sending
<4Kbyte packets. 
<
<The limiting factor in his measurements seems to be that his interface
<can only send one packet at a time; i.e., he must process one interrupt
<per transmitted packet, which takes a few hundred microseconds.  The
<interface can receive up to 16 packets using only one interrupt.  With
<a more elaborate interface design, the theoretical limit should be
<attainable.

In general the maximum channel utilization possible by a single host,

assuming no errors, no contention, an unlimited output queue, and

no copy is,

                       t
                        f
              D = ------------
		   t   +   t
		    f       p

where t  is the time required to wiggle over the wire the bits of an
       f
average length data frame over the wire, and t  is the processing
                                              p
overhead time to interrupt the host CPU, switch context, reset the

interface hardware, allocate buffers, and do other (fixed) overhead.

To push the utilization curve to near 1, you have to either make

your data frames big (increase t , or equivalently process more frames
                                f
per interrupt) or make your processing overhead small (decrease t  ).
                                                                 p

Dave Boggs did both things and got good results.  His processing overhead
is 50us, or a 20,000 packets per second.  Impressive.  (The results for
the 4K case show a 66us overhead, from which we can infer that one of
our original assumptions, such as no data copy, were probably wrong,
but the results are still valid.)

But herein lies the problem.  As machines get faster and bigger, with
more pipelining and vectorization, and as the host network software
becomes bigger and more complicated, the per-message processing overhead
gets more expensive.  And yet the data-links are becoming faster and
faster.   FDDI is 100+ mbit/s.  The GaAs version will be 1000+ mbit/s.
The ANSI X3T9 Working Group is developing a spec for a HSC channel rated
at 1600 mbit/s per second.   The importance of absolutely minimizing
the host overhead is something that I think is critical to get any sort
of decent usage of these links (e.g. buffering multiple messages per host
interrupt). 

The problem is that many vendors still think the "critical path" for
getting better performance is the wire.  (Make the wire go faster and
you get better results), when in actuality the critical path is reverting
back the processor.  Chop off the zeros and its not unlike the olden
days of writing a 9600 baud serial driver for a Intel 8080 processor :-)

--
Alan Klietz
Minnesota Supercomputer Center (*)
1200 Washington Avenue South
Minneapolis, MN  55415    UUCP:  alan@mn-at1.k.mn.org
Ph: +1 612 626 1836       ARPA:  alan@uc.msc.umn.edu  (was umn-rei-uc.arpa)

(*) An affiliate of the University of Minnesota

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Mar 88 17:56:36 EST
From:      Ken Pogran <pogran@ccq.bbn.com>
To:        hedrick@aramis.rutgers.edu
Cc:        hedrick@sccgate.scc.com, oconnor@sccgate.scc.com, tcp-ip@sri-nic.arpa, pogran@ccq.bbn.com
Subject:   Re: maximum Ethernet throughput
Charles,

Getting "maximum throughput" from a LAN has been a challenge
since the inception of Local Area Network technology back in the
'70s.  Often there's a disparity between what the LAN specs
permit (at the "MAC" layer) and what practical controller
implementations are capable of delivering.  The challenge is to
implement a controller that can deliver something approaching the
maximum throughput without being prohibitively expensive (i.e.,
from a vendor's perspective: "Well, we could build one that would
go that fast, but it would price us out of the market.").  So one
sees compromises in what a SINGLE flow can obtain from a LAN.

In ETHERNET implementations, the compromise usually centers on
how fast one can "turn around" a controller following one
transaction (packet sent or received) to begin another one.  On
transmit, this limits how quickly you can send on an unloaded
net.  There are (or at least there were five years ago) some
controller products that did a lot of "housekeeping" between
outgoing packets, lowering throughput (I used one; I was
disappointed.).  On receive, the effect is is much more
pernicious: If your controller takes "a long time" to get ready
to receive the next incoming packet, and the controller sending
to you has a faster turn-around than you do, your controller
might be "blind" to the net and miss a packet, requiring
retransmission by a higher-level protocol.

Applications can't bank on getting a significant fraction of a
LAN; after all, what would happen when two (or ten) of 'em happen
to run simultaneously?  On the other hand, software implemented
in an environment that only contains "slow" controllers might
break in embarrassing ways when employed on systems with quick
turn-around controllers and a lightly loaded net!  Which brings
up a good point for developers of software that run right above
the MAC layer: make sure it'll run on hardware "quicker" than
yours.

>    When designers were thinking of Ethernet, I rather suspect
>    they might not have considered the possibility that one host
>    could actually use all 10Mb of bandwidth.

The mechanisms of the ETHERNET care not a whit whether the next
packet on the line is from the same guy as the last, or from
someone else.  I think it's clear that there were (are?) a number
of CONTROLLER designs that assumed that no individual host would
want to TRY to use all 10 Mb/s.  I haven't looked at the insides
of any recent controllers (or the timing specs of recent controller
chips) but I'd be willing to bet that the choke point is more
likely to be either the controller or its interface to the host,
rather than the specs of the ETHERNET itself.

This all applies to token-ring LANs, too, of course.  And the
faster the aggregate data rate on the LAN, the more these
arguments apply.  (So I might, for example, be able to get a
greater PERCENTAGE of a 4 Mb/s Token Ring than I can of a 10 Mb/s
ETHERNET).

Any comments from designers of LAN controllers?

Ken Pogran
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 14:44:53 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

I also have heard "unofficial" reports of TCP transfers at greater than 8Mbps
between a couple of SOS boxes by Van Jacobson.  Stories of crashing Vaxen
accompany the reports.  At least one reporter claimed that this helped to
demonstrate that Sun violates the Ethernet spec, allowing packets to be put
on the wire too close together, effectively denying access to other hosts.

Any chance of an "official" confirmation or denial of these rumors?  Possibly
an IDEA or RFC?  Which leads to another question, what ever happened to IENs?

				Mike

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 15:59:09 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: remote broadcasts

There is no guarantee that any particular (sub)net that you're
sending to supports broadcasting.  This topic is discussed
in RFC1009, mostly in appendix A.  Briefly, the local gateway
may forward a "directed broadcast datagram", but not through
the interface that it came in.  A local gateway is permitted
to black hole a directed broadcast.  Presumably, there should
be a software switch.

It may be useful to remember that intermediate gateways may
not be able to determine if a particular IP address is a broadcast
address unless they know the local subnet mask.  Thus disgarding
directed broadcasts is always done by the gateway guarding the
destination net.

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 18:07:07 GMT
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

We know of no evidence that Suns violate the minimum spacing
requirement.  Indeed if they did, things that work for us would fail,
so I don't believe it.  However 8Mb transfers would certainly open us
to a whole range of things that have never been tested before.  While
Ethernet should in theory tolerate multiple simultaenous high-speed
users, as far as I know it isn't being used that way now.  Proper
functioning would depend upon everybody's random backoff working
right.  Given the past history in networking, I am not prepared to bet
that untested features work.  One could imagine failures everywhere
from Ethernet controller microcode to device drivers to protocols
implementation.  It would also let us test whether protocol designs
implicitly assume that an Ethernet can never be congested.  Certainly
DECnet deals very differently with Ethernet than with point to point
lines, and to a certainly extent IP does as well.  When designers were
thinking of Ethernet, I rather suspect they might not have considered
the possibility that one host could actually use all 10Mb of
bandwidth.  It is possible that protocols such as ARP and DECnet hello
would have to be rethought in this context.  (For the benefit of the
person asking the original question, let me note that there's no reason
to think that a token ring would help.  Indeed it is slower, so one
is in danger of reaching this unknown realm sooner.)

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 18:23:47 GMT
From:      pgc@newcastle.ac.uk (P. G. Cutting)
To:        comp.protocols.tcp-ip
Subject:   bridge/router summary request?



I would be most grateful if someone could send me a summary of the bridge vs router debate that took place in this newsgroup recently. 

 



thanks in advance.



our address is



CSSD@UK.AC.NEWCASTLE



CSSD,

Computing Laboratory,

The University of Newcastle,

Newcastle Upon Tyne,

NE1 7RU,

ENGLAND.

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 18:45:46 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   ethernet monitor needed?

We have a single modest ethernet with a fair assortment of equipment
spread around the building.  So far, network mangagment has been on
a plug-it-in-and-see-if-it-works-good basis.  I'd like to be able to
so some monitoring with the following goals:

1) define ethernet loading and identify transceiver/interface level
   malfunctions.

2) investigate problems with systems that won't talk to each other or
   interfere with other conversations.

3) support development/debugging of in-house ethernet related hardware
   software projects.

I've seen an ad for an Excelan 5100/5300 unit that seems to fit the
bill, but they want maybe $5K for it, which seems pretty expensive for
the amount of use it would get.  I'd appreciate any comments about
this unit, good, bad or something else is better.

Also, is there any software, either 4.3 BSD or Sun related that could
be used to support this monitoring funciton, instead of going with a
piece of specialized equipment?

-- 
George Robbins - now working for,	uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 22:46:20 GMT
From:      doug@wbcs.UUCP (Doug Kratky)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   ARP hardware field


What does a 2 value in the hardware field of ARP (ar_hrd)
represent? Does anyone have a list of the different values
that are valid for the hardware field and the types of
hardware they correspond to?

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 88 22:56:36 GMT
From:      pogran@CCQ.BBN.COM (Ken Pogran)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

Charles,

Getting "maximum throughput" from a LAN has been a challenge
since the inception of Local Area Network technology back in the
'70s.  Often there's a disparity between what the LAN specs
permit (at the "MAC" layer) and what practical controller
implementations are capable of delivering.  The challenge is to
implement a controller that can deliver something approaching the
maximum throughput without being prohibitively expensive (i.e.,
from a vendor's perspective: "Well, we could build one that would
go that fast, but it would price us out of the market.").  So one
sees compromises in what a SINGLE flow can obtain from a LAN.

In ETHERNET implementations, the compromise usually centers on
how fast one can "turn around" a controller following one
transaction (packet sent or received) to begin another one.  On
transmit, this limits how quickly you can send on an unloaded
net.  There are (or at least there were five years ago) some
controller products that did a lot of "housekeeping" between
outgoing packets, lowering throughput (I used one; I was
disappointed.).  On receive, the effect is is much more
pernicious: If your controller takes "a long time" to get ready
to receive the next incoming packet, and the controller sending
to you has a faster turn-around than you do, your controller
might be "blind" to the net and miss a packet, requiring
retransmission by a higher-level protocol.

Applications can't bank on getting a significant fraction of a
LAN; after all, what would happen when two (or ten) of 'em happen
to run simultaneously?  On the other hand, software implemented
in an environment that only contains "slow" controllers might
break in embarrassing ways when employed on systems with quick
turn-around controllers and a lightly loaded net!  Which brings
up a good point for developers of software that run right above
the MAC layer: make sure it'll run on hardware "quicker" than
yours.

>    When designers were thinking of Ethernet, I rather suspect
>    they might not have considered the possibility that one host
>    could actually use all 10Mb of bandwidth.

The mechanisms of the ETHERNET care not a whit whether the next
packet on the line is from the same guy as the last, or from
someone else.  I think it's clear that there were (are?) a number
of CONTROLLER designs that assumed that no individual host would
want to TRY to use all 10 Mb/s.  I haven't looked at the insides
of any recent controllers (or the timing specs of recent controller
chips) but I'd be willing to bet that the choke point is more
likely to be either the controller or its interface to the host,
rather than the specs of the ETHERNET itself.

This all applies to token-ring LANs, too, of course.  And the
faster the aggregate data rate on the LAN, the more these
arguments apply.  (So I might, for example, be able to get a
greater PERCENTAGE of a 4 Mb/s Token Ring than I can of a 10 Mb/s
ETHERNET).

Any comments from designers of LAN controllers?

Ken Pogran

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 88 08:32 CST
From:      RYAN POPKEN <POPKEN@crcvms.unl.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   CDC TCP/IP and CDCnet
CDCnet currently includes a subset of the TCP/IP suite of prorocols.
They consist of ICMP and TELNET for both their NOS and NOS/VE systems.
FTP is also available for the NOS/VE system.  In their Spring Release of
CDCnet, they have added FTP for NOS and ARP for both systems.  We currently
have both TELNETs and FTP for NOS/VE running on our systems.  TELNET we use
fairly regularly, and it appears to work quite well.  FTP we tested out when
it was first installed and it worked at that time.  I do not know how stable
it is over regular use.

Ryan Popken
Cyber System Manager
University of Nebraska
Lincoln, Nebraska
<POPKEN@UNLVAX1.BITNET>
<RYAN@UNLCDC3.BITNET>

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 02:55:48 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: remote broadcasts

In article <88.03.08.2044.910@pescadero.stanford.edu> deering@PESCADERO.STANFORD.EDU (Steve Deering) writes:
>Could you explain in more detail what that one broadcast packet contained
>that effectively brought down your network, and why the fact that it came
>from another network was significant?  

I don't know what the original poster's answer will be, but my answer
to this is that one generally has some control over the systems on the
local net.  If they start abusing broadcasts we can remove the
programs that are causing trouble.  But if broadcasts can come from
anywhere there's not much that you can do to prevent them, and instead
you must defend against them.  While it is a good idea for systems to
be resilient, it's also harder to implement.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 03:45:47 GMT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

I don't know what would constitute an "official" confirmation
but maybe I can put some rumors to bed.  We have done a TCP that
gets 8Mbps between Sun 3/50s (the lowest we've seen is 7Mbps,
the highest 9Mbps -- when using 100% of the wire bandwidth, the
ethernet exponential backoff makes throughput very sensitive to the
competing traffic distribution.)  The throughput limit seemed to
be the Lance chip on the Sun -- the CPU was showing 10-15% idle
time.  I don't believe the idle time number (I want to really
measure the idle time with a uprocessor analyzer) but the
interactive response on the machines was pretty good even while
they were shoving 1MB/s at each other so I know there was some
CPU left over.

Yes, I did crash most of our VMS vaxen while running throughput
tests and no, this has nothing to do with Sun violating
protocols -- the problem was that the DECNET designers failed to
use common sense.  I fired off a 1GB transfer to see if it would
really finish in 20 minutes (it took 18 minutes) and halfway
through I noticed that our VMS 780 was rebooting.  When I later
looked at the crash dump I found that it had run out of non-paged
pool because the DEUNA queue was full of packets.  It seems that
whoever did the protocols used a *linear* backoff on the
retransmit timer.  With 20 DECNET routers trying to babble the
state of the universe every couple of minutes, and my Suns
keeping the wire warm in the interim, any attempt to access the
ether was going to put a host into serious exponential backoff.
Under these circumstances, a linear transport timer just doesn't
cut it.  So I found 25 retransmissions in the outbound queue for
every active DECNET connection.  I know as little about VMS as
possible so I didn't investigate why the machine had crashed
rather than terminating the connections gracefully.  I should
also note that NFS on our other Sun workstations wasn't all that
happy about waiting for the wire:  As I walked around the building,
every Sun screen was filled with "server not responding" messages.
(But no Sun crashed -- I later shut most of them down to keep ND
traffic off the wire while I was looking for the upper bound on
xfer rate.)

I did run two simultaneous 100MB transfers between 4 3/50s and
verified that they were gracious about sharing the wire.  The
total throughput was 7Mbps split roughly 60/40.  The tcpdump
trace of the two conversations has some holes in it (tcpdump
can't quite hack a packet/millisecond, steady state) but the
trace doesn't show anything weird happening.

Quite a bit of the speedup comes from an algorithm that we (`we'
refers to collaborator Mike Karels and myself) are calling
"header prediction".  The idea is that if you're in the middle
of a bulk data transfer and have just seen a packet, you know
what the next packet is going to look like:  It will look just
like the current packet with either the sequence number or ack
number updated (depending on whether you're the sender or
receiver).  Combining this with the "Use hints" epigram from
Butler Lampson's classic "Epigrams for System Designers", you
start to think of the tcp state (rcv.nxt, snd.una, etc.) as
"hints" about what the next packet should look like.

If you arrange those "hints" so they match the layout of a tcp
packet header, it takes a single 14-byte compare to see if your
prediction is correct (3 longword compares to pick up the send &
ack sequence numbers, header length, flags and window, plus a
short compare on the length).  If the prediction is correct,
there's a single test on the length to see if you're the sender
or receiver followed by the appropriate processing.  E.g., if
the length is non-zero (you're the receiver), checksum and
append the data to the socket buffer then wake any process
that's sleeping on the buffer.  Update rcv.nxt by the length of
this packet (this updates your "prediction" of the next packet).
Check if you can handle another packet the same size as the
current one.  If not, set one of the unused flag bits in your
header prediction to guarantee that the prediction will fail on
the next packet and force you to go through full protocol
processing.  Otherwise, you're done with this packet.  So, the
*total* tcp protocol processing, exclusive of checksumming, is
on the order of 6 compares and an add.  The checksumming goes
at whatever the memory bandwidth is so, as long as the effective
memory bandwidth at least 4 times the ethernet bandwidth, the
cpu isn't a bottleneck.  (Let me make that clearer: we got 8Mbps
with checksumming on).

You can apply the same idea to outgoing tcp packets and most
everywhere else in the protocol stack.  I.e., if you're going
fast, it's real likely this packet comes from the same place
the last packet came from so 1-behind caches of pcb's and arp
entries are a big win if you're right and a negligible loss if
you're wrong.

In addition to the header prediction, I put some horrible kluges
in the mbuf handling to get the allocation/deallocations down to
1 per packet.  Mike Karels has been working in the same area and
his clean code is faster than my kluges.  As soon as this
semester is over, I plan to merge Mike's and my versions then
the two of us will probably make a pass at knocking off the
biggest of the rough edges.  Sometime in late spring or early
summer we should be passing this code out to hardy souls for
beta-testing (but ask yourself: do you really want workstations
that routinely use 100% of the ethernet bandwidth?  I'm pretty
sure we don't and we're not running this tcp on any of our
workstations.)

Some of the impetus for this work came from Greg Chesson's
statement at the Phoenix USENIX that `the way TCP and IP are
designed, it's impossible to make them go fast'.  On hearing
this, I lept to my feet to protest but decided that saying "I
think you're wrong" wasn't going to change anybody's mind about
anything.  Now I can say that I'm pretty sure he was wrong about
TCP (but that's *not* a comment on the excellent work he's doing
and has done on the XTP and the Protocol Engine).

The header prediction algorithm evolved during attempts to make
my 2400-baud SLIP dial-up send 4 bytes when I typed a character
rather than 44.  After staring at packet streams for a while, it
was pretty obvious that the receiver could predict everything
about the next packet on a TCP data stream except for the data
bytes.  Thus all the sender had to ship in the usual case was
one bit that said "yes, your prediction is right" plus the data.
I mention this because funding agents looking for high speed,
next-generation networks may forget that research to make slow
things go fast sometimes makes fast things go faster.

 - Van

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 04:44:38 GMT
From:      hedrick@ARAMIS.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

I thought it was obvious that I was talking about systems designers,
not the people who made up the Ethernet specs.  As I said, when we get
into untests realms, such as 8Mb single transfers, we run the danger
of finding bugs in the controller, its microcode, device drivers, and
possibly even (though we will hope not) the protocols defining the
Ethernet encapsulation for IP, DECnet, or whatever.  We see very
clearly the fact that many controllers can't handle bursts of packets
with minimum spacing.  Normally however they simply drop packets, not
crash the machine they are running on.  I have no idea why DECnet
machines would crash during bursts of TCP traffic (or even whether
that rumor is true), but I would start looking at the design of the
Ethernet controller and the device driver that is dealing with it.  It
could be something as simple as a bug in the code that handles
situations where you are unable to get the Ethernet for an extended
period of time, or something as complex as implicit assumptions in
some piece of the DECnet protocol design.  Of course it could also be
a bug in the Sun that causes it to fail to defer to someone else when
it is supposed to do so, but I sort of doubt that, since that should
be handled by the Lance chip.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Mar 88 09:46:52 EST
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: PRIME TCP/IP OS software
The local Prime salesman tells me that they support tcp/ip and ethernet as
of last October. Telnet is curently inbound only, ftp is both ways, and smtp
is not at all. The missing pieces are claimed to be under development.

                                          Bob Dixon
                                          Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 06:56:11 GMT
From:      dannyb@kulcs.uucp (Danny Backx)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
>
>I am looking for PD version of code that accomplishes the same thing
>as rsh but conforms to the RFC's (machine name case independent).
>We have users who like to pipe BIG jobs from one machine to another
>machine via rsh's.  
>
>The reason I am interested in something other than rsh is because
>here at UNM we are strongly considering disallowing the r* programs
>(rsh/rcp/rlogin) because they do NOT conform to the RFC's as well
>as being BIG security problems (.rhosts).

You might want to look at the "rex" service in SUN's RPC package.
This is something quite similar to rexec(3) and rsh(1).
What I mean is : it also doesn't provide a virtual terminal for your remote
processes.

If you have access to SUN manuals, look at on(1c), rexd(8c), and rex(3r).
If not, you could get the idea by looking in the RPCSRC 3.9 package,
which was recently posted to the net (comp.sources.???).
It is also accessible via anonymous ftp and via Email from the archives of
Sun-Spots.

If you need better authentication than BSD's r*, I think this may do :
the rex-system uses the same "UNIX-style authentication" that the entire RPC
package uses.
If you have a SUN or a 4.3 system from Mt.Xinu, you should be able to use it
right away.

	Danny Backx

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Katholieke Universiteit Leuven 
 Tel: +32 16 200656 x 3537              |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@kulcs.BITNET            |        Belgium     

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 14:32:00 GMT
From:      POPKEN@crcvms.unl.EDU (RYAN POPKEN)
To:        comp.protocols.tcp-ip
Subject:   CDC TCP/IP and CDCnet

CDCnet currently includes a subset of the TCP/IP suite of prorocols.
They consist of ICMP and TELNET for both their NOS and NOS/VE systems.
FTP is also available for the NOS/VE system.  In their Spring Release of
CDCnet, they have added FTP for NOS and ARP for both systems.  We currently
have both TELNETs and FTP for NOS/VE running on our systems.  TELNET we use
fairly regularly, and it appears to work quite well.  FTP we tested out when
it was first installed and it worked at that time.  I do not know how stable
it is over regular use.

Ryan Popken
Cyber System Manager
University of Nebraska
Lincoln, Nebraska
<POPKEN@UNLVAX1.BITNET>
<RYAN@UNLCDC3.BITNET>

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 14:46:52 GMT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re: PRIME TCP/IP OS software

The local Prime salesman tells me that they support tcp/ip and ethernet as
of last October. Telnet is curently inbound only, ftp is both ways, and smtp
is not at all. The missing pieces are claimed to be under development.

                                          Bob Dixon
                                          Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 88 19:51:19 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: ARP hardware field

In article <117@wbcs.UUCP> doug@wbcs.UUCP (Doug Kratky) writes:
>What does a 2 value in the hardware field of ARP (ar_hrd)
>represent? Does anyone have a list of the different values
>that are valid for the hardware field and the types of
>hardware they correspond to?

Check the most recent version of the Assigned Numbers RFC (1010, I think).
And the winner is...3Mb/sec ethernet...
-- 
			- john romkey
		...harvard!spdcc!kaos!romkey
		       romkey@kaos.uucp
		    romkey@xx.lcs.mit.edu

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 00:06:45 GMT
From:      sob@bcm.tmc.edu (Stan Barber)
To:        comp.protocols.tcp-ip
Subject:   Bridge Communications TCP/IP 20000

There has been some discussion about terminal servers and the Bridge 
Communications products. Most of it has been "hear-say". I thought I'd 
take this opportunity to make some concrete comments based on our
use of two versions of their software accross three products.

We run a large network that uses CS/1s, CS/100s and CS/200s. We had been
running XNS on the terminal servers until the end of last year when we 
converted the TCP (version 13000). This version of TCP/IP was functional,
but no more than that. It was slow and it seemed that many useful TELNET
functions were not implemented. However, it worked well enough for the
month we had to wait for TCP 20000. [We were intending to convert to
20000 directly, but Bridge was delayed in getting it to us.] One useful
feature was the addition of permanent virtual circuits. This made remote
printers easy to do.

The new version was MUCH better than the older version. Flow control
was much more responsive (flow stops within a couple of bytes). TELNET's
binary option was now available (useful for some types of file transfers and
graphics). Throughput was MUCH improved.

Additionally, a rich macro language has been added as well as support for
the Domain Name Service.

Until recently, I was only marginally satisfied with the Bridge product. Now,
I am quite pleased with it. My only major remaining complaint is the lack
of support for a non-proprietary system logging function. I have suggested
that they make their log information available to the unix syslog function.
I hope they will.

Stan Barber, Baylor College of Medicine



Stan           internet: sob@tmc.edu          Baylor College of Medicine
Olan           uucp: {rice,killer,hoptoad}!academ!sob
Barber         Opinions expressed are only mine.

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 00:53:14 GMT
From:      wesommer@athena.mit.edu (William E. Sommerfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <102@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes:
>If you need better authentication than BSD's r*, I think this may do :
>the rex-system uses the same "UNIX-style authentication" that the entire RPC
>package uses.

Have you actually looked at what `UNIX style authentication' is for
Sun RPC?

The client puts its hostname, userid and group set in the packet; the
server is expected to take the client's word for it, and usually does.

Calling Sun's rex, with UNIX style authentication, ``more secure than
rlogin'' is like calling a Medeco padlock on a paper bag more secure
than a Master padlock on a cardboard box.

Sun may have a `secured RPC' version of `rex' in release 4.0 which
would be more secure than rlogin/rsh, although not quite as secure as
a modified rsh using Kerberos (the MIT/Athena authentication system).

					Bill Sommerfeld
					MIT Project Athena.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 01:26:41 GMT
From:      kak@stc-auts.UUCP (Kris Kugel)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   using TCP/IP for news and mail

I'd like to get uucp to use our ethernet connection
to "Building 2" but I don't know how.
In investigating this, I managed to get "sendmail"
to connect from our local sun to our vax running ultrix
(a slightly downlevel ultrix, probably 2.0),
but not the other direction.

1. How do I make the ultrix sendmail aware of my sun?
   (it always responds, "User unknown")
2. How can I alter uucp to take advantage of the ethernet?
	(will eventually be talking to a BSD 4.3 machine)

We're running a BSD4.2 mail system on the ultrix vax,
but I'm missing the 4.2 documentation. 

Any help would be welcome!

	Thanks in advance,
	Kris A. Kugel
	Storage Tek:    ...{ uunet!nbires, hao, ihnp4 }!stcvax!stc-auts!kak
	"It is better to light one small cannibal than to torch the duchess"

P.S. please respond by e-mail.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 03:06:59 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   maximum Ethernet throughput


Breathtaking, in a word, who made that comment about Nobel Prizes
for networking?

At any rate, there is another interesting issue here:

>(but ask yourself: do you really want workstations
>that routinely use 100% of the ethernet bandwidth?  I'm pretty
>sure we don't and we're not running this tcp on any of our
>workstations.)

My temptation is to ask the converse: Do I wish to believe that merely
mediocre algorithms protect me from this as a problem?

It seems that given what we might call near-capacity algorithms (for
ethernets, of course new wire technologies such as direct fiber
hookups will be interesting again) we need to think about rational
ways to administer such networks.

In the trivial case we could isolate many of these workstations, as we
already do here, to their own ethernets, barely shared, so it is less
of a problem. Perhaps this would spur vendors to provide hardware to
make that even easier and more economical. This would certainly be
useful in the case of networked file systems using a client/server
model (eg. diskless or disk-poor clients.)

Beyond that I have often thought of the idea of a network "throttle",
a settable parameter that might control maximum throughput (packets
output per second, for example) that a machine might limit itself to.

Obviously that requires voluntary compliance (although it could be an
extension of window advertising, that is, making the window behavior
tunable by the system administrator rather than calculated for maximum
throughput always based upon blind assumptions about resources.)

Interesting, at any rate...

	-Barry Shein, Boston University

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 04:39:50 GMT
From:      mike@BRL.ARPA (Mike Muuss)
To:        comp.protocols.tcp-ip
Subject:   Re:  expo ftp bug?

Greg -

Good work on the detailed sleuthing.  Phil here at BRL experienced the
same problems when using 3 different TCPs here, which definitely
points the finger at the TCP on poor <expo>.

I'm the original proponent of the tcp_mss code, and moving it to 1024
will actually cause you significantly more trouble than the 512 setting,
as it will case the packets to be fragmented as they enter the IMP-based
networks (ARPANET, MILNET).  If you are trying to squeeze a few more
data bytes per packet from the network, be certain that this
relationship holds:

	tcp_mss <= Network_MTU - Max_Header_Size

In the case of IMPs, the MTU is 1006.  The max header (TCP+IP) isn't
huge, perhaps 42 bytes :-).  Therefore, your tcp_mss should not exceed
964 bytes.  If you want to be really conservative, a number like
920 or 930 would allow lots of room for IP Options (which are rare,
but not unheard of).  Even at 920 that would give you a 1.8x performance
advantage.  HOWEVER, note that no system is REQUIRED to accept a
packet with more than 512 data bytes, so by implementing this change
you may reduce your interoperability.  No UNIX system is likely to mind,
but some non-UNIX systems (esp. some MULTICS machines) are unhappy with
larger MSS settings.

If you induce IP fragmentation through the core network system, you
will do very much worse than with the current setting.  The problem is
that if one fragment of a multi-fragment IP datagram is dropped, then
the whole transmission (all fragments) are not useful, and have to be
re-sent.  If each TCP transmission fits in a single IP datagram, then
TCP has the opportunity to be more sensible with it's retransmission
strategy.

At BRL, we run SUNOS 3.4, with the "Van" TCP code replacing the Sun
code. I believe he offers the fixes in both source and Sun-binary-patch
form. It's a real winner, consult the archives of the <TCP-IP> list for
details.

	Best,
	 -Mike

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 06:21:49 GMT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

In article <8803091444.AA24112@sccgate.scc.com> oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) writes:
>...  At least one reporter claimed that this helped to
>demonstrate that Sun violates the Ethernet spec, allowing packets to be put
>on the wire too close together, effectively denying access to other hosts.

We hear these stories at Sun all the time, usually from customers who
have been told by other computer vendors that the Sun somehow "cheats"
on the Ethernet spec by "putting too many packets on the wire", or
"sending too many packets too fast for Ethernet". These are complete
falsehoods. Sun uses standard chips supplied by both Intel and AMD for
our ethernet interfaces, and while they may be the fastest
implementations available on the market, they are completely within
Ethernet specifications. Next time you hear one of these stories from
a sales person for another computer vendor, ask them to back their
claim with facts, and seriously consider the source.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 16:54:05 GMT
From:      rajaei@ttds.UUCP (Hassan Rajaei)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput

In article <412@mn-at1.UUCP> alan@mn-at1.UUCP (0000-Alan Klietz) writes:
>But herein lies the problem.  As machines get faster and bigger, with
>more pipelining and vectorization, and as the host network software
>becomes bigger and more complicated, the per-message processing overhead
>gets more expensive.  And yet the data-links are becoming faster and
>faster.   FDDI is 100+ mbit/s.  The GaAs version will be 1000+ mbit/s.
>The ANSI X3T9 Working Group is developing a spec for a HSC channel rated
>at 1600 mbit/s per second.   The importance of absolutely minimizing
>the host overhead is something that I think is critical to get any sort
>of decent usage of these links (e.g. buffering multiple messages per host
>interrupt). 
>
You are right. We are reaching a point that a host machine no longer can
cope with the communication problems alone. We have to offload the host as
much as we can by introducing dedicated communications system rather than
some simple board. The protocol engines are something to think about.

Hassan Rajaei
rajaei@ttds.tds.kth.se

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 19:25:29 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   maximum Ethernet throughput

One way to deal with those violent controller speed mismatches that
are starting to show up is to use a LAN with some form of hardware
ACK.  This is part of all token ring networks (ProNET, Apollo, 802.5,
FDDI), as well as Hyperchannel and DEC's CI.  While these bits cannot
be used to guaruntee end-to-end reliability, they do let you know when
you are sending faster than the other guy can receive.

The simplest thing to do is just retransmit until the other guy copies
it, but this is a waste of network bandwith.  The more sophisticated
thing to do is put the packet back on the front of the output queue,
and search up the queue for a packet to a different hardware
destination.  This way the packet retransmissions are interleaved with
potentially useful transmissions.  You don't, however, want to shuufle
the order of packets to a particular node, this can be pathological to
some protocols.  (The NSP in DECnet-VAX did not accept out-of-order
packets until Version 4.7, some TCP's have the same problem.)

Good programming interfaces are indeed important.  While our earlier
boards were only single-buffered (one each way), their simple and fast
programming interface (start a transmit in 4 C statements) made up for
it.  (The ACK bit also helps on the single-buffer problem.)

It is very hard to try and get below the interrupt-per-packet
threshold and keep a simple programming interface.  However, even if
you make it, you run into programming interfaces, such as the 4.3bsd
network device interface, that make it very difficult to get a
pipeline going.  By comparison, in VAX/VMS, where pipelining is quite
feasible, when you pipeline two packets deep, you nearly double the
throughput.

As an example of how programming interfaces and interface design
affect performance, note that Van's benchmarks were run on a Sun-3/50,
which uses the AMD LANCE Ethernet chipset.  I doubt he could match
those numbers on a Sun-3/160, which uses a Intel 82586 Ethernet chip.
The '586 has an inferior programming interface, and some nasty
internal "housekeeping" delays that make it a good bit slower.

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 88 22:22:21 GMT
From:      sean@cadre.dsl.PITTSBURGH.EDU (Sean McLinden)
To:        comp.protocols.tcp-ip
Subject:   LAN Terminal server (TELNET and SUPDUP)

Is anyone aware of an Ethernet terminal server which supports both
TELNET and SUPDUP?

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Mar 1988 06:33:46.82 EST
From:      <droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Re: Another example of the joys of BITNET mail

> %%% Issue 17 was sliced in half by some unkind IBM systems using SMTP. Glenn
> %%% Vanderburg informs me that the reason was a line that was longer than
> %%% 80 columns got wrapped, ...

If the moderator would only submit tex-hax on a deck of punch cards, (rather
than these new-fangled "disk files"), BITNET would be perfectly happy.

Oh, and make sure you refrain from using those "tab" characters, whatever
*they* are...

- Ralph Droms
  Bucknell University
  (coming to you live from bknlvms.*bitnet*)

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 03:16:19 GMT
From:      dougm@violet.ico.isc.COM ("Doug McCallum")
To:        comp.protocols.tcp-ip
Subject:   Re(2): maximum Ethernet throughput

In reply to your message of Thu, 10 Mar 88 22:21:49 PST
-------
> falsehoods. Sun uses standard chips supplied by both Intel and AMD for
> our ethernet interfaces, and while they may be the fastest
> implementations available on the market, they are completely within
> Ethernet specifications. Next time you hear one of these stories from

Just having controllers made with standard chips does not ensure that they
are within specification.  I don't remember the details of the LANCE chip,
but the Intel 82586 can be configured to violate just about every parameter
you might think of.  The interpacket spacing is one such parameter.  The
parameterization makes it useful for implementing different speed networks
(like Starlan) with the same chips.

So, even though Sun's products are made with standard parts doesn't
guarantee that someone hasn't changed parameters to something non-standard.

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 05:08:13 GMT
From:      A.Eric@GSB-WHY.STANFORD.EDU (Eric M. Berg)
To:        comp.protocols.tcp-ip
Subject:   Another example of the joys of BITNET mail

[Extracted from a recent digest posted to the TeXhax mailing list...]


Date: 21 Feb 88
From: Malcolm
Subject: Immoderate notes: brief pause in texhax; issue 17 sliced up

%%% Issue 17 was sliced in half by some unkind IBM systems using SMTP. Glenn
%%% Vanderburg informs me that the reason was a line that was longer than
%%% 80 columns got wrapped, which resulted in the next line beginning with
%%% a period.  SMTP though that this meant it was about to get a command. So
%%% it went through the remainder of the digest, looking for a command, which
%%% of course it didn't find -- only more TeXhax.  

-------

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 09:02:11 GMT
From:      amdcad!charlie@ucbvax.Berkeley.EDU  (Charlie Slater)
To:        tcp-ip@sri-nic.arpa
Subject:   AT&T ISN as a Method of Connecting Ethernets
This is a report on AT&T's Information Systems Network (ISN).

Correcting to points on which I was confused:

1. ISN does not transfer voice
2. ISN controllers do statistically multiplex data traffic over 
   long lines to other controllers such as 56Kb or T1 lines.
3. ISN does support BSC, SDLC, 3270.  AT&T brochures include 
   long list of IBM terminals and controllers with which ISN is 
	 said to be compatible.
4. It does support asynchronous ASCII terminals at speeds up
   to 19.2 Kbps.

Routing:

ISN provides sophisticated routing for all of its digital
services except the Ethernet bridge.  Like Vitalink's, AT&T's
bridge mixes (internal) network address resolution with routing.
Because the "learning" algorithm used for network address
resolution cannot handle polygon topologies (e.g. a triangle of
three sites), all polygons are broken by taking one line in the
polygon out of service (e.g. a triangle is converted to a
dog-leg).  There is no reason a "disconnected" polygon (e.g. a
dog-leg) cannot be used for network address resolution and a
closed polygon used for transferring data over the shortest path
once addressing has been resolved.  Like Vitalink, AT&T just did
not bother. If you understand this, you can skip the next four
paragraphs.

All learning bridges work by building tables of Ethernet
addresses and internal network address which help the bridge
decide which network to send it to.  These addresses can be very
simple such as "local," "line1," and "line2."

When the bridge sees a new Ethernet source address it adds it to
its list of local addresses and informs the other bridges that
the new address is on its local network. The remote bridges have
add to their list of addresses associated with the bridge which
just saw the packet. Thus bridges learn which packets go to which
bridge.

The problem occurs when a bridge sees a packet with a destination
address that is not in its table.   The bridges must send this
packet to all Ethernets.  The bridge sends the packet to all
connected bridges. One bridge sends it to the next, and so on.
If bridges are connected via a closed polygon, the packet stays
"in flight" forever.

Almost all packets on the Ethernet, however, have destination
addresses already in the bridge's table.  The bridges should
route packets with known destination networks over the shortest
path, and packets for which the network is unknown over an
administratively defined path which does not close the polygon.
Such an algorithm is not hard to implement.  The problem is that
most bridge vendors are insensitive to the customer's desire to
send data over one hop consuming one long line, rather than two
or more hops consuming two or more long lines.

											       

Having separated routing from automatic network address
resolution, there is no reason why bridge vendors cannot develop
more sophisticated routing algorithms than those of IP routers.
Among the metrics that should be included in the objective
function are: line speed, line quality, and line utilization.

Line Utilization:

Because the bridge knows nothing of the network and connection
level protocols, it must forward the entire Ethernet packet
(except for preamble)  This means there is an extra 18 bytes of
overhead in addition to the protocol overhead.  One respondent
from AT&T said that ISN eliminated part of this overhead by
mapping the Ethernet source and destination addresses to shorter
addresses.

Assuming that all 18 bytes of Ethernet overhead are sent, then
the overhead on a TCP/IP connection is increased from 40 bytes to
58 bytes.  This means that the maximum line utilization for an
ftp file transfer which uses packets containing 512 bytes of user
data decreases from 93 per cent to 90 per cent.

The difference is even more pronounced for telnet connections. If
one is sending a single character via a router, the packet is 41
bytes long.  However, the minimum Ethernet packet length is 46
bytes.  With Ethernet's 14-byte heading and some form of CRC 
(unlikely to be less than Ethernet's 4 bytes) a bridge must send 
64 bytes to send a single character on a virtual terminal 
connection.

Converting from a router to a bridge devotes an at least an
additional 3 per cent of total traffic to overhead.  This cost
may well be offset by the efficiencies which acrue from ISN's
statistical multiplexing of 3270 traffic with inter Ethernet
traffic.

As an aside, the DEC router server moves DECnet traffic more
slowly over a 56Kb line than the Vitalink bridge.  This
well-known phenomena is contrary to what I just said about
routers achieving better line utilization to Bridges.  The DEC
router server is simply too slow to drive a 56Kb line.  A Bridge
GS/3 IP router uses 4-year old hardware to achieve the
theoretical maximum of 93 per cent line utilization for an ftp
file transfers. Routers really do drive 56Kb lines faster than
bridges.

Will ISN work for large networks?

As a rule, bridges do well on networks with small numbers of
stations and less well on networks with large numbers of
stations. There are two reasons for this:

1. A bridge must read every packet.  If a T1 bridge connects two
Ethernets, each with only one station attached, it may achieve a
station-to-station file transfer speed in excess of one megabit
per second.  However, if one of the Ethernets has, say, 300
stations and an average load of, say, five megabits per second,
the bridge's throughput may drop to, say, 200 Kb per second. This
is because most of the bridge's CPU cycles are consumed sifting
through five packets for every one it forwards.
											
2. Both DECnet and what people call TCP/IP (but is really the
Address Resolution Protocol or ARP which goes with TCP/IP),
use Ethernet broadcast packets to resolve logical addresses
to Ethernet addresses (and in the case of diskless workstations,
vice versa).  With no knowledge of the next level protocol, it
is difficult for the bridge to know which broadcast packets to
forward.  The choice is usually none or all.  If the bridge 
does not forward broadcast packets, neither DECnet nor TCP/IP 
will work.  On the otherhand, If the bridge forwards all 
broadcast traffic then some of the long line to the next bridge
will be wasted on broadcast packets which should have stayed
on the local Ethernet.  While local broadcast traffic small with 
respect to the 10-megabit capacity of Ethernet it may be large
with respect to the capacity of a 56Kb line.  

Summary:  

AT&T's Bridge is far from state of the art.  It is slower and
less efficient than multiple protocol routers available from
Wellfleet Communications or cisco Systems.  

ISN's ability to move SDLC, BSC, and Async on the same line can
be matched by using products from Bridge Communications which
convert these protocols to TCP/IP.  

However, ISN is an improvement over previous products from AT&T.
The advantages of having a single vendor take end-to-end 
responsibility for all corporate communications may well 
justify the cost of still being one generation behind.  

Thanks to all who responded to my original inquiry and helped in
the preparation of this article.  I take full blame for any 
mistakes in this article.  The opinions expressed are my own
and do not necessarilly reflect those of AT&T or AMD.

charlie slater
charlie@amdcad.amd.com
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 12:18:45 GMT
From:      droms@BKNLVMS.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: Another example of the joys of BITNET mail



> %%% Issue 17 was sliced in half by some unkind IBM systems using SMTP. Glenn
> %%% Vanderburg informs me that the reason was a line that was longer than
> %%% 80 columns got wrapped, ...

If the moderator would only submit tex-hax on a deck of punch cards, (rather
than these new-fangled "disk files"), BITNET would be perfectly happy.

Oh, and make sure you refrain from using those "tab" characters, whatever
*they* are...

- Ralph Droms
  Bucknell University
  (coming to you live from bknlvms.*bitnet*)

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 20:45:02 GMT
From:      csg@pyramid.pyramid.com (Carl S. Gutekunst)
To:        comp.sys.pyramid,comp.protocols.tcp-ip
Subject:   Re: SLIP on a Pyramid

In article <274@uowcsa.cs.uow.oz> david@uowcsa.cs.uow.oz (David E A Wilson) writes:
>Has anyone managed to configure SLIP to work on a Pyramid (90xe, OSx4.0).

Sure. It will be a supported product in OSx 4.4, now in beta test. Harrass
your salescritter if you want to be a beta test site.

I suspect that the problem you had porting the Sun/VAX version to OSx 4.0 is
that OSx 4.0 is 4.3BSD; it sounds like you had the 4.2BSD version of SLIP.

Performance has been pretty good; we had to make some minor modifications to
get dropped packets on the source side to work properly. (Otherwise we occa-
sionally got long TCP timeout delays.) rlogin over a 19.2K SLIP line is not
visibly different from rlogin over Ethernet. Of course, when you get several
people doing cat /etc/termcap at the same time, it gets a bit sluggish. :-)
We've also just started running SLIP on the Telebit TrailBlazer between here
and Ames; interactive really stinks (1 to 4 second echo delays), but that's
because the TrailBlazer is half duplex.  File transfer is better. We'll be
compiling (and posting) specific numbers as the project moves along.

<csg>

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 21:41:52 GMT
From:      avolio@decuac.dec.com (Frederick M. Avolio)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   using TCP/IP for news and mail

The sendmail problem sounds like you need to putz around with your sendmail.cf.
There is no problem tlaking to/from any system via SMTP, but the sendmail.cf
needs to be a proper sendmail.cf (one that knows about an SMTP mailer, for
example).

It sounds like you don't really want UUCP over TCP/IP (which is doable)
but you want to transfer news.  A better way is to use NNTP which works
very nicely.  An added feature is that it implements the ihave/sendme
protocol so only those articles which must be sent are sent.  (It does
it in real time as opposed to how one can do this over real uucp dialup
links which works but requires multiple phone calls, etc.)

Fred

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 88 22:46:18 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, chris@ACC-SB-UNIX.ARPA
Subject:   Re: TN3270 on Terminal Servers


I know at least one vendor who claims to be working on tn3270 mode.  I
think I can tell you why it hasn't been done yet.  First, it needs
more memory and CPU than a normal telnet connection.  You have to
maintain a screen image and various other state information, and you
have to do the emulation.  Most terminal servers currently use a 68000
with not much memory.  But that's not the big problem.  The big
problem is that you need to have access to somthing like termcap for
the user's terminal.  Terminal servers don't have disks, and they
don't have enough memory to store the whole thing in memory.  My
theory is that they're going to have to define a "termcap server" that
runs on a host and gives you the termcap entry for a single requested
terminal type.  Of course those machines that support tftp booting
(which I think is common) could always download /etc/termcap and just
throw away everything except the one entry that they needed.
Presumably when the vendors do it, they'll use it to help sell us
upgrades that use the SPARC chip and have 32MB of memory...  (Well,
not really, but I think you might need more than 1MB, and at least
a 68020.)

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 1988 09:12-EST
From:      CERF@A.ISI.EDU
To:        jif@VENERA.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   NRI New Address

Forgive the broadside - it seemed most efficient to do it this
way. NRI has moved its location to:

Corporation for National Research Initiatives
1895 Preston White Dr., Suite 100
Reston, VA 22091

(703) 620-8990

The telephone number is the same. The old Post Office Box is
still valid, but mail sent to our physical location will reach
us faster.

Vint Cerf and Bob Kahn
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 88 12:28:59 GMT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Ultrix

In article <1535@uhccux.UUCP>, torben@dorsai.ics.hawaii.edu (Prof. Torben N. Nielsen) writes:
> In article <8802060858.AA08978@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes:
>> We have a uVAX running Ultrix that I would "like" to have SLIP on.

I have a pseudo interface driver that is known to work on MicroVAX-IIs
running Ultrix 1.2 and 2.0.  This can function as a SLIP driver, in
conjunction with a user-level program.  I can send details if anyone is
interested.

> I took a look at an Ultrix system at one time and kind of came to the
> conclusion that trying to do it yourself to a binary Ultrix
> distribution was no fun.

Trying to do anything to a binary distribution is no fun.  I hold the
view that if you don't have source, you shouldn't even consider using
it.

However it is possible to drop a new network interface driver into a
binary distribution.  I can send you the distribution package for my
IP-over-DECnet stuff, which contains the pseudo interface driver and
directions for installing it even on a binary distribution.

I started to write the user program I mentioned above, but I don't
recall whether I finished it or not.  If anyone cares, I can check and
possibly finish it.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 88 14:12:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   NRI New Address


Forgive the broadside - it seemed most efficient to do it this
way. NRI has moved its location to:

Corporation for National Research Initiatives
1895 Preston White Dr., Suite 100
Reston, VA 22091

(703) 620-8990

The telephone number is the same. The old Post Office Box is
still valid, but mail sent to our physical location will reach
us faster.

Vint Cerf and Bob Kahn

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 02:44:00 GMT
From:      brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: remote broadcasts

Steve, Jon, list,

	Jon wrote that a directed broadcast "caused a broadcast storm
on our ethernet effectively bring down the net." In the 18 months that
I've had a largish part of SRINET to watch, storms have come and gone
due to local broadcast address mismatches, and broken cable. I have on
occasion seen directed broadcasts, which didn't do as Jon describes -
trigger a broadcast storm.
	...I've just spoken to Jon, it appears that the directed broadcasts
I saw here (SRI) from UCSC some many moons ago, were mentioned to him
by our hardware facility manager as the/a cause of one-or-more of our
network failures in the winter. This is wrong, so I'll make the informational
corrections locally. Unless anyone has anything else to add, the "directed
causes network meltdowns" discussion is at its end.

Eric

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon 14 Mar 88 09:26:37-EST
From:      Stephen M. King <KING@AFSC-HQ.ARPA>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   WHOIS for VMS Vax...
Does anyone know where I can get a copy of WHOIS which will run on a VMS
based Vax?

We have a VaxCluster (780s, 785, 8700, 8650) running VMS and Wollongong
Shared-Deuna products.  Source/binary is preferred... but binary only will
still be appreciated.  Need ASAP... thanks in advance.

Steve
-------
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 11:23:44 GMT
From:      dannyb@kulcs.uucp (Danny Backx)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <3647@bloom-beacon.MIT.EDU> wesommer@athena.mit.edu (William E. Sommerfeld) writes:
>In article <102@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes:
>>If you need better authentication than BSD's r*, I think this may do :
>>the rex-system uses the same "UNIX-style authentication" that the entire RPC
>>package uses.
>
>Have you actually looked at what `UNIX style authentication' is for
>Sun RPC?
>
>The client puts its hostname, userid and group set in the packet; the
>server is expected to take the client's word for it, and usually does.

I know the original system from Sun is far from secure.
You can make it MUCH better, though.

You can always check :
	1) does the client have a port nr. < 1023
		If not, throw this request away

	2) is the host the client is sending from one of a selected set of
		'trusted' machines.
		If not, throw this request away

I can think of two possible ways to break into this :
	1) put a machine on the net who believes he is somebody else

	This can be detected by the other machines, though, especially the one
	that the fraud pretends to be.

	2) the user trying to break in already broke the protection on the
	   machine he is sending from.

	I don't think defense against this is possible.

I'm sure Kerberos is better... I only wanted to state that rex could be used.

	Danny Backx

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Katholieke Universiteit Leuven 
 Tel: +32 16 200656 x 3537              |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@kulcs.BITNET            |        Belgium     

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 13:43:15 GMT
From:      isns01@ms3.UUCP (Jim Chappell)
To:        comp.protocols.tcp-ip
Subject:   IMP interface design

I'm teaching myself how this sucker works because when its broke
no one in BBN or DCA that I contact can help, and I'm left in the
dark like those mushrooms in a PA farm.

Can anyone interpret the following netstat -h output?

IMP Host Table
Flags Host            Qcnt Q Address RFNM Timer
A     ardec.arpa      8    8090a780  8    127
A     isec-oa.arpa    8    80908f80  8    125
A     nosc-tecr.arpa  0    0         4    0
A     ria-1.arpa      8    80906e00  8    72
A     usadhq2.arpa    8    80907d80  8    126
A     optimis-pent.ar 8    80908500  8    128
A     brl.arpa        8    8090ab80  8    127
A     26.0.0.104      8    8090b980  8    127
A     sri-nic         6    8090e180  8    0

Thanks,
-- 
Jim Chappell               UUCP: ...!umd5!vrdxhq!ms3!jrc 
ISN Corp.  (703) 979-8900  ARPA: jrc@hios-pent
1235A Jeff Davis Hwy, Suite 220
Arlington, Va 22202

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 14:26:37 GMT
From:      KING@AFSC-HQ.ARPA (Stephen M. King)
To:        comp.protocols.tcp-ip
Subject:   WHOIS for VMS Vax...

Does anyone know where I can get a copy of WHOIS which will run on a VMS
based Vax?

We have a VaxCluster (780s, 785, 8700, 8650) running VMS and Wollongong
Shared-Deuna products.  Source/binary is preferred... but binary only will
still be appreciated.  Need ASAP... thanks in advance.

Steve
-------

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 15:08:22 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Re(2): maximum Ethernet throughput

I quick look with adb at SunOS 3.4 reveals that Sun is initializing
the Intel 82586 Ethernet chip per Ethernet specifications for
interfame spacing.  The instruction:

_iedefaultconf+0x5a:	movb	#0x60,a5@(0xb)

is moving an interfame spacing of 96 bits (9.6 microseconds) to the
interfame spacing (offset 0xb) field in the Configure command block
for the 82586.  Confirm this for yourself on your Sun.

They are not cheating.  There are simply Ethernet boards that crash
trying to do address compares at full speed, and there are host
implementations (DECnet-VAX) that assume that the Ethernet interface
will always send packets than they can generate them.  These
implementations have Ethernet-related bugs--the Sun does not.  The Sun
proves to be a good tool for finding these bugs.

Enough said?

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 15:59:26 GMT
From:      thompson@dalcs.UUCP (Michael A. Thompson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: ARP hardware field

In article <117@wbcs.UUCP> doug@wbcs.UUCP (Doug Kratky) writes:
>What does a 2 value in the hardware field of ARP (ar_hrd)
>represent? Does anyone have a list of the different values
>that are valid for the hardware field and the types of
>hardware they correspond to?
	The following is extracted from rfc1010:
                 ADDRESS RESOLUTION PROTOCOL PARAMETERS
 
   The Address Resolution Protocol (ARP) specified in RFC 826 [64] has
   several parameters.  The assigned values for these parameters are
   listed here.
 
   Assignments:
 
      Operation Code (op)
 
         1   REQUEST
         2   REPLY
 
      Hardware Type (hrd)
 
         Type   Description                                   References
         ----   -----------                                   ----------
           1    Ethernet (10Mb)                                    [JBP]
           2    Experimental Ethernet (3Mb)                        [JBP]
           3    Amateur Radio AX.25                                [PXK]
           4    Proteon ProNET Token Ring                          [JBP]
           5    Chaos                                              [GXP]
           6    IEEE 802 Networks                                  [JBP]
           7    ARCNET                                             [JBP]
 
      Protocol Type (pro)
 
         Use the same codes as listed in the section called "Ethernet
         Numbers of Interest" (all hardware types use this code set for
         the protocol type).

-- 
Michael A. Thompson, Dept. Math, Stats, & C.S., Dalhousie U., Halifax, N.S.
thompson@dalcs.uucp	From Bitnet or Uucp
thompson@cs.dal.cdn	From Bitnet or Cdn
thompson%dalcs.uucp@uunet.uu.net From Arpa

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 17:28:20 GMT
From:      boesch@VAX.DARPA.MIL
To:        comp.protocols.tcp-ip
Subject:   Rumors about the death of the ARPANET


There have been a number of rumors about the impending death of the
ARPANET.  Here is the current DARPA position.

Brian Boesch

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


	DEATH OF THE ARPANET AND OTHER PARANOIA

There have been a number of rumors throughout the community that the
ARPANET project is being terminated. Many individuals and
organizations have expressed concern that the service that they have
become accustomed to will be terminated.

Enough rumors, now a word from your sponsor, DARPA.

The ARPANET project in fact is being terminated, but not soon.  DARPA 
is in the business of conducting research into critical NEW technologies 
that will advance the state of the art.  ARPANET is neither new, 
nor state of the art.  It is slow and  expensive.

ARPANET was founded in the early 70's when 56Kbit/second trunks were
on the cutting edge of modulation and transmission technology. Packet
switching was unheard of.  (An interesting fact is that the average
terminal of the day was 30cps giving the net trunks about a factor of
230 faster than the average user interface). Since that time the
project expanded into the INTERNET where a number of dissimilar
networks could be interconnected relatively transparently.  The
internet grew from about 63 hosts to over 20,000. The local nets that
connect to the ARPANET and other Wide Area Nets (WANs) progressively
increased in speed.  The result is that while in '73 a large number of
users could effectively share one trunk, today, one user on a PC can
overload the entire capacity of the ARPANET.

In addition to being overloaded, the ARPANET is no longer able to
support its other prime function, that of a research base.  To conduct
any kind of experiment on the ARPANET causes too much service
disruption to the community.

Finally, the ARPANET is absorbing a significant fraction of our total
research budget in what is really a support function.

Solution, eliminate the source of the problem.  Rather than cutting
off the community our approach is to outgrow the ARPANET in a few
years.

The follow on network experiment will be called the Defense Research
Internet (DRI). We are also working in conjunction with other Federal
agencies, most notably National Science Foundation, to integrate our
networking experiments with the new regional networks, the NSFNET 
project, and other agency networks.

An additional source of confusion is the fact that we are currently
arranging for NSFNET to support some ARPANET users, as part of a joint 
effort to reduce costs by phasing out overlapping service.  Our
intention, as always, is to do this with minimal disruption to the
reserach community.

While this happening, we will be putting together the initial version
of the DRI apart from the ARPANET.  From the beginning the DRI will provide
the long distance trunk capacity that the ARPANET lacks. Initial
speeds will be 1.5Mbit/second per link (a factor of 25 improvement).
The DRI will also be segregated into an "experimental" and an
"operational" side.  The experimental side will have higher performance,
with the possibility of higher degree of net problems; the operational
side will support high data-rate applications such as image transfer.
The experimental side will be phased from 1.5Mbit to higher and higher
bandwidths with the intent of eventually reaching gigabit/second
performance; the operational side will take over for the ARPANET.
It will be operated by a contractor, and will be funded as overhead on
individual users' projects rather than becoming a drain on the Networking
research budget.  After the DRI is stable, the ARPANET will be phased out.  


PLEASE DON'T BURY US WITH QUERIES ON THE DETAILS OF THE
IMPLEMENTATION, WE DON'T HAVE TIME TO ANSWER THEM.  AS DETAILS ARE 
FINALIZED AND READY FOR PUBLIC DISSEMINATION, WE WILL POST THEM.


Mark Pullen & Brian Boesch
- -------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 18:30:45 GMT
From:      mohsen@retix.retix.COM (Mohsen Banan)
To:        comp.protocols.tcp-ip
Subject:   Re: X.400<->RFC822

In article <8803081451.AA24107@tcgould.TN.CORNELL.EDU> swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) writes:
>I know work has been going on for a while on gateways between X.400
>mail and RFC822 mail (ISO and DoD IP-based Internet).  Could someone
>give me pointers and contacts to find out how the work is progressing,
>what is available, and what will be available this year?
>					Thanks very much....Scott

RFC987 (Mapping between X.400 and RFC822) is the title of the document that
you want. (S. E. Kille, University College London, June 1986.)
It was posted to the net in Nov. 1987.

I am also interested in X.400 <---> RFC822 mapping work that people are doing.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 20:36:29 GMT
From:      haas@gr.utah.edu  (Walt Haas)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: AT&T ISN as a Method of Connecting Ethernets
In article <20778@amdcad.AMD.COM>, charlie@amdcad.AMD.COM (Charlie Slater) writes:

[stuff deleted]
> ISN provides sophisticated routing for all of its digital
> services except the Ethernet bridge.  Like Vitalink's, AT&T's
                                             ^^^^^^^^^
> bridge mixes (internal) network address resolution with routing.
[stuff deleted]
> There is no reason a "disconnected" polygon (e.g. a
> dog-leg) cannot be used for network address resolution and a
> closed polygon used for transferring data over the shortest path
> once addressing has been resolved.  Like Vitalink, AT&T just did
                                           ^^^^^^^^
> not bother. If you understand this, you can skip the next four
> paragraphs.
[stuff deleted]

Vitalink's new software release does exactly what you suggest.
Furthermore the Vitalink software now interoperates with DEC
LANbridges to form a unified spanning tree for routing.  Call
Mike Coker at Vitalink and ask him to explain it to you.

Cheers  -- Walt Haas    haas@cs.utah.edu    utah-cs!haas
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 20:49:00 GMT
From:      WANCHO@SIMTEL20.ARPA ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Whither MILNET?

(There is a possible pun in the Subject line...)

I'm jealous.  Can I get my host rehomed/dual-homed to ARPANET/DRI?
I'll bet our traffic is the cause of a major portion of the mailbridge
congestion (if that helps the cause to be moved)...

It's time for the MILNET management to speak up and tell us what's in
store for the production side of this INTERNET... and when...

--Frank

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 88 23:58:22 GMT
From:      brad@cayman.COM (Brad Parker)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   who posted the delni summary? (enet in a can)

A few years ago (was it that long?) some kind soul posted a very elaborate
explanation / expose about "ethernet in a can" a.k.a. delni boxes.

It contained a nice list of features/problems/issues which I would like
to read. Could someone send it to me or tell me where's it archived
or ftp'able (or whatever).

Something tells me it was someone from NASA/Ames (home of the P-3's) or
a cad company or AMD? Truth is I don't remember. Help!

Thanks in advance.
-brad

ps: could someone send me mail if this gets out; I'm not sure posting
is working here.
-- 

Brad Parker
Cayman Systems		"You are sleeping; you don't want to believe..."
brad@Cayman.com			   - from a (yet another) Smith's tune

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Mar 88 10:20:29 CST
From:      hrp%windsor.CRAY.COM@uc.msc.umn.edu (Hal Peterson)
To:        tcp-ip@sri-nic.arpa
Subject:   offloading the protocols
An interesting point came up in the recent discussion prompted by Van
Jacobson's improvements on TCP capacity:  since network capacity is
increasing drastically, it is becoming ever more important to put
protocol handling where it won't interfere with a host's real work;
that is, on an outboard processor.  But Dave Clark has said that in
practice these outboard processors don't save much, because of the
necessary complexity of the interface between the OP and the CPU.  If
this is true (and I'm sure we can find someone to debate against it),
then the next generation of protocols should be designed with OPs
specifically in mind.  But what does that mean?  What does a protocol
suite need to look like so it has a clean point of cleavage between
the duties of the central and the outboard processor?

--
Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN  55120
hrp%hall.CRAY.COM@umn-rei-uc.ARPA	ihnp4!cray!hrp	    (612) 681-3145
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 88 07:11:55 GMT
From:      romkey@kaos.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <1188@kulcs.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes:
>I know the original system from Sun is far from secure.
>You can make it MUCH better, though.
>
>You can always check :
>	1) does the client have a port nr. < 1023
>		If not, throw this request away

"Trusted ports" (when port numbers less than 1024 can only be used by
a trusted user) exist only in the world of the Berkeley UNIX TCP.
Virtually no TCP/IP implementations that are not derived from BSD
UNIX have the concept of "trusted ports"; they will allow any user
program to open a connection on any port that isn't already in use.

Some of the non-BSD TCP's also support rsh; I know of at least one.
Rsh is a simple enough protocol that you can bring it up pretty
easily on non-UNIX systems. It's useful enough that it's desireable
to do so.

Trusted ports are a phenomenally bad idea in a heterogeneous
environment where you really want security. Even in a homogenous
environment of all BSD systems, if some are being used as personal
workstations chances are that their users can easily boot them in
single user mode and run programs as root.

They shouldn't be depended upon to do anything other than provide
security holes.
-- 
			- john romkey
		...harvard!spdcc!kaos!romkey
		       romkey@kaos.uucp
		    romkey@xx.lcs.mit.edu

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 88 08:58:00 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Keep-alives, also push bit

In BSD at least, keepalives are implemented by sending a TCP segment
containing a single byte of "garbage". However, the SEQ field is one
less than the receiver is expecting, so it is not accepted as real data.

When the receiver sees an "old" data packet (i.e., a packet containing
data that has already been acked, i.e., the sequence number in the
header plus the length of its data is less than the receiver's RCV.NXT)
it is required by the spec to send a segment with its next expected
sequence number, i.e., RCV.NXT, in the ACK field.  (This is primarily
intended to prevent deadlock in normal data transfer should an
acknowledgment packet be lost.) The "polling" TCP uses this "do-nothing
ACK" as the indication that the remote host is still there. So hosts
that don't respond properly to BSD-style keepalives are most likely not
following the spec.

Having said this, I should point out that keepalives are NOT a formal
part of the TCP spec. I also think they're a very bad idea.  I didn't
always feel this way. However, some long and frustrating experiences
with slow, unreliable and often expensive network paths (amateur packet
radio, as well as commercial X.25 networks that charge for every packet)
have turned me into a crusader against keepalive pinging.  It simply
isn't worth the cost, especially when there's no way for me to tell the
other end to cease and desist.

Besides, the whole philosophy of TCP and the datagram approach to
networking was supposed to be reliability and robustness in the face of
network problems. Why should the system gratuitously close a connection
just because the network path happens to go down for a few minutes? If
the connection has been idle during the entire outage, the user wouldn't
even know (or care) that there had been a problem, as long as it's back
by the time he sends more data. But keepalive pinging will make SURE he
knows in the most annoying way possible!

In the same category are TCPs that immediately close a connection when they
get an ICMP Unreachable message. At most they should abort connections
only before they are established; once established they should serve as
diagnostic messages only.

Phil

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 88 16:05:15 GMT
From:      ftp!nancy@bloom-beacon.mit.edu  (Nancy Connor)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: ARP hardware field
Michael Thompson writes:

      Protocol Type (pro)
 
         Use the same codes as listed in the section called "Ethernet
         Numbers of Interest" (all hardware types use this code set for
         the protocol type).

I don't believe that this is true.  I know that Proteon uses a
different set of codes from the Ethernet list I sent out a while ago.

	-Nancy Connor
	FTP Software
	... !harvard!spdcc!ftp!nancy
	nancy@ftp.com
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 88 18:52:37 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   IP options crash our Sun gateway

When our stock SMI DDN gateway attempted to forward IP-grams containing RR or
LSRR options, it would crash.  Our box is a 3/260 running SOS 3.5 and acts as
a gateway between our local ethernet-based network and the ARPANET.  We have
only been able to test this behavior on outgoing packets, but if we are correct
in our diagnosis, the problem should occur when the box attempts to forward any
IP-option bearing packets in either direction.

According to the engineer assigned to our service request, Sun has assigned the
problem bug number 1008944 but will not supply a fix for 3.n SOS.  He stated
that the problem should be fixed in 4.0 SOS which will be distributed later in
1988.

Based on a report from Allison Mankin of MITRE, that the crashing is caused by
a previously reported typo in ip_stripoption(), I have patched our binary in an
attempt to reverse the effects of the typo.  The patch has been working now for
a little over 2 weeks.  Working in the sense that our machine no longer crashes
when forwarding IPgrams which contain options.  I have yet to verify what is
going out the other interface.

If anyone else is affected by this, and the legal boys allow it, I am willing
to supply the binary patch.  It only consists of modifying a register value
in 2 consecutive instructions.

			Mike

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 88 19:05:02 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP on IBM (was Re: BITNET)

Perhaps Kludge was too harsh a word.  I haven't seen one of these yet although
we will probably end up with one.  It uses an Industrial IBM-PC with a channel
interface.  That's about all I know.

-Ron

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 88 00:53:11 GMT
From:      iglesias@ICS.UCI.EDU (Mike Iglesias)
To:        comp.protocols.tcp-ip
Subject:   Turning off ip forwarding in Ultrix v1.2

We have a microvax II running Ultrix v1.2 that is doing ip forwarding
We don't want it to that.  Is there a way to turn it off, given that
we don't have sources?

Please reply directly to me - I don't want the whole list to have to
read all the replies (I hope to get!).


Thanks,

Mike Iglesias
University of California, Irvine

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 88 01:06:02 GMT
From:      cheriton@PESCADERO.STANFORD.EDU ("David Cheriton")
To:        comp.protocols.tcp-ip
Subject:   Re:  offloading the protocols

VMTP (RFC 1045) is specifically designed to work well with hardware support
on a network adaptor board with its own processing power.  In fact, we have
designed and are implementing such a board to support VMTP, and this process,
concurrent with the protocol design and refinement, has significantly
influenced the design of the protocol.  I would agree there are severe limits
on what such intelligent interfaces can provide with current protocols
independent of how well the boards are designed.  I would also agree that
most intelligent interfaces to date are slower than the dumb fast ones
when you look at transport-level performance.  However, my experience
with VMTP and the NAB (Network adaptor Board) we are building convinces
me that this approach is essential for transport-level performance in the
same general range as the network when we go to 100 Mb networks and higher.
Moreover, offboarding the processing load of protocols seems to have
additional advatnages on multiprocessors machines because the interrupts
and cache demands of protocols leans on the critical resources, namely the
system bus.

Interested parties can send to my secretary (nevena@pescadero.stanford.edu)
for a copy of our draft paper on the NAB.  The VMTP spec is of course
available as an RFC - only the first 30 pages are really needed to get
a feeling for the protocol.

David Cheriton

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 88 17:16:16 PST
From:      satz@clash.cisco.com
To:        Hank Nussbacher <HANK%TAUNIVM.BITNET@cunyvm.cuny.edu>
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: ISN
>> In addition, it has implemented a TTL type
>> of field so that packets that loop around between REBs get
>> removed.  You can configure in each REB what the maximum TTL
>> should be and each outgoing packet gets assigned that number.
>> As the packet passes thru other REBs, the number is decremented.
>> When it hits zero, the packet is thrown away.

If it is acting as a router it should use the TTL field in the IP
header. It seems, from your message, that another field may be used
possibly from a REB-REB protocol.


-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Mar-88 16:23:55 EST
From:      tomwest@gpu.utcs.toronto.edu (Tom West)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Book on TCP/IP



   A little while ago, there were several recommendations for a book that
might serve as an introduction to the technical aspects of TCP/IP.  It
(if I remember correctly) was to be published by Addison-Wesley.  Unfortunately,
I lost the reference.  Could kind person mail me the author and title of
the book.  Thank you very much.

-- 
				Tom West

BITNET:         tomwest@utorgpu.bitnet, tomwest@gpu.utcs.utoronto
Internet:       tomwest@gpu.utcs.toronto.edu 
UUCP:           tomwest@utgpu 

		utzoo, yetti, harpo, mnetor \
		cbosgd, deepthot, utoronto  -  !utgpu!tomwest
		ihnp4, lsuc, sfmin, vnr-vpa /

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 88 12:36:00 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270 on Terminal Servers

In article <Mar.12.17.46.18.1988.5479@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>I know at least one vendor who claims to be working on tn3270 mode.  I
>think I can tell you why it hasn't been done yet.  First, it needs
>more memory and CPU than a normal telnet connection.  You have to
>maintain a screen image and various other state information, and you
>have to do the emulation.  Most terminal servers currently use a 68000
>with not much memory.  But that's not the big problem.  The big
>problem is that you need to have access to somthing like termcap for
>the user's terminal.  Terminal servers don't have disks, and they


	[]

	From my past, I remember implementing a 3270 emulator under
	UNIX using termcaps.  It doesn't work!  3270 terminals need
	5 or 6 modes of screen attributes to be effective (normal,
	hilight,reverse,reverse hilight,blinking,underline,etc.).
	Verry few termvcaps entries have these attributes defined
	completely.  Now the vendor has to decide... do I want to
	start mucking with termcaps for each and every terminal type I wish to
	support, or... let the user do it themselves.  As I remember,
	neither way was a viable solution.

	Yes you could define a limited subset of terrminals that would
	be supported, but that subset grows rapidly based on user feedback.

	As to memory and CPU.  The EBCDIC --> ASCII stuff eats some
	cycles, but the byte stream interpretation was no worse than
	any VT220 application.  You have to scan for order codes and
	parse some following bytes accoordingly.  Each screen image
	needs roughly 4K of memory, 2 K for the image, and 2K for the
	attributes, not a lot of memory these days.

	As with anything else, it can be done, but its a pain.  Is it
	worth it?  Count the number of PC based 3270 emulators sold;
	multiply by $500.  What do you think?


						Larry Backman
						Micom - Interrlan

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 88 16:43:35 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ISN


	
	There is a bridge that is about 70% of a router.  It is called
	REB (Remote Ethernet Bridge).  The designer has taken a small
	number of the fields in the IP header and has done a similar
	implementation at level II.
	
	For example, REB can close loops.  I can assign a weight to each
	line (i.e. one line is 9.6kb, another is T1, another is X.25,
	and another should hardly ever be used) and based on the weight
	and the network load, the REB will determine the routing the
	packet should take.  In addition, it has implemented a TTL type
	of field so that packets that loop around between REBs get
	removed.  You can configure in each REB what the maximum TTL
	should be and each outgoing packet gets assigned that number.
	As the packet passes thru other REBs, the number is decremented.
	When it hits zero, the packet is thrown away.
	
	There are many other functions that was designed via 802.3 D -
	Managament specs.
	
	What it cannot do is ARP or ICMP but if you are looking for a
	bridge replacement, you should seriously evaluate the RAD REB.
	
	Hank
	
I would describe this as a level-2 router, essentially an IMP for Ethernets.
Seems like a reasonable concept.  The bridge guys work very hard to
keep the overhead low enough to handle back-to-back Ethernet packets;
can the REB guys do as well, with the extra protocol processing?

Bob Braden

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 88 18:22:52 GMT
From:      jc@heart-of-gold (John M Chambers x7780 1E342)
To:        comp.protocols.tcp-ip
Subject:   Ping, checksum algorithm?

Does anyone have a PD version of ping?  How about a C-coded routine that
does the IP checksum calculation?  We have one that is written in VAX
assembly language, which is OK for a VAX, but it doesn't work too well
on a 68020....

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Mar 88 17:15:43 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   ISN
>If bridges are connected via a closed polygon, the packet stays
>"in flight" forever.
>
>charlie slater
>charlie@amdcad.amd.com

There is a bridge that is about 70% of a router.  It is called
REB (Remote Ethernet Bridge).  The designer has taken a small
number of the fields in the IP header and has done a similar
implementation at level II.

For example, REB can close loops.  I can assign a weight to each
line (i.e. one line is 9.6kb, another is T1, another is X.25,
and another should hardly ever be used) and based on the weight
and the network load, the REB will determine the routing the
packet should take.  In addition, it has implemented a TTL type
of field so that packets that loop around between REBs get
removed.  You can configure in each REB what the maximum TTL
should be and each outgoing packet gets assigned that number.
As the packet passes thru other REBs, the number is decremented.
When it hits zero, the packet is thrown away.

There are many other functions that was designed via 802.3 D -
Managament specs.

What it cannot do is ARP or ICMP but if you are looking for a
bridge replacement, you should seriously evaluate the RAD REB.

Hank
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 88 21:00:31 GMT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping, checksum algorithm?

The 'ping.c' distributed with Berkeley unix is public
domain, distribution unlimited, according to comments
in the source.  What's your address?

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 1988 05:12-EST
From:      CERF@A.ISI.EDU
To:        hrp%windsor.CRAY.COM@UMN-REI-UC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: offloading the protocols
I'm not goin to get into the front-end versus operating system resident
protocol argument (I argued against the front-end years ago on the same
basis you suggest Dave Clark argues, if anyone cares about my historical
biases).

However, it seems to me that as you approach the gigabit channels, you
really want to simplify the host's view of networking. An analogy might be
found in disk/file access and virtual memory. Years ago, an operating
systme was designed at UCLA called the Sigma EXperimental system (SEX for
short - the user's manual was a popular item!). It ran on a Sigma 7 made
by Scientific Data System (later, Xerox Data Systems, later, R.I.P.).

The notion of associating ("coupling" - God, I never thought about how
suggestive that term was in connection with the operating system acronym)
virtual memory with pages of files was an essential design element.

One would associate a particular virtual page space with disk pages 
occupied by a file. This is not much different than virtual memory
linked to pages of a disk, except in this case, actions to the memory
content were reflected in changes to the FILE (not just changes to a 
disk page which happened to represent a page of virtual memory space).

So, the user's virtual memory space was mapped onto the file system. I
imagine Multics could be considered to have done something like that
only even more elegantly with its rich addressing structure.

Perhaps what is needed is a way to associate virtual memory with places
in the networking space. Writing to virtual memory would be like writing
to the network. PDP-11's had the concept of associating certain words of
memory with I/O channels. But what I am looking for is a notion that lets
very simple actions to memory be interpreted by outboard processors as
network-related actions. 

Perhaps Dave Clark could expand on his theme which I view as related to
your question if not the rather poorly expressed ideas above.

Vint Cerf
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 01:16:16 GMT
From:      satz@CLASH.CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: ISN

>> In addition, it has implemented a TTL type
>> of field so that packets that loop around between REBs get
>> removed.  You can configure in each REB what the maximum TTL
>> should be and each outgoing packet gets assigned that number.
>> As the packet passes thru other REBs, the number is decremented.
>> When it hits zero, the packet is thrown away.

If it is acting as a router it should use the TTL field in the IP
header. It seems, from your message, that another field may be used
possibly from a REB-REB protocol.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 03:48:09 GMT
From:      thomson@oldhub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: maximum Ethernet throughput



Van Jacobson's results are certainly startling, but I can't help
believing that a significant part of that speedup must be in
changes to the mbuf handling, the socket code, and the LANCE
driver.  My evidence is a test I ran on a 3/50: I defined a
'protocol' whose PRU_SEND action was to checksum each mbuf then
hand it directly to the driver, with a dummy AF_UNSPEC destination so
there would be no ARPing going on.  This exercises vanilla
SUN mbuf, socket, and interface driver code, while replacing all
of TCP/IP by simple checksumming - so no protocols at all.
The data goes nowhere, and there are no acks to deal with.
Even so, this configuration could not source data to the wire faster
than about 3.6Mb/sec.  I could hit 8Mb/sec if I threw the data
away right after checksumming, without passing it to the driver at all.

-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 05:52:55 GMT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with UNIX tcp

In article <8802181625.AA27348@cod.nosc.mil>, neerma@COD.NOSC.MIL (Merle A. Neer) writes:
> The problem simply stated is this: the user process cannot get the
> status of its tcp connections from UNIX.
 
> Have any UNIX guru-types ever considered offering a
> 'status(myconnect)' call?  We'll gladly pay for one.

If you're running 4.3, I can give you a socket ioctl to return the
status of the connection (as in one of the values in
../netinet/tcp_fsm.h, like TCPS_LISTEN, TCPS_ESTABLISHED, TCPS_CLOSING,
etc).  It's not really hard; it'd take all of an afternoon.  Just drop
another ioctl into ../h/ioctl.h and into ../netinet/tcp_usrreq.c (in
the if req == PRU_CONTROL statement).

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 88 11:02
From:      "Antony F.Martin" (on UK.MOD.RSRE) <AFM%rsre.mod.uk@relay.MOD.UK>
To:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   RE: WHOIS for VMS Vax...
We have a version of WHOIS, written in Ada, which runs on a MicroVAX II
with VMS and Wollongong TCP/IP with Shared-Deqna. We are prepared to make
this available (perhaps via SIMTEL20?).
 
Antony Martin
Royal Signals and Radar Establishment
Ministry of Defence
UK

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 06:23:55 GMT
From:      mouse@mcgill-vision.UUCP (der Mouse)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <23511@hi.unm.edu>, cyrus@hi.unm.edu (Tait Cyrus) writes:
> I am looking for PD version of code that accomplishes the same thing
> as rsh [...].  The reason I am interested in something other than rsh
> is because here at UNM we are strongly considering disallowing the r*
> programs (rsh/rcp/rlogin) because they do NOT conform to the RFC's
> [as previously indicated, the non-conformance in question is
> case-sensitivity of hostname lookups]

Why is this a disadvantage?  The nameserver does case-insensitive
lookups; why should the user program have to care?

> as well as being BIG security problems (.rhosts).

If this is a problem at all, it's a problem with your user community.
They won't create .rhosts files unless they care more about convenience
than security, and if that's the case, nothing you do will help
(assuming you've educated them in the security holes implicit in
creating .rhosts files).  People are almost always the weakest link in
any security system.  You can "fix" the hosts.equiv and .rhosts
"problem" very easily by running this every night:

rm -f /etc/hosts.equiv
< /etc/passwd awk -F: '{printf("rm -f %s/.rhosts",$6);}' | sh

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 16:35:00 PST
From:      "Gabriel Hirl" <gabi@twg.com>
To:        "king" <king@afsc-hq.arpa>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   Re:WHOIS for VMS Vax
The Wollongong WIN/TCP 3.2 release includes the WHOIS utility.
First customer shipment is scheduled for April 1988.
Also, for those interested, this release supports Van Jacobson's and
Mike Karel's TCP code.

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 10:12:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: offloading the protocols

I'm not goin to get into the front-end versus operating system resident
protocol argument (I argued against the front-end years ago on the same
basis you suggest Dave Clark argues, if anyone cares about my historical
biases).

However, it seems to me that as you approach the gigabit channels, you
really want to simplify the host's view of networking. An analogy might be
found in disk/file access and virtual memory. Years ago, an operating
systme was designed at UCLA called the Sigma EXperimental system (SEX for
short - the user's manual was a popular item!). It ran on a Sigma 7 made
by Scientific Data System (later, Xerox Data Systems, later, R.I.P.).

The notion of associating ("coupling" - God, I never thought about how
suggestive that term was in connection with the operating system acronym)
virtual memory with pages of files was an essential design element.

One would associate a particular virtual page space with disk pages 
occupied by a file. This is not much different than virtual memory
linked to pages of a disk, except in this case, actions to the memory
content were reflected in changes to the FILE (not just changes to a 
disk page which happened to represent a page of virtual memory space).

So, the user's virtual memory space was mapped onto the file system. I
imagine Multics could be considered to have done something like that
only even more elegantly with its rich addressing structure.

Perhaps what is needed is a way to associate virtual memory with places
in the networking space. Writing to virtual memory would be like writing
to the network. PDP-11's had the concept of associating certain words of
memory with I/O channels. But what I am looking for is a notion that lets
very simple actions to memory be interpreted by outboard processors as
network-related actions. 

Perhaps Dave Clark could expand on his theme which I view as related to
your question if not the rather poorly expressed ideas above.

Vint Cerf

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Mar 88 20:59:46 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "kwe@bu-it.bu.edu (Kent W. England" <kwe@BU-CS.BU.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   useful RR and SR (was: IP options crash our Sun gateway )

I have found source routing useful for tracing routes, both for local net
access problems and routing problems between gateways.  Today I had to bemoan
the fact that a particular gateway would not source-route, even though it did
not crash, because they had called to see why they could ping a core gateway
but not establish an EGP connection.  With source routing I send a packet from
gateway A to B and back to myself, and vice versa.  If it fails, I may get
ICMP net-unreachable for route problems, or host-unreachable for host access
problems.

One additional feature would make problem tracking useful; that is the ability
to ask a gateway to give back its opinion of the next hop for a particular
destination net.  This is the info that RR gives you, but only if the packet
gets back to you.  If gateway A wants to send to B and B is a black hole, you
would like to get the info from A instead.

I have been able to do source routing through 4.3BSD systems.  I think they
may do it even if IP_FORWARDING is off.

LSI11 core gateways do source-and-record-route but not record-route.
Butterfly gateways do both.  In both gateways, the alignment of the IP address
fields in the options is not critical.

Mike Brescia
BBNCC Gateway Development
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 14:23:33 GMT
From:      robert@richp1.UUCP (Robert Miller)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: who posted the delni summary? (enet in a can)


MICOM (1-800-LAN TALK) has just come out with an equivilant
of the DELNI box called 8-4-1 Multiport Transceiver.
Does everything the DELNI can plus costs less plus has more LED's
on front panel to provide more status.  Real nice!

I have no connection with either DEC or MICOM other than that
we use both here.

-- 
.......................................
"To open, cut along dotted line."  ....:.......................................
                                  :     :  Robert Miller @ ihnp4!richp1!robert
                                   .....

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 16:14:39 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: IP options crash our Sun gateway

In article <8803151852.AA12900@sccgate.scc.com> oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) writes:
>When our stock SMI DDN gateway attempted to forward IP-grams containing RR or
>LSRR options, it would crash.  Our box is a 3/260 running SOS 3.5 and acts as
>a gateway between our local ethernet-based network and the ARPANET.  
>
>Based on a report from Allison Mankin of MITRE, that the crashing is caused by
>a previously reported typo in ip_stripoption(), I have patched our binary in an
>attempt to reverse the effects of the typo.  The patch has been working now for
>a little over 2 weeks.  

	It seems that IP RR and LSRR options will crash a lot of
gateways.  I would like to hear from others how widespread the
problem is (other known implementation failures) and what they think
the utility of RR and LSRR is for debugging and network management.
	Seems to me that record route and loose source routing options
would be extremely useful for checking router tables without actually
doing a netstat or equivalent.  However, if there are too many routers
that crash or don't record themselves or follow the route request,
then such an option is unusable.
	I have never read a conversation on this in tcp-ip.  Anyone
able to make use of IP route options?  If so, how useful is it?

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 17:37:58 GMT
From:      phil@EAST.BERKELEY.EDU (Phil Lapsley)
To:        comp.protocols.tcp-ip
Subject:   LSRR and RR IP options

These options can be extremely useful for figuring out what routes are
being used to get from point A to point B.  Although some gateways
crash when presented with an IP datagram with LSRR/RR options (and almost
as bad, other gateways simply drop the packet), things are generally getting
better.  Proteon gateways now (version 7.4) correctly handle LSRR/RR,
and 4.3 BSD now does the right thing as well (although it had a bug that
caused it to do some wrong stuff for a while).  Buttergates also do the
right thing.  Ultrix (2.0) simply eats the packets, as does HPUX and Dynix
(sequent OS).  As mentioned, Suns often crash in the action of forwarding
the packets.  I don't know how the Fuzz fares under IP option attack.

Still, one shouldn't say that the options are useless.  Rather, one
should beat on the vendors for selling joe code.  (Call 1-800-USA4SUN
and complain! :-)

							Phil

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 17:58:04 GMT
From:      toms@amdcad.AMD.COM (Tom Slykhouse)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PC/AT LANCE Card


Advanced Micro Devices has completed development on a Public Domain
Ethernet board for the PC/AT's and Clones, based on our LANCE controller.
Manuals, schematics and artwork are available for this product. 

We are additionally considering porting several of the common
communications packages to this board.  One possibility is KA9Q
TCP/IP.  If anyone on the net would like this package ported, or would
prefer another package please respond to me with EMail. 

Tom Slykhouse
Advanced Micro Devices
toms@amdcad.AMD.COM
decwrl!amdcad!toms
(408)749-2517

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 19:02:00 GMT
From:      AFM@rsre.mod.UK ("Antony F.Martin", on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   RE: WHOIS for VMS Vax...

We have a version of WHOIS, written in Ada, which runs on a MicroVAX II
with VMS and Wollongong TCP/IP with Shared-Deqna. We are prepared to make
this available (perhaps via SIMTEL20?).
 
Antony Martin
Royal Signals and Radar Establishment
Ministry of Defence
UK

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 88 20:28:54 GMT
From:      pedersen@acf3.NYU.EDU (paul pedersen)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping, checksum algorithm?

In article <123@heart-of-gold> jc@heart-of-gold (John M Chambers x7780 1E342) writes:
>[question about 'ping']


Sorry to post about this, but addresses like "jc@heart-of-gold" are really
unacceptable.  I tried to comment via e-mail, but of course no sane mailer
will accept such an address.  "Heart-of-gold" is too long for UUCP, and
doesn't have the right format for the domain system.  Puh-leeze get your
system fixed so it doesn't send out articles with meaningless addresses.

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 00:35:00 GMT
From:      gabi@TWG.COM ("Gabriel Hirl")
To:        comp.protocols.tcp-ip
Subject:   Re:WHOIS for VMS Vax

The Wollongong WIN/TCP 3.2 release includes the WHOIS utility.
First customer shipment is scheduled for April 1988.
Also, for those interested, this release supports Van Jacobson's and
Mike Karel's TCP code.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 01:59:46 GMT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   useful RR and SR (was: IP options crash our Sun gateway )


I have found source routing useful for tracing routes, both for local net
access problems and routing problems between gateways.  Today I had to bemoan
the fact that a particular gateway would not source-route, even though it did
not crash, because they had called to see why they could ping a core gateway
but not establish an EGP connection.  With source routing I send a packet from
gateway A to B and back to myself, and vice versa.  If it fails, I may get
ICMP net-unreachable for route problems, or host-unreachable for host access
problems.

One additional feature would make problem tracking useful; that is the ability
to ask a gateway to give back its opinion of the next hop for a particular
destination net.  This is the info that RR gives you, but only if the packet
gets back to you.  If gateway A wants to send to B and B is a black hole, you
would like to get the info from A instead.

I have been able to do source routing through 4.3BSD systems.  I think they
may do it even if IP_FORWARDING is off.

LSI11 core gateways do source-and-record-route but not record-route.
Butterfly gateways do both.  In both gateways, the alignment of the IP address
fields in the options is not critical.

Mike Brescia
BBNCC Gateway Development

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 1988 10:19-EST
From:      Alessandro.Forin@SPEECH2.CS.CMU.EDU
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Off loading the protocol

Work in the area of networked shared memory is progressing quite rapidly:
It is not just a crazy thought.
The following is a short list of references to recent work that is relevant
to the subject.  I'll be glad to receive notice of any other activity
in the area by people in this list.

1.    Bisiani,  R.  and  Forin,  A.,  ``Architectural Support for
Multilanguage Parallel  Programming  on  Heterogeneous  Systems'',  2nd
International Conference   on  Architectural  Support  for  Programming
Languages  and Operating Systems, IEEE, Palo Alto , October 1987, pp. 21-30.

2.    Cheriton D.R., ``Problem-oriented Shared Memory: A Decentralized
Approach to  Distributed  System  Design'',  Proc.  of  the  6th  Intl.
Conf.  on Distributed Computing Systems, May 1986, pp. 190-197.

3.    Kai Li and Paul  Hudak,  ``Memory  Coherence  in  Shared  Virtual
Memory Systems'',  Proceedings  of  the  Fifth Annual Symposium on
Principles of Distributed Computing, ACM, 1986, pp. 229-239.

4.    Krishnaswamy, Ahuja, Gelernter,  Carriero,  ``Progress  Towards  a
Linda Machine'',  Proc.  ICCD,  IEEE-CS  and  IEEE  Circuits, October 1986,
pp.  97-101.

5.    Ramachandran,  U.,  Ahamad,  M.,  Khalidi,  M.,  ``Hardware  Support
For Distributed Shared Memory'', Report GIT-ICS-87/41, Georgia Tech,
November 1987.

6.    Rashid, R. et al., ``Machine-Independent Virtual  Memory  Management
for Paged Uniprocessors and Multiprocessor Architectures'', 2nd
International Conference  on  Architectural  Support  for  Programming
Languages   and Operating Systems, IEEE, Palo Alto , October 1987, pp.
31-39.

7.    Wendorf,  J.  and  Tokuda, H., ``An Interprocess Communication
Processor:  Exploiting  OS/Application  Concurrency'',  Tech.  report
CMU-CS-87-152, Carnegie-Mellon University, March 1987.

8.    Zayas,  R.E., The Use of Copy-on-reference in a Process Migration
System, PhD dissertation, Carnegie-Mellon, January 1987.
-----------------------------------------------------------------------------
Alessandro Forin, Computer Science Dept., Carnegie-Mellon University,
5000 Forbes Pittsbugh PA, 15213.
ARPA: af@cs.cmu.edu
Phone: (412) 268-2569
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18 Mar 88 12:00 EST
From:      DAN <S72TDAN%TOWSONVX.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: Re: IP options crash our Sun gateway
I'M NOT TOO SURE ON HOW TO SEND A MAIL MESSAGE SO I'M DOING IT THIS WAY.

        PLEASE UNSUSCRIBE ME FROM LIST TCP-IP.
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 07:17:11 GMT
From:      nishida@nsisv2.nec.junet (Takeshi.Nishida)
To:        comp.protocols.tcp-ip
Subject:   (none)

Dear Sir,

I would like to get the "ARPANET Protocol Handbook",
"Internet Protocol Transition Workbook", and other
related published documents.
How can I get such kind of documents?
Thanks in advance.


Takeshi Nishida

Communication Research Lab.
C&C Systems Research Labs.
NEC Co.
Kawasaki, Kanagawa 213, Japan

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 11:38:56 GMT
From:      farber@CIS.UPENN.EDU (David Farber)
To:        comp.protocols.tcp-ip
Subject:   Off loading the protocol

The following is abstracted from a note on our experiences with a line
of research aimed at eamining a radically different approach to "off
loading" designed for the very high speed networking era -- "Gigabit
networking". I would be happy to supply the full text and/or memnet
documents to any interested people.


             Some Thoughts on the Impact of Very High Speed Networking on
                                Processor Interfaces

......

          Approach

            This note  proposes a  completely different  view  of  computer
          networking, a  view which  derives from experiments started in my
          group at  the University  of  Delaware  (and  continuing  at  the
          University of  Pennsylvania) resulting  in the  creation a  novel
          local network  architecture called "MEMNet." MEMNet is a research
          system aimed  at exploring ways of removing the severe processing
          overhead found  in distributed  operating systems.  The  approach
          MEMNet takes  is to treat the network as a mechanism which allows
          a  processor  to  access  the  collective  memory  space  of  the
          distributed  system.   Thus,  when   a  processor   in  a  MEMNet
          environment needs  to send data via the high-speed local network,
          it simply  writes to  memory   addresses which  are in the memory
          space  of  the  recipient  processor.  Similarly,  the  recipient
          processor, when  it chooses to examine data which has been "sent"
          by another  processor, reads  its local  memory  (or  physically-
          remote memory,  in a  hierarchical memory  system) simply  by the
          normal memory  access mechanisms of that processor. In the MEMNet
          environment, there  is a  set of  special memory controllers with
          adequate  caching,  connected  together  via  a  high-speed  (200
          megabit) ring. The caching provides a mechanism equivalent to the
          snooping caches of modern multiprocessors.

            During this  research, we examined the architecture of software
          systems which  would run  in a  MEMNet environment.  Much to  our
          surprise (although  we  should  not  have  been  surprised),  the
          software implications  of  such  a  distributed  environment  are
          essentially non-existent.  That is,  a software system written to
          run on  the fully  distributed MEMNet environment is essentially,
          in all  respects, identical  to the same software system designed
          to run on a simple multiprocessor, shared-memory environment.

            The issues  one must  face in  designing  the  architecture  of
          future wide-area,  high-speed networks ......
          
            ......

	    In summary,  this note  suggests that we reexamine what we mean
          by "networking"  in the  future.  It  essentially  suggests  that
          networking is simply a special case of interprocess communication
          over a  widely-distributed computer  system, and  thus  can  take
          advantage of technology already developed.

          
_________________________________________________________________________


---------------
David J. Farber; Prof. of CS and EE, Director - Distributed Systems Labs.
University of Pennsylvania/200 South 33rd Street/Philadelphia, PA  19104-6389
Tele: 215-898-9508; FAX: 215-274-8192 

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 15:19:00 GMT
From:      Alessandro.Forin@SPEECH2.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Off loading the protocol


Work in the area of networked shared memory is progressing quite rapidly:
It is not just a crazy thought.
The following is a short list of references to recent work that is relevant
to the subject.  I'll be glad to receive notice of any other activity
in the area by people in this list.

1.    Bisiani,  R.  and  Forin,  A.,  ``Architectural Support for
Multilanguage Parallel  Programming  on  Heterogeneous  Systems'',  2nd
International Conference   on  Architectural  Support  for  Programming
Languages  and Operating Systems, IEEE, Palo Alto , October 1987, pp. 21-30.

2.    Cheriton D.R., ``Problem-oriented Shared Memory: A Decentralized
Approach to  Distributed  System  Design'',  Proc.  of  the  6th  Intl.
Conf.  on Distributed Computing Systems, May 1986, pp. 190-197.

3.    Kai Li and Paul  Hudak,  ``Memory  Coherence  in  Shared  Virtual
Memory Systems'',  Proceedings  of  the  Fifth Annual Symposium on
Principles of Distributed Computing, ACM, 1986, pp. 229-239.

4.    Krishnaswamy, Ahuja, Gelernter,  Carriero,  ``Progress  Towards  a
Linda Machine'',  Proc.  ICCD,  IEEE-CS  and  IEEE  Circuits, October 1986,
pp.  97-101.

5.    Ramachandran,  U.,  Ahamad,  M.,  Khalidi,  M.,  ``Hardware  Support
For Distributed Shared Memory'', Report GIT-ICS-87/41, Georgia Tech,
November 1987.

6.    Rashid, R. et al., ``Machine-Independent Virtual  Memory  Management
for Paged Uniprocessors and Multiprocessor Architectures'', 2nd
International Conference  on  Architectural  Support  for  Programming
Languages   and Operating Systems, IEEE, Palo Alto , October 1987, pp.
31-39.

7.    Wendorf,  J.  and  Tokuda, H., ``An Interprocess Communication
Processor:  Exploiting  OS/Application  Concurrency'',  Tech.  report
CMU-CS-87-152, Carnegie-Mellon University, March 1987.

8.    Zayas,  R.E., The Use of Copy-on-reference in a Process Migration
System, PhD dissertation, Carnegie-Mellon, January 1987.
-----------------------------------------------------------------------------
Alessandro Forin, Computer Science Dept., Carnegie-Mellon University,
5000 Forbes Pittsbugh PA, 15213.
ARPA: af@cs.cmu.edu
Phone: (412) 268-2569

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 16:01:45 GMT
From:      oconnor@SCCGATE.SCC.COM (Michael J. O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options crash our Sun gateway

Maybe I should have worded it differently.  It's my contention that a Sun
gateway running a version of SOS earlier than 4.0 can crash when it attempts
to forward any option bearing datagram not just the record route types.  The
only option generating software that I have access to is the Ping with RR and
LSRR which was described in this forum a month or so ago.  People were crashing
our gateway every time they tried to send one of those packets through our SMI
box.
	Excuse my pontificating, but it is the presence of IP-options that is
optional not the implementation.  I don't have a copy of the Mil-Std handy but
my copy of the RFC states "Every internet module must be able to act on every
option."  I just don't think that crashing was the act that the authors had in
mind.
	The part that still irritates me is SMI's attitude that this is a bug
that I should be able to live with until they release SOS 4.0.  On top of that
there is the rumor that the Sunlink DDN package will not be updated until well
after the 4.0 release.  If true, that means our gateway will be the last machine
upgradable to SOS 4.0.

				Mike

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 16:13:10 GMT
From:      mtune!codas!ablnc!gil@rutgers.edu  (Gil Widdowson)
To:        tcp-ip@sri-nic.arpa
Subject:   TLI HELP!!!

I need some help with WIN/3B 2.1 and UNIX 5.3.1 TLI.  I  have  an
application  that  worked with both the TLI and sockets interface
under WIN/3B 1.1. I have had to make some changes to make sockets
work  under  2.1,  but  I can not get even get to first base with
TLI. The AT&T TLI documentation describes  things  at  a  generic
level  since  it  does  not  know  anything  about  the transport
provider you will be using. Unfortunately, the WIN  documentation
that  I  got,  does  not  address what data structures need to be
used. Is it still the sockets structures such as sockaddr_in when
you deal with network addressing.

Here is the problem I have now. I am trying to send a datagram. I
do  a  t_open()  and  get  a stream with a service type of T_CLTS
according to the info returned to me. I  do  a  t_bind(fd,  NULL,
&ret)  and  seem  to  get a port. What is the format of the eight
byte ret.addr.buf returned? I am getting back what looks  like  a
the  port id in the first four bytes and zeroes in the last four?
For ha-has, I do a t_getstate() before the  t_sndudata()  and  it
says  the  stream  is  in the idle state. Then when I attempt the
t_sndudata(), I get

errno 203  Socket operation on non-socket

A rather strange TLI error. I am using the same udata structure I
used  under  WIN/3B  1.1.  This  uses  a sockaddr_in structure to
define the destination address for the datagram.


I would appreciate ANY help. I would  really  like  some  working
code fragments using TLI and poll() to manage multiple stream I/O
in the same process. Additional  documentation  references  would
also be appreciated.  I currently have:
UNIX Sys V programmer's ref and guide
UNIX Sys V Network programmer's ref
UNIX Sys V Streams programmer's ref
Enhanced TCP/IP WIN/3B Reference Manual for release 2.1

Please reply via email to ihnp4!ablnc!utiprod!gil.

thanks,
gil widdowson
AT&T
(305) 660-6123
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 17:00:00 GMT
From:      S72TDAN@TOWSONVX.BITNET (DAN)
To:        comp.protocols.tcp-ip
Subject:   RE: Re: IP options crash our Sun gateway

I'M NOT TOO SURE ON HOW TO SEND A MAIL MESSAGE SO I'M DOING IT THIS WAY.

        PLEASE UNSUSCRIBE ME FROM LIST TCP-IP.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 18:13:12 GMT
From:      tsudik@MALIBU.USC.EDU (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   Re:  LSRR and RR IP options

"4.3 does the right thing well"????
Does that include incorrectly filled out IP headers when fragmentation
is performed and option(s) is(are) present in the header? 
Until this bug is fixed using any IP option is not safe.

Gene Tsudik

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 19:13:15 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: offloading the protocols

In article <[A.ISI.EDU]17-Mar-88.05:12:56.CERF> CERF@A.ISI.EDU writes:
	[discussion of simplifying and speeding up network/host interface]
>
>Perhaps what is needed is a way to associate virtual memory with places
>in the networking space. Writing to virtual memory would be like writing
>to the network. PDP-11's had the concept of associating certain words of
>memory with I/O channels. 

	Doesn't Apollo's Domain [proprietary] networked operating
system do just that?

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 21:08:14 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options crash our Sun gateway

I have found IP options and ICMP functions useful.  I also feel that if
they crash gateways, then the gateway should be replaced darned quick.
I also think that users planning on joining or doing an Internet should
become familiar with RFC1009 which explicitly states that Record Route,
Loose and Strict Source Route,among the others, are required for gateways.

OPTION does not mean its up to the discretion of the Vendor, only that it
may or may not be in an IP header!

We are planning to use the IP Security Option, or son of ...  You bet the
IP options are important.  A vendor who's product does not work correctly
will not be looked on kindly from here.

cornett philip wood  (cpw@lanl.gov)

Los Alamos National Laboratory

 

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 22:03:24 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   IP Options and ICMP Messages

For those of you with 4.3BSD implimentations, as in Berkeley UNIX on a
VAX, or SunOS 4.0 on a SUN, and those of you who think you have a 4.3
implimentation on your operating system, this, bud, is for you:

Product: Tools to exercise the Internet
Access: Anonymous FTP
Source Host: lambda.lanl.gov
Source Directory: /pub/inet
Source Files:

	total 175
	-r--r--r--  1 cpw           786 Mar 18 14:38 Copyright
	-r--r--r--  1 cpw          1381 Mar 18 14:38 EXAMPLES
	-r--r--r--  1 cpw          6883 Mar 18 14:38 Makefile
	-r--r--r--  1 cpw          2156 Mar 18 14:38 README
	-r--r--r--  1 cpw           958 Mar 18 14:38 chargen.sh
	-r--r--r--  1 cpw          4753 Mar 18 14:38 chargend.c
	-r--r--r--  1 cpw           922 Mar 18 14:38 daytime.sh
	-r--r--r--  1 cpw           952 Mar 18 14:38 discard.sh
	-r--r--r--  1 cpw          3420 Mar 18 14:38 discardd.c
	-r--r--r--  1 cpw          4152 Mar 18 14:38 echod.c
	-r--r--r--  1 cpw           924 Mar 18 14:38 ecko.sh
	-r--r--r--  1 cpw           954 Mar 18 14:38 finger.sh
	-r--r--r--  1 cpw          1177 Mar 18 14:38 getclientname.c
	-r--r--r--  1 cpw           966 Mar 18 14:38 hostname.sh
	-r--r--r--  1 cpw          3979 Mar 18 14:38 hostnamed.c
	-r--r--r--  1 cpw          2073 Mar 18 14:38 icmp.sh
	-r--r--r--  1 cpw          2659 Mar 18 14:38 inaddr.c
	-r--r--r--  1 cpw          3890 Mar 18 14:38 inet.8
	-r--r--r--  1 cpw         10460 Mar 18 14:38 inet.c
	-r--r--r--  1 cpw         88960 Mar 18 14:41 inet.shar
	-r--r--r--  1 cpw          1757 Mar 18 14:38 lsrr.sh
	-r--r--r--  1 cpw           954 Mar 18 14:38 nicname.sh
	-r--r--r--  1 cpw         15075 Mar 18 14:53 ping.c
	-r--r--r--  1 cpw           947 Mar 18 14:38 quote.sh
	-r--r--r--  1 cpw           969 Mar 18 14:38 rdate.sh
	-r--r--r--  1 cpw          2047 Mar 18 14:38 settod.c
	-r--r--r--  1 cpw          1442 Mar 18 14:38 so.sh
	-r--r--r--  1 cpw          1758 Mar 18 14:38 ssrr.sh
	-r--r--r--  1 cpw          1493 Mar 18 14:38 xdr.c

Producer: Cornett Philip Wood
Affiliation: Los Alamos National Laboratory

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 88 22:05:00 GMT
From:      Houde@HIS-PHOENIX-MULTICS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Sun servers


Does anybody know whether or not a server for a Sun workstation based network
HAS to be a Sun product?  Will Sun allow for this and has anybody done this?
Please direct any responses to Houde at pco.

Thanks,
          Mike Houde

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 88 08:53:35 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Rumors about the death of the ARPANET

When the ARPANET was built, 56Kb lines were used - the leading  edge
of technology of the day. The "New and Improved" network is proposed
to use 1.5Mbit lines (I assume T1). In keeping with the leading edge
philosophy of yore, the just erupting 45Mbit/sec technology (T3?) comes
to mind.

Any thoughts given to T3? After all, current experience with the ARPANET
tends to indicate that applications expand to fill the available bandwidth.

This is not a flame! merely a true question.

Frank Kastenholz
Atex Inc.

All opinions are mine and mine alone. My employer has no idea I am even
saying this.
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 88 09:03:33 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        tcp-ip@sri-nic.arpa
Cc:        Hal Peterson <hrp%windsor.CRAY.COM@uc.msc.umn.edu>
Subject:   Re: offloading the protocols

More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.

A second (equally important issue) is to trust your local I/O
channel.

The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).

By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.


A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:

    The cost of moving the data from disk to user is X, from user
    to network application is X, running the TCP checksum is X and
    then moving the data from the network application to the I/O
    adaptor is X. The total cost is 4X and X seems to be O(n).

This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).


Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.

Remember, this is all empirical! real testing needs to be done.

Frank Kastenholz
Atex Inc.

All opinions are mine - not my employers.....
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19 Mar 88 09:38:16 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: offloading the protocols


More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.

A second (equally important issue) is to trust your local I/O
channel.

The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).

By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.


A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:

    The cost of moving the data from disk to user is X, from user
    to network application is X, running the TCP checksum is X and
    then moving the data from the network application to the I/O
    adaptor is X. The total cost is 4X and X seems to be O(n).

This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).


Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.

Remember, this is all empirical! real testing needs to be done.

Frank Kastenholz
Atex Inc.

All opinions are mine - not my employers.....
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 08:16:03 GMT
From:      GRAVES@MATHOM.CISCO.COM (Bill Graves)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options crash our Sun gateway

IP options are not optional for IP Gateways!
-------

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 12:44:32 GMT
From:      barmar@think.COM (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh equivalent

In article <722@kaos.UUCP> romkey@kaos.UUCP (John Romkey) writes:
>"Trusted ports" (when port numbers less than 1024 can only be used by
>a trusted user) exist only in the world of the Berkeley UNIX TCP.
>Virtually no TCP/IP implementations that are not derived from BSD
>UNIX have the concept of "trusted ports"; they will allow any user
>program to open a connection on any port that isn't already in use.

This is why the Unix RSH server also checks the host against a .rhosts
file.  Presumably you would only list machines that implement the
trusted port rule.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 13:53:35 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET


When the ARPANET was built, 56Kb lines were used - the leading  edge
of technology of the day. The "New and Improved" network is proposed
to use 1.5Mbit lines (I assume T1). In keeping with the leading edge
philosophy of yore, the just erupting 45Mbit/sec technology (T3?) comes
to mind.

Any thoughts given to T3? After all, current experience with the ARPANET
tends to indicate that applications expand to fill the available bandwidth.

This is not a flame! merely a true question.

Frank Kastenholz
Atex Inc.

All opinions are mine and mine alone. My employer has no idea I am even
saying this.

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 14:03:33 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: offloading the protocols


More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.

A second (equally important issue) is to trust your local I/O
channel.

The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).

By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.


A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:

    The cost of moving the data from disk to user is X, from user
    to network application is X, running the TCP checksum is X and
    then moving the data from the network application to the I/O
    adaptor is X. The total cost is 4X and X seems to be O(n).

This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).


Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.

Remember, this is all empirical! real testing needs to be done.

Frank Kastenholz
Atex Inc.

All opinions are mine - not my employers.....

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 14:38:16 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: offloading the protocols



More importantly than devising protocols with OP's in mind is to
move data directly from the users space to the processor -
it should not go through some central network application.

A second (equally important issue) is to trust your local I/O
channel.

The things that really kill the protocol processing are checksums
and "adminstrative" I/O (separate ack's, etc).

By trusting the local I/O channel, you do not need to checksum packets
going between the OP and the host, ack them, etc, etc.


A very empirical model that I have dreamed up for a TCP file
transfer for a non-kernal TCP implementation (e.g. Wollongong, KNET
etc) is:

    The cost of moving the data from disk to user is X, from user
    to network application is X, running the TCP checksum is X and
    then moving the data from the network application to the I/O
    adaptor is X. The total cost is 4X and X seems to be O(n).

This model is not proven, but seems to be borne out by some empirical
testing for running file transfers through a VAX using TCP and UDP
(both had about the same throughput, but TCP took 100% and UDP
about 75% of the CPU - the transfers were done by FTP/TCP and NFS/RPC/
UDP - the only effective difference was the TCP checksum).


Moral of the story, if you can not move the data from the user's space
to the OP directly (i.e. need to go to an application level network
process first) you only save about 25%.

Remember, this is all empirical! real testing needs to be done.

Frank Kastenholz
Atex Inc.

All opinions are mine - not my employers.....

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 18:18:09 GMT
From:      auerbach@hercules.csl.sri.com (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Off loading the protocol

Just curious: How does the shared memory paradigm handle the case where
the machines are of different memory architectures with different
data representations?

PS -- I would like a copy of the full article.

				Thanks, --karl--

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 19:47:42 GMT
From:      phil@EAST.BERKELEY.EDU (Phil Lapsley)
To:        comp.protocols.tcp-ip
Subject:   Who uses directed broadcasts?

RFC 1009 defines an IP directed broadcast as a datagram with a destination
of an IP (sub)network broadcast address.  The packet is forwarded normally
until it reaches a gateway of the destination (sub)net, at which point the
gateway "bursts" the packet into a media broadcast on the local (sub)net.
RFC 1009 also gives gateways the option of "protecting" their local networks
by dropping directed broadcasts on the floor.

Be default, a 4.3 BSD gateway machine that is final hop of a directed
broadcast packet will accept the packet as if it was destined for itself,
but it will not burst the packet into a media level broadcast.
If DIRECTED_BROADCAST is defined when the 4.3 kernel is made, this bursting
will actually occur.

My question is: what gateway implementations actually use directed
broadcasts in the RFC 1009 sense, and why?

							Phil

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 88 21:56:13 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   NTP timewarp

Folks,

At the moment both the ISI and NCAR radio clocks have failed, while the UDel
radio clock is down for repair. This leaves only the UMd and Ford radio
clocks online. Unfortunately, sometime since Friday evening the NTP primary
time-server network, which usually thrives when one or more radio clocks
fail, went nuts and may have delivered bogus time. I believe I have found
and fixed the bug, which turned out to be subtle indeed and bit only in
an interesting and unusual scenario involving broken spanning trees. As
of now (Saturday afternoon) all primary servers ISI, NCAR, UDel, UMd, Ford
and DECWRL have been fixed. Note that all except UMd and Ford are running
at stratum two, since they have automatically resynchronized to the remaining
radio clocks. Secondary servers at Linkabit and Rice, now operating at their
usual stratum two, have also been fixed.

There is at least one Unix site that crashed due the broken time. Since the
bug was due to my own error and not due to the protocol design or Mike Petry's
NTP daemon, I do apologize for any inconvenience. When a new NTP daemon
conforming to the latest protocol revision becomes available, even this latest
bug will not cause timewarps, should something like it ever happen again.

Dave

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 88 05:12:58 GMT
From:      HANK@BARILVM.BITNET (Henry Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re:  ISN

>Seems like a reasonable concept.  The bridge guys work very hard to
>keep the overhead low enough to handle back-to-back Ethernet packets;
>can the REB guys do as well, with the extra protocol processing?

The stated rate is 2500 packets per second (forwarding).  Falls
between a bridge (10,000 pps) and a router (1000 pps).

Hank

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 88 05:15:14 GMT
From:      HANK@BARILVM.BITNET (Henry Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re: ISN

>If it is acting as a router it should use the TTL field in the IP
>header. It seems, from your message, that another field may be used
>possibly from a REB-REB protocol.

It is not acting as a router.  It is a bridge which has adopted "router
concepts" at the level II.  It does not look at the protocol so it can't
possibly use TTL.  It uses its own concept of stopping packets from
travelling in the network forever, all within the definition of 803.2 D -
Management specs.

Hank

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Mar 88 08:12:58 P
From:      Henry Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  ISN
>Seems like a reasonable concept.  The bridge guys work very hard to
>keep the overhead low enough to handle back-to-back Ethernet packets;
>can the REB guys do as well, with the extra protocol processing?

The stated rate is 2500 packets per second (forwarding).  Falls
between a bridge (10,000 pps) and a router (1000 pps).

Hank
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20 Mar 88 08:15:14 P
From:      Henry Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: ISN
>If it is acting as a router it should use the TTL field in the IP
>header. It seems, from your message, that another field may be used
>possibly from a REB-REB protocol.

It is not acting as a router.  It is a bridge which has adopted "router
concepts" at the level II.  It does not look at the protocol so it can't
possibly use TTL.  It uses its own concept of stopping packets from
travelling in the network forever, all within the definition of 803.2 D -
Management specs.

Hank
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 88 15:32:21 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  LSRR and RR IP options

I have a fix for that fragmentation of IP options problem.  I sent it to
berkeley as well as this list.  Can you use it?

cornett philip wood  (cpw@lanl.gov)

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 1988 22:28-EST
From:      CERF@A.ISI.EDU
To:        KASTEN@MITVMA.MIT.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Rumors about the death of the ARPANET
Frank,

DS-3 is a reality for many people who either mux it down to manageable
bandwidth channels or build special interfaces that can push/pull data
at 45 Mbit/sec.

About your earlier messages concerning trusting local I/O and not doing
checksums end to end (by implication) - we have tried that in the past and
been burned - what is different today? Fiber? The problem is that the end
to end channel may still contain some weakness in terms of S/N and bit 
error rate. I'd rather see silicon checksums to speed them up than doing
away with them because they take time...

Vint
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 88 20:35:00 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Re: who posted the delni summary? (enet in a can)

To Robert Miller(he who posted the plug for Micom/Interlan's Delni killer),
		Sounds like the same thing that the Cabletron Multiport
has been doing for TWO YEARS...I also have no affiliation with these people
other than using their equipment.
				Chris VandenBerg
				chris@acc-sb-unix.arpa

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 88 23:12:13 GMT
From:      xiaohe@tybalt.caltech.edu (Xiao-He Zhang)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   How can I leave telnet temporarily?


   I am not sure if this is the right group, and I am sorry if this has been
discussed recently.  Can anyone tell me how I can escape back to local host
from "telnet" temporarily  and how I can supply a login file for "telnet"?
More specificly,
  1.  I see a "z" in telnet commands and it returns me back to my local host.
If I am using a Unix machine, "fg" gets me back to telnet prompt.  But I don't
know how to reconnect to the remote machine except logout the remote machine
and login again.  Is there any way to reconnect me back to the remote machine
without logout first?  If I am using a VMS machine, I even don't know how to
resume the telnet process.
  2.  To log in to a remote machine using telnet, I must say who I am, my
password (of course) and the terminal type.  Is it possible to put these
information in a login file and automate the login procedure so that the first
thing I'll see is the shell prompt of the remote machine?  Better yet, can
I use a crypted file to protect my password in other systems?

   Thank you in advance.

xiao-He Zhang || xiaohe@tybalt.caltech.edu  |  xiaohe@caltech.bitnet

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 11:17:00 PST
From:      "Jerry Scott" <jerry@twg.com>
To:        "kasten" <kasten@mitvma.mit.edu>
Cc:        <tcp-ip@sri-nic.arpa>
Subject:   RE: offloading the protocols
Frank,
	That is not the way that data flows inside the Wollongong
software at all.  The same style used by 4.3BSD is the case here.
First data is sent from the user into the kernel where it is placed
into network buffers call mbufs.  Mbufs can and are chained to
build packets (IP headers, TCP headers, data, etc).  The mbuf
chains are passed between protocols, thus no data is moved at all
just the pointers to the data.  Plus once the data is in the
kernel, it never has to take a hop back to an application for
any further processing.

	We are well aware of the overhead of moving data between
the kernel level and user level, that is why we have done
considerable work in preventing this from happening (eg. Telnet
server is kernel resident, sharing DEC ethernet controllers
using ALTSTART interface).  We have also been eagerly tracking
the good work by Van Jacobson and Mike Karels in the TCP area.
Our implementation allows us to use there public domain code
without modification.

	I do agree with your assessment of the on-board TCP
solutions.  The overhead in the host must be minimal.  Data
must be moved from the user into a DMA area where the smart
controller can access it.  You must trust the data integrity
between the host and the controller performing the network
functions.  Now if you can get Van's and Mike's code down
onto these controllers...

Jerry

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 03:28:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

Frank,

DS-3 is a reality for many people who either mux it down to manageable
bandwidth channels or build special interfaces that can push/pull data
at 45 Mbit/sec.

About your earlier messages concerning trusting local I/O and not doing
checksums end to end (by implication) - we have tried that in the past and
been burned - what is different today? Fiber? The problem is that the end
to end channel may still contain some weakness in terms of S/N and bit 
error rate. I'd rather see silicon checksums to speed them up than doing
away with them because they take time...

Vint

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 88 12:01:26 -0500
From:      haverty@CCV.BBN.COM
To:        CERF@A.ISI.EDU
Cc:        KASTEN@MITVMA.MIT.EDU, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM
Subject:   Re: Rumors about the death of the ARPANET
Vint/Frank - my recollection of some of the conflagrations around
checksumming is that the end-end checksum is valuable even if the
piecewise error control is perfect (10 to however many you like);
what the end-end often catches are plain and simple bugs deep down
in the middle of the path, e.g., a pointer off-by-one in a packet
switch buffer under some obscure condition and the like.  Since
software is never debugged fully until you retire it, such situations
will crop up, and according to Murphy will happen at the worst time.
What would be interesting is to see if there is a way to design
a simple end-end "checksum" designed to catch errors which are not
like those in communications media, i.e., result from bugs, configuration
mistakes, etc., rather than line noise and the like.
Jack
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 1988 10:01-EST
From:      GBELING@A.ISI.EDU
To:        tcp-ip@SRI-NIC.ARPA
Subject:   ?we have the future?
to whom it may be of interest, 
in an announcement of a (at least in Germany) well known computer company 
- name with a lot of letters but not more than seven - for the great
German computer show Cebit in Hannover I found the following:
"MultiNET-Sonderschau
Optische und elektronische CSMA/CD- Netzkomponenten nach
ISO-Standard TCP/IP" 
roughly translated:
"optical and electronical CSMA/CD net components
according to ISO-standards TCP/IP" (whatever that could mean)
Those people have really moved to the front of internetworking
  
regards gerd beling west germanyr
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 88 11:23:54 EST
From:      Jim Petty <PETTY@MITVMA.MIT.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   GATE-D
If anyone out there knows who to contact about the GATE-D gateway
software please drop me a note.  I believe it was written at
Cornell.

Thanks in advance

Jim
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 08:40:21 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Who uses directed broadcasts?

We use directed broadcasts for at least two purposes:

1) Our kinetics Appletalk gateways use them to keep track of each
other or of some hosts that provide services for them.  (I'm a bit
vague, since I'm not an expert with Kinetics.  I support the main IP
gateways, and I know I had to get directed broadcasts working properly
in order to satisfy our Mac guys.)

2) The cisco gateways that we use have a concept of helper address.
If a net doesn't have any servers on it, you can get a gateway to
forward all requests of a certain class (those that would normally be
used for booting: TFTP, bootp, timed, and named) to a specified
address.  FOr reliability reasons, we don't to provide several
servers, so we use a subnet with lots of servers, and use directed
broadcast onto that subnet.

I have also done some experiments with sending messges warning of
gateway reboots etc. by doing rwall to a broadcast addresss for each
of the subnets affected.  It seems to work.

In general, I'd say the directed broadcast mechanism is useful, and
that gateways should implement it.  Note that the way you know whether
to absorb the packet yourself or forward it onto the subnet is by
whether it arrived as a physical broadcast or not.  If it did, then it
has already been broadcast, and you should process it as a host.  If
it arrives as a non-broadcast, then the sender wants you to put it out
on the subnet as a broadcast.  This must be implemented properly, or
disaster will ensue.

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 08:47:00 GMT
From:      YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279)
To:        comp.protocols.tcp-ip
Subject:   Wollogong TcpIp for VMS and Cisco AGS routers interaction.


  We are considering connecting VAX/VMS systems to the TcpIp net via X-25.
We are thinking of using the Wollogong with ACC-6250 cards which will talk
with Cisco AGS routers. The question is: Will this work?
Cisco people say that the VC connection should be initiated from the VAX
side without DDN standard facility (Basic service) and the first byte of
the data field of CALL USER is 0xCC; Can the Wollogong software do it?

Please answer directly to me, since we experience some problems receiving
the distribution lists here.
                                      Thanks in advance, __Yehavi:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
                                                      H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 88 15:47:44 EST
From:      Mark Bodenstein <MAB@CORNELLC.CCS.CORNELL.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Conversion to ISO - Number of NCP Hosts
Network World, in their March 14 issue, published an article about GOSIP,
and the conversion from TCP/IP to ISO protocols.  In brief, they say that
ISO OSI is in the process of becoming a government standard, supplanting
TCP/IP, but that the conversion may take a very long time.  At the end of
the article, they give an analogy to the conversion from NCP to TCP, from
Kevin Ebel of DCA, and say, in effect, that the difference between the
two conversions is only one of scale.

Let's assume, for the purpose of non-argument, that the analogy is apt.
(I don't think it is.)  Does anyone know what the difference in scale is,
between these two conversions?   How many NCP hosts and routers/gateways/
imps were there at the time of conversion to TCP?  And how many TCP hosts
and routers/gateways/imps are there now and/or will there be two years
from now (assuming that to be the time of the beginning of the TCP->OSI
conversion)?

Mark Bodenstein    (mab@cornellc.ccs.cornell.edu)
Cornell University
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon,  21 Mar 88 10:47 +0200
From:      Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA, INFO-VAX@KL.SRI.COM
Subject:   Wollogong TcpIp for VMS and Cisco AGS routers interaction.
  We are considering connecting VAX/VMS systems to the TcpIp net via X-25.
We are thinking of using the Wollogong with ACC-6250 cards which will talk
with Cisco AGS routers. The question is: Will this work?
Cisco people say that the VC connection should be initiated from the VAX
side without DDN standard facility (Basic service) and the first byte of
the data field of CALL USER is 0xCC; Can the Wollogong software do it?

Please answer directly to me, since we experience some problems receiving
the distribution lists here.
                                      Thanks in advance, __Yehavi:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yehavi Bourvine,             Phones: +972-2-584279,     H
Computation Center,                  +972-2-521574      H
The Hebrew University of Jerusalem,                     H
Givat-Ram,  Jerusalem  91904                            H H H
                             Fax: +972-2-527349         HH H
BITnet:    YEHAVI@HUJIVMS                               H   H
InterNet:  YEHAVI@VMS.HUJI.AC.IL                       H
                                                      H
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 15:01:00 GMT
From:      GBELING@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   ?we have the future?

to whom it may be of interest, 
in an announcement of a (at least in Germany) well known computer company 
- name with a lot of letters but not more than seven - for the great
German computer show Cebit in Hannover I found the following:
"MultiNET-Sonderschau
Optische und elektronische CSMA/CD- Netzkomponenten nach
ISO-Standard TCP/IP" 
roughly translated:
"optical and electronical CSMA/CD net components
according to ISO-standards TCP/IP" (whatever that could mean)
Those people have really moved to the front of internetworking
  
regards gerd beling west germanyr

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 15:41:19 GMT
From:      relkins@vax1.acs.udel.EDU (Rob Elkins)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Re: How can I leave telnet temporarily?

In article <5854@cit-vax.Caltech.Edu> xiaohe@tybalt.caltech.edu (Xiao-He Zhang) writes:
>
>   I am not sure if this is the right group, and I am sorry if this has been
>discussed recently.  Can anyone tell me how I can escape back to local host
>from "telnet" temporarily  and how I can supply a login file for "telnet"?

Assuming you are using telnet on unic, when you are logged on to the remote
host, you can enter the escape ^] (thats control right bracket) , that should
take you back to the telnet> prompt, which you can enter ^z to stop the
job to return to the local machine.  To get back, you type fg to bring
the stopeed job back to the foreground, hit return and you should be back
on the remote machine.

Good Luck

Rob Elkins
-- 
ARPA: relkins@vax1.acs.udel.edu   BITNET: FFO04688@UDACSVM 
UUCP: ...!sun!vax1.acs.udel.edu
Live Long and Prosper!
Damn it Jim, I'm a doctor not a <Insert Occupation Here>

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 15:48:43 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

In article <8803210118.AA19481@ucbvax.Berkeley.EDU> KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) writes:
>
>When the ARPANET was built, 56Kb lines were used - the leading  edge
>of technology of the day. The "New and Improved" network is proposed
>to use 1.5Mbit lines (I assume T1). In keeping with the leading edge
>philosophy of yore, the just erupting 45Mbit/sec technology (T3?) comes
>to mind.
>
>Any thoughts given to T3? 

	There is the FCCSET [fixit!] committee of the President's
Office of Science and Technology which has done studies and set up
subcommittee's on supercomputing, networking, and technology
development, etc.  Gordon Bell is the chairman of the subcommittee on
networking.  He recently wrote an article [with an unfortunate
derogatory leading remark on BU networking!] in the February issue of
IEEE Spectrum about the need for a new national research and education
network.  He proposes a series of steps upgrading the internet,
leading eventually to a T3 link to every major university and research
center.  He discusses some costs associated with upgrading to T1, but
says nothing about the cost of T3, which may be appropriate given the
lead time to deployment, except to say that the institutions served
should pay (telephone analogy).  I wonder if this is reasonable?
	Paying for T3 would be dear compared to paying for today's
services.  I think the telephone companies rates, based on message
units and not cost-to-provide, are probably too high.
	Bell says it's up to us to take the lead since our government
probably won't.  Anybody want AT&T to provide T3 service for a new
super-internet?  Anybody up to building our own private network?  The
providers of supercomputer services (like, but not necessarily,
Boeing) already have complained about unfair competition from the NSF
supercomputer centers.  Wonder what the telecommunications vendors
will say when someone puts Bell's proposal before the Congress, if
ever?
	Oh, well, I think I'll get our network users used to paying
for service now on a recurring basis.  Soften them up for the $5k to
$30k per month the super-internet will cost.  :-)
	As Bell says, technology is not the issue.  We can build T3
networks and we can build super-routers and we can fix TCP {VJ can,
anyway}...  The problem is figuring out how to do it cooperatively.

	Kent England
	Boston University (which does have the networks the Medical
	Center doesn't have. [read the article])

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21 Mar 88 21:06:57 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>, Jack Haverty <HAVERTY@CCV.BBN.COM>, Vint Cerf <CERF@A.ISI.EDU>
Subject:   Re: Rumors about the death of the ARPANET

Jack, Vint, and friends,

By trusting the local I/O channel I had in mind just the transfer of
data from the hosts main storage to the protocol processor. For example,
the Block Multiplexer channel on an IBM mainframe provides a guaranteed
transfer - if the application issues a write to the channel, the final status
of the operation indicates success or failure. Also, the channel will transfer
data intact, or reports an error to the application. There is little need
(other than paranoia?) to provide an application level checksum on the
transferred data, or a high level ack mechanism across the channel.

End to End checksums, acks, etc are needed. Nolo Contendre. But they
can be between intelligent control units.

(This whole argument also assumes that the protocol processor has a
reasonably powerful CPU and amount of memory - imagine a IBM 3090
dumping data into a 8 Mhz 68000 with 512 Kb of memory!!! :-)

Frank
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 16:23:54 GMT
From:      PETTY@MITVMA.MIT.EDU (Jim Petty)
To:        comp.protocols.tcp-ip
Subject:   GATE-D

If anyone out there knows who to contact about the GATE-D gateway
software please drop me a note.  I believe it was written at
Cornell.

Thanks in advance

Jim

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 17:01:26 GMT
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

Vint/Frank - my recollection of some of the conflagrations around
checksumming is that the end-end checksum is valuable even if the
piecewise error control is perfect (10 to however many you like);
what the end-end often catches are plain and simple bugs deep down
in the middle of the path, e.g., a pointer off-by-one in a packet
switch buffer under some obscure condition and the like.  Since
software is never debugged fully until you retire it, such situations
will crop up, and according to Murphy will happen at the worst time.
What would be interesting is to see if there is a way to design
a simple end-end "checksum" designed to catch errors which are not
like those in communications media, i.e., result from bugs, configuration
mistakes, etc., rather than line noise and the like.
Jack

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 18:43:00 GMT
From:      Houde@HIS-PHOENIX-MULTICS.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Sun servers

Sorry, but I never specified my address.  I wanted to know whether or not I
could use a standard Unix box as a server for Sun workstations.  Please direct
any responses to Houde at PCO-MULTICS.ARPA.

Thanks again,

          Mike Houde

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 19:14:04 GMT
From:      tsudik@MALIBU.USC.EDU (Gene Tsudik)
To:        comp.protocols.tcp-ip
Subject:   Re:  LSRR and RR IP options


Yes, your fix for the fragmentation/options problem worked very well and
was easy to inject into IP code. Thank you very much.

Gene Tsudik
Networks and Distributed Systems Lab
USC

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 19:17:00 GMT
From:      jerry@twg.COM ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   RE: offloading the protocols

Frank,
	That is not the way that data flows inside the Wollongong
software at all.  The same style used by 4.3BSD is the case here.
First data is sent from the user into the kernel where it is placed
into network buffers call mbufs.  Mbufs can and are chained to
build packets (IP headers, TCP headers, data, etc).  The mbuf
chains are passed between protocols, thus no data is moved at all
just the pointers to the data.  Plus once the data is in the
kernel, it never has to take a hop back to an application for
any further processing.

	We are well aware of the overhead of moving data between
the kernel level and user level, that is why we have done
considerable work in preventing this from happening (eg. Telnet
server is kernel resident, sharing DEC ethernet controllers
using ALTSTART interface).  We have also been eagerly tracking
the good work by Van Jacobson and Mike Karels in the TCP area.
Our implementation allows us to use there public domain code
without modification.

	I do agree with your assessment of the on-board TCP
solutions.  The overhead in the host must be minimal.  Data
must be moved from the user into a DMA area where the smart
controller can access it.  You must trust the data integrity
between the host and the controller performing the network
functions.  Now if you can get Van's and Mike's code down
onto these controllers...

Jerry

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 20:29:19 GMT
From:      jeremy@swatsun.uucp (Jeremy Brest)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Information request: DECnet, tcp/ip

I am interested in connecting a bunch of MicroVAXen running DECnet
to a tcp/ip network.  Any information about this would be appreciated.
In particular, I am interested in people's experiences with the CMU
software v. Wollongong (sp?).  Also, if anyone knows an address for 
information about the CMU software, please send it.  Please send by
mail unless you think your reply of general interest.

Thank you, 

Jeremy Brest
Swarthmore College
uucp:  ...seismo!bpa!swatsun!jeremy
CSnet: jeremy@swatsun.swarthmore.edu
ARPA:  jeremy%swatsun.swarthmore.edu@relay.cs.net

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 20:40:00 GMT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Keep-alives, also push bit

This seems to come up once a year.  When I was implementing the
Symbolics TCP implementation some 3 or 4 years ago, I asked about active
connection sensing.  The UNANIMOUS answer I got were that such things
were 100% against the spec.  Therefore, BSD is in error.
[Philosophically, sending a garbage byte is disgusting.]  What IS
allowed, as far as I know, is to send a zero length IN ORDER TO ELICIT A
RESET if the connection absolutely doesn't exist.  This is what we do.
Yes, it will cause packet traffic.  If the link or remote host is down,
the connection will not go away until active data is sent or the host
comes up and IT declares that the connection doesn't exist.

This will surely come up again in 10 to 14 months...

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 20:47:44 GMT
From:      MAB@CORNELLC.CCS.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Conversion to ISO - Number of NCP Hosts

Network World, in their March 14 issue, published an article about GOSIP,
and the conversion from TCP/IP to ISO protocols.  In brief, they say that
ISO OSI is in the process of becoming a government standard, supplanting
TCP/IP, but that the conversion may take a very long time.  At the end of
the article, they give an analogy to the conversion from NCP to TCP, from
Kevin Ebel of DCA, and say, in effect, that the difference between the
two conversions is only one of scale.

Let's assume, for the purpose of non-argument, that the analogy is apt.
(I don't think it is.)  Does anyone know what the difference in scale is,
between these two conversions?   How many NCP hosts and routers/gateways/
imps were there at the time of conversion to TCP?  And how many TCP hosts
and routers/gateways/imps are there now and/or will there be two years
from now (assuming that to be the time of the beginning of the TCP->OSI
conversion)?

Mark Bodenstein    (mab@cornellc.ccs.cornell.edu)
Cornell University

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 88 23:04:22 GMT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  Ping, checksum algorithm?

Ping.c as found in Berkeley Unix was originally written by
Mike Muuss at the U.S.Army Ballistic Research Laboratory
<mike@brl.arpa>.  It is public domain distribution unlimited.
Berkeley made some modifications to it but maintained its
public domain status.

Recently we at BRL modified it to do RECORD_ROUTE, provide
more detailed ICMP messages (read subcodes), dump the fields
of returned IP headers in ICMP messages, etc.  Our version
does not yet do LSRR or SSRR (though since I heard that the
core gateways honor it, it will almost certainly be added).
[Note: record route can not be done on a SunOS <= 3.4 since
the IP_OPTIONS socket option does not exist - the rest of
the code works fine on the Sun however.]

Anticipating a possible high demand, I have made the source
code publicly FTP'able from VGR.BRL.MIL [192.5.23.5 or
128.63.4.4] in pub/ping.tar.  Man page included.

- Phil
<phil@brl.arpa>

ps: warning - our main gateway was having hardware problems today.

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 02:06:57 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET


Jack, Vint, and friends,

By trusting the local I/O channel I had in mind just the transfer of
data from the hosts main storage to the protocol processor. For example,
the Block Multiplexer channel on an IBM mainframe provides a guaranteed
transfer - if the application issues a write to the channel, the final status
of the operation indicates success or failure. Also, the channel will transfer
data intact, or reports an error to the application. There is little need
(other than paranoia?) to provide an application level checksum on the
transferred data, or a high level ack mechanism across the channel.

End to End checksums, acks, etc are needed. Nolo Contendre. But they
can be between intelligent control units.

(This whole argument also assumes that the protocol processor has a
reasonably powerful CPU and amount of memory - imagine a IBM 3090
dumping data into a 8 Mhz 68000 with 512 Kb of memory!!! :-)

Frank

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 14:06:00 PST
From:      "Jerry Scott" <jerry@twg.com>
To:        "chris" <chris@gyre.umd.edu>
Cc:        <kasten@mitvma.mit.edu>,<tcp-ip@sri-nic.arpa>
Subject:   RE: offloading the protocols
Chris,
	Agreed, the cpu on the board will definitely come
into play in terms of performance.  We see that here at
TWG when our host resident software is compared against
on-board software on VAX 86xx or 88xx hardware.  The host
resident runs circles around the on-board in these cases.

	I think the Jacobson/Karels code has more to offer
than blazing performance.  The code that I am distributing
does not yet have the performance hooks that Van explained
in some of his mail messages.  But it does have improved
congestion control that allows my connections to adapt to
line speeds during the life of the connection rather than
at the beginning.  Not only does this code save the net
the overhead of unnecessary retransmissions, but prevents
timeouts of connections as well.  The big improvement I
have seen is with Arpanet mail.  It used to be the case that
I would try to send mail to another host, make the connection,
and then lose the connection because of timeouts before the
mail could be transferred.  Now, even at peak packet times,
mail delivery is reliable.


Jerry

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 06:16:34 GMT
From:      chris@gyre.umd.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   RE: offloading the protocols

On the other hand, putting the Jacobson/Karels TCP into the
board may produce something significantly slower than what you
get when you run the protocol on a Sun-3.

Even if the interface is right.

Even if you have a good DMA path.

No matter how low the overhead is.

The problem, you see, is that the Sun-3 CPU may be significantly
faster than the one on your protocol card.  That 68020 runs rings
around the 80x8x in some of those external protocol boards.  The
latest Ethernet chips from Intel and AMD are fast, but they are
not CPUs.  There may be some protocol boards that use fast hardware
---if they do not exist now they probably will soon---but I have
never seen one myself.

Chris

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 12:00:00 CDT
From:      "HRL780::DN06" <longra@bafb-ddnvax.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   deletion from mailing list
From:	DDNVAX::SYSTEM       21-MAR-1988 16:28
To:	LONGRA
Subj:	Undeliverable mail

 ----Reason for mail failure follows----
Sending mail to host sri-nic.arpa :
  Fatal reply code to command 'RCPT TO:<tcp-ip-requests@sri-nic.arpa>':
  550 No such local mailbox as "tcp-ip-requests", recipient rejected


 ----Partial transcript of message follows----
Date: 21 Mar 88 16:09:00 CDT
From: "Rick A Long" <longra@bafb-ddnvax.arpa>
Subject: mailing list
To: "tcp-ip-requests" <tcp-ip-requests@sri-nic.arpa>
cc: longra      
Reply-To: "Rick A Long" <longra@bafb-ddnvax.arpa>

Please remove me from your mailing list.

Rick Long
------
------
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Mar 88 15:39:04 -0500
From:      haverty@CCV.BBN.COM
To:        braden@VENERA.ISI.EDU
Cc:        haverty@CCV.BBN.COM, tcp-ip@SRI-NIC.ARPA, haverty@CCV.BBN.COM
Subject:   Re: Rumors about the death of the ARPANET
Hi Bob,

Yes, good observation.  Actually it's not so much the weakness of the
TCP algorithm, it's the fact that so much has to remain intact for the
bad packet to make it to the destination at all to be checksummed!

The other thing to note is that error-correcting codes are related to
checksumming and to fault isolation - they detect, isolate the cause,
and repair all at the same time (but they DON'T usually report the
event to someone who might, for example, dispatch service to fix a
flaky component.  

Here's part of an exchange from Vint commenting on checksums that
would have a bit that is set for 'pointer-off', and another for
'count-off-by-one', etc. that you might find interesting:

Vint - You've touched on an interesting point.  Right now, checksums
are almost alway binary, i.e., the data is either intact to some high
probability, or it's bad in some undefined way.  Thus checksums become
good fault detection tools, but lousy fault isolation tools.  If we
could design a checksum algorithm that produced more than a yes/no
output, it could be a useful network management tool; e.g., even if it
could differentiate between a single-bit error in a packet, which
might be a 'normal' behavior of certain lines, and a totally clobbered
packet, e.g., all bytes zeroed, which might indicate a major hardware
or software failure, it would be very useful.  The former would be
ignored unless it happens a lot; the latter could trigger alarms,
memory snapshots, datascope traces, etc.
             
Of course the ultimate such algorithm would set bit 1 for off-by-one,
bit 2 for pointer problem, etc.  It may sound crazy, but I think it's
not so farfetched.  From lots of hours looking over people's shoulders
as they debug problems (and doing it myself), the key principle is to
look for something 'unusual' in the behavior.  If that test could be
converted into an AI-ish algorithm, it could become part of the 
network technology itself.  Deja vu - we talked about this kind ofd
thing when getting the original Automated Network Managemet prmoject
off the ground.  Maybe we should get the academic community to try to
invent a new branch of science and engineering focussed around 'checksums'?

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 14:15:44 GMT
From:      thompson@dalcs.UUCP (Michael A. Thompson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: ARP hardware field

In article <135@ftp.COM> nancy@ftp.COM (Nancy Connor) writes:
>I don't believe that this is true.  I know that Proteon uses a
>different set of codes from the Ethernet list I sent out a while ago.

	Does this make Proteon non-standard? I was quoting from rfc1010, and I
must admit some confusion over the status of rfc's, I know that rfc stands for
Request For Comment, but everyone seems to treat them as standards, so what
are they? Standards or Drafts of proposed standards, and if they are drafts
what are the final standards (if any exist) called?
-- 
Michael A. Thompson, Dept. Math, Stats, & C.S., Dalhousie U., Halifax, N.S.
thompson@dalcs.uucp	From Bitnet or Uucp
thompson@cs.dal.cdn	From Bitnet or Cdn
thompson%dalcs.uucp@uunet.uu.net From Arpa

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 1988 20:04 EST
From:      Charles Jerian <cpj@citi.umich.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   brl ping
The brl ping only records 6 routes and the documentation says
that  only 6 will fit into the ip header, however the one I wrote last year
has 9 routes
brl's gives
./ping -R umda.umd.edu
PING umda.umd.edu (128.8.10.10): 56 data bytes
64 bytes from 128.8.10.10: icmp_seq=1 time=1880 ms
citi->cntr (35.1.17.2)
cntr.pgw (35.1.1.12)
umich->cleveland (128.182.18.2)
cleveland->psc (128.182.16.2)
psc->sura (128.167.31.2)
sura->umdbogon (128.167.1.3)
while mine gives
 /etc/ping -r umda.umd.edu
options 7==7(RR) 39 40
citi->cntr
cntr.pgw
umich->cleveland
cleveland->psc
psc->sura
sura->umdbogon
129.2.1.5
bogon-gw.umd.edu
terp.umd.edu
umda.umd.edu is alive
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 16:33:00 GMT
From:      Dickson@HIS-PHOENIX-MULTICS.ARPA (Paul Dickson)
To:        comp.protocols.tcp-ip
Subject:   Re: Sun servers

PCO-MULTICS.ARPA isn't currently on the Internet. All responses to that
address should be sent to "user-name%pco @ BCO-Multics.ARPA".


          -Paul Dickson
            Dickson%pco @ BCO-Multics.ARPA

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 17:00:00 GMT
From:      longra@BAFB-DDNVAX.ARPA ("HRL780::DN06")
To:        comp.protocols.tcp-ip
Subject:   deletion from mailing list

From:	DDNVAX::SYSTEM       21-MAR-1988 16:28
To:	LONGRA
Subj:	Undeliverable mail

 ----Reason for mail failure follows----
Sending mail to host sri-nic.arpa :
  Fatal reply code to command 'RCPT TO:<tcp-ip-requests@sri-nic.arpa>':
  550 No such local mailbox as "tcp-ip-requests", recipient rejected


 ----Partial transcript of message follows----
Date: 21 Mar 88 16:09:00 CDT
From: "Rick A Long" <longra@bafb-ddnvax.arpa>
Subject: mailing list
To: "tcp-ip-requests" <tcp-ip-requests@sri-nic.arpa>
cc: longra      
Reply-To: "Rick A Long" <longra@bafb-ddnvax.arpa>

Please remove me from your mailing list.

Rick Long
------
------

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 17:20:36 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET


	What would be interesting is to see if there is a way to design
	a simple end-end "checksum" designed to catch errors which are not
	like those in communications media, i.e., result from bugs, configuration
	mistakes, etc., rather than line noise and the like.
	Jack
	
Actually, Jack, I think that is what you (as part of the TCP WG) did.
The TCP checksum is probably too weak for communications media, but it
DOES, as you point out, catch subtle host software errors!

Bob Braden

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 17:54:58 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: GATE-D

Jim,

A person to contact regarding "gated" is

	Mark Fedor <fedor@NISC.NYSER.NET>

--Annette

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 20:20:04 GMT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: Conversion to ISO - Number of NCP Hosts

You know, NCP is still alive and well in certain sheltered parts of
the world.

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 20:20:24 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Conversion to ISO - Number of NCP Hosts


    Does anyone know what the difference in scale is, between these
    two conversions?  How many NCP hosts and routers/gateways/ imps
    were there at the time of conversion to TCP?  And how many TCP
    hosts and routers/gateways/imps are there now and/or will there
    be two years from now (assuming that to be the time of the
    beginning of the TCP->OSI conversion)?

I still have an "I Survived the TCP Transition" button somewhere, so
Ill take a shot at this...

The conversion from NCP to TCP took place on 1-Jan-1983.  It was about
6 months after that that most hosts could communicate with each other.
As of the cut-over data, most vendor software wasn't quite ready...

My March, 1982 Arpanet directory shows 96 imps, and about 300 hosts.
(And there were more DEC-20s than there were vaxen.)
NCP didn't incorporate ideas like "routers" or "internet".  There was
just the ARPAnet.  If you had a local area network, it was probably a
Xerox "experimental" 3Mb ethernet, and it probably spoke PUP protocols.

The current NIC host table has 854 Networks, 456 gateways (routers),
and 5719 hosts in it.  This, of course, does not include isolated
places that have set up IP networks without being assigned network
numbers by the NIC.  It probably does not include gateways that aren't
involved with talking to the arpanet.  It does not include subnet
gateways used within an autonomous system.  It does not include hosts
whose names are only obtainable only via the domain system.  I think
current estimates are that one new network is added to the Internet
every working day (eg 250/year).

Hopefully, there will be a several year period during which ISO
protocols and TCP/IP will co-exist, and eventually, one of them will
become unused.

Bill Westfield
cisco Systems.
-------

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 20:39:04 GMT
From:      haverty@CCV.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

Hi Bob,

Yes, good observation.  Actually it's not so much the weakness of the
TCP algorithm, it's the fact that so much has to remain intact for the
bad packet to make it to the destination at all to be checksummed!

The other thing to note is that error-correcting codes are related to
checksumming and to fault isolation - they detect, isolate the cause,
and repair all at the same time (but they DON'T usually report the
event to someone who might, for example, dispatch service to fix a
flaky component.  

Here's part of an exchange from Vint commenting on checksums that
would have a bit that is set for 'pointer-off', and another for
'count-off-by-one', etc. that you might find interesting:

Vint - You've touched on an interesting point.  Right now, checksums
are almost alway binary, i.e., the data is either intact to some high
probability, or it's bad in some undefined way.  Thus checksums become
good fault detection tools, but lousy fault isolation tools.  If we
could design a checksum algorithm that produced more than a yes/no
output, it could be a useful network management tool; e.g., even if it
could differentiate between a single-bit error in a packet, which
might be a 'normal' behavior of certain lines, and a totally clobbered
packet, e.g., all bytes zeroed, which might indicate a major hardware
or software failure, it would be very useful.  The former would be
ignored unless it happens a lot; the latter could trigger alarms,
memory snapshots, datascope traces, etc.
             
Of course the ultimate such algorithm would set bit 1 for off-by-one,
bit 2 for pointer problem, etc.  It may sound crazy, but I think it's
not so farfetched.  From lots of hours looking over people's shoulders
as they debug problems (and doing it myself), the key principle is to
look for something 'unusual' in the behavior.  If that test could be
converted into an AI-ish algorithm, it could become part of the 
network technology itself.  Deja vu - we talked about this kind ofd
thing when getting the original Automated Network Managemet prmoject
off the ground.  Maybe we should get the academic community to try to
invent a new branch of science and engineering focussed around 'checksums'?

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 22:06:00 GMT
From:      jerry@TWG.COM ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   RE: offloading the protocols

Chris,
	Agreed, the cpu on the board will definitely come
into play in terms of performance.  We see that here at
TWG when our host resident software is compared against
on-board software on VAX 86xx or 88xx hardware.  The host
resident runs circles around the on-board in these cases.

	I think the Jacobson/Karels code has more to offer
than blazing performance.  The code that I am distributing
does not yet have the performance hooks that Van explained
in some of his mail messages.  But it does have improved
congestion control that allows my connections to adapt to
line speeds during the life of the connection rather than
at the beginning.  Not only does this code save the net
the overhead of unnecessary retransmissions, but prevents
timeouts of connections as well.  The big improvement I
have seen is with Arpanet mail.  It used to be the case that
I would try to send mail to another host, make the connection,
and then lose the connection because of timeouts before the
mail could be transferred.  Now, even at peak packet times,
mail delivery is reliable.


Jerry

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 88 22:15:39 GMT
From:      jeff@tc.fluke.COM (Jeff Stearns)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: ethernet monitor needed?

In article <3447@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes
about his search for Ethernet test gear.

I'll put in a plug for the Cabletron LAN-MD.  It's a suitcase-sized box that
can thoroughly test cables and transceivers.  A pair of LAN-MD's can exercise
transceivers in place and tell you things that you'll never otherwise know.

Which of your transceivers have broken or out-of-spec collision detect
circuitry?  How will you find them?  Hint: Can a computer tell if its
transceiver has this problem?

Now that we're in the age of level I vs level II vs 802.3, we have abundant
opportunities to pair up Ethernet controllers with the wrong kind of
transceiver, multiplexor, or cable.  Physical and link-level problems like
this are often inscrutable to higher-level tools.

Imagine a chart of the ISO reference model.  Stick a pushpin in it for every
Ethernet problem you've had.  Here's a starter drawn from recent memory:
    Controllers that don't conform to the Ethernet spec, wrong cable type for
    transceiver level, out-of-spec transceivers, defective transceivers,
    broken Ethernet controllers, buggy controllers, buggy device drivers,
    improperly-installed vampire taps, noise-sensitive transceivers, loose
    transceiver cables, bugs in TCP/IP, NFS, ND, and ftp.

That puts a lot of pins down at the bottom of the chart, below the level of
monitors and protocol analyzers.  The LAN-MD works well down there.
I wouldn't be surprised if Cabletron were working on something newer than
the LAN-MD; you might also want to ask 'em that.
-- 
		 Jeff Stearns
	 Domain: jeff@tc.fluke.COM
	  Voice: +1 206 356 5064
    If you must: {uw-beaver,microsoft,sun}!fluke!jeff
	   USPS: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA  98206

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 01:03:47 GMT
From:      gordan@maccs.UUCP (gordan)
To:        comp.protocols.tcp-ip
Subject:   Checksums (was Re: Ping, checksum algorithm?)

In article <123@heart-of-gold> jc@heart-of-gold (John M Chambers x7780 1E342) writes:
-Does anyone have a PD version of ping?  How about a C-coded routine that
-does the IP checksum calculation?  We have one that is written in VAX
-assembly language, which is OK for a VAX, but it doesn't work too well
-on a 68020....


--------------------------------------------------------------------------
  -- One's complement of the one's complement sum checksum in TCP/IP --


In the RFC documents, the "one's complement of the one's complement sum"
checksums are mentioned in a single paragraph, and are never even
described, an omission that seems incredible.

Although the algorithm must be well known to many people, a written
description seems to be lacking.  So here's an attempt to provide a
short description (with examples).  The only authority I can cite for
the following is myself (but it seems to work, judging from actual
TCP/IP packets).  Someone kindly let me know if this is horribly wrong.


Basically, IP, TCP, and UDP require doing one's complement sums of
16-bit words.  That is, you must take a bunch of 16-bit words and sum
them (ignoring overflows) _as if their bit patterns represented one's
complement numbers_.  The trick, then, is doing one's complement
arithmetic on a two's complement machine.

Without going into any arithmetical justification, here's how to do a
one's complement sum on a two's complement machine, in pseudocode:

  INT16 sum;
  INT16 *word;     /* pointer to start of 16-bit words to be summed */

  sum = 0;

  for (i = 0; i < `number of 16-bit words to be summed'; i++)
  {
    `byte-swap word[i], if necessary (see comment on byte-order)'
    sum += word[i];   /* do NOT combine these two lines ... */
    sum += `CARRY';   /* ... into sum += word[i] + CARRY !!!! */
  }

where CARRY is the value of the hardware carry bit (0 or 1), as set by
the addition in the previous line (note you mustn't do sum += word[i] +
CARRY as one line, since a high-level language could rearrange the order
of addition and add the value of the carry bit before it was set).

Of course, the value of the carry bit is not accessible from a
higher-level language like C.  A perfectly equivalent method (very
suitable if your machine has 32-bit integers) is:

  INT32 sum32, word32
  INT16 *word;     /* pointer to start of 16-bit words to be summed */

  sum32 = 0;

  for (i = 0; i < `number of 16-bit words to be summed'; i++)
  {
    `byte-swap word[i], if necessary (see comments on byte-order)'
    `copy word[i] to word32, zero-extended (NOT sign-extended)'
              /* (e.g., 0xedcb -> 0x0000edcb, not 0xffffedcb) */
    sum32 += word32;
  }

  sum = `add the two 16-bit halves of sum32 to each other'

This works, since the carry bit values for 16-bit addition of the least
significant 16-bit word accumulate in the most significant 16-bit word
of the 32-bit sum.  (This is probably what you would use on a 68020 --
and you can forget about byte-swapping on a 68020 as well).

After calculating a one's complement sum, you have to take its one's
complement (invert all the bits) to get the actual checksum used in IP,
TCP, and UDP (but note that UDP treats a calculated checksum of 0x0000
as a special case -- see the RFC).


It is of course necessary to take byte-order into account.

  (Byte-order:  if adjacent memory locations on a machine contain the
  following bytes:

  X   :       0x12
  X+1 :       0x34

  then what is the value of the 16-bit word whose address is X?
  (assuming a byte-addressable machine and valid alignment for X to be
  read as a 16-bit value).

  If the 16-bit value is 0x1234, the machine is said to be
  ``big-endian;'' if it is 0x3412, the machine is ``little-endian.''

Some machine architectures (Motorola 680x0, etc.) are big-endian, others
(Intel 80x86, VAX) are little-endian.  TCP/IP headers use big-endian
byte-order.  Thus, life is easier on a Sun than on a VAX.


Some examples follow, using actual packets (see the appropriate RFC docs
for IP, UDP, and TCP, and ignore the Ethernet stuff).  In case anyone's
curious, the IP addresses here are used on a LAN unconnected to any
outside network (they do not respect the class A/B/C Internet naming
scheme).


     An Ethernet UDP/IP packet
---------------------------------------------------
1:  ff-ff-ff-ff-ff-ff 02-60-8c-09-58-97 08-00      
2:                                            45 00
3:  00-24 00-01 00-00 ff 11 61-31 01-00-58-97 01-00-
4: -00-00                                          
5:        09-46 00-2a 00-10 c9-ca                  
6:                                01 06 4a 48 45 56
7:  41 58                                          
8:        00 00 00 00 00 00 00 00 00 00            
---------------------------------------------------
Line  1:    Ethernet header
Lines 2-8:  Ethernet data

Lines 2-4:  IP header
Lines 5-7:  IP data

Line  5:    UDP header
Lines 6-7:  UDP data

Line  8:    Garbage padding to satisfy Ethernet minimum packet size
            (Ethernet header + data >= 60 bytes).
---------------------------------------------------


    An Ethernet TCP/IP packet
----------------------------------------------------
1:  08-00-2b-02-d2-67 08-00-02-00-51-23 08-00 
2:                                            45 00
3:  00-4b 44-46 00-00 1e 06 56-3a 01-00-00-0b 01-00-
4: -00-23 
5:        00-17 07-a8 06-14-56-f0 d3-1d-aa-a4 50 18
6:  00-68 b1-d0 00-00 
7:                    0d 0a 0d 0a 4d 63 4d 61 73 74
8:  65 72 20 55 6e 69 76 65 72 73 69 74 79 20 56 41
9:  58 20 38 36 30 30 0d 0a 0d 
10:                            00
---------------------------------------------------
Line  1:    Ethernet header
Lines 2-10: Ethernet data

Lines 2-4:  IP header
Lines 5-9:  IP data

Lines 5-6:  TCP header
Lines 7-9:  TCP data

Line  10:   Garbage Ethernet padding (to send an even number of bytes)
----------------------------------------------------


In the first packet, the IP Checksum field is 0x6131 (in the middle of
line 3).  The IP checksum is calculated over all 16-bit words in the
header (except the checksum field itself is taken to be zero, prior to
actually calculating it).  Thus the 16-bit words that go into
calculating the IP checksum are (from lines 2,3,4): 0x4500, 0x0024,
0x0001, 0x0000, 0xff11, 0x0000, 0x0100, 0x5897, 0x0100, 0x0000.

The 32-bit sum of zero-extended words is 0x 0001 9ecd, so the one's
complement sum is 0x9ece.  The one's complement of this is the checksum,
0x6131.

The UDP Checksum field in the same packet is 0xc9ca (at the end of line
5).  Unlike IP, the UDP checksum is calculated not only over the UDP
header, but also over the UDP data, and over a pseudo-header consisting
of the IP source and destination addresses, the IP Protocol field
zero-extended to 16-bits, and a UDP length word.  Again the checksum
field itself is taken to be zero during the actual calculation, since we
can't know its value before actually computing it.

Thus the 16-bit words that go into calculating the UDP checksum are
(from lines 5,6,7): 0x0946, 0x002a, 0x0010, 0x0000, 0x0106, 0x4a48,
0x4556, 0x4158; (and from the pseudo-header): 0x0100, 0x5897, 0x0100,
0x0000, 0x0011 (UDP protocol number = 0x11 or 17 decimal), and 0x0010
(the UDP length).  The 32-bit sum of zero-extended words is 0x 0001
3634, so the 16-bit one's complement sum is 0x3635 and the checksum is
0xc9ca as required.


In the second packet shown, the IP checksum is 0x563a (in the middle of
line 3).  The 16-bit words that go into calculating the IP checksum are
(from lines 2,3,4):  0x4500, 0x004b, 0x4446, 0x0000, 0x1e06, 0x0000,
0x0100, 0x000b, 0x0100, 0x0023.

The 32-bit sum of zero-extended words is 0x 0000 a9c5, so the one's
complement sum is 0xa9c5.  The one's complement of this is the checksum,
0x563a.

The TCP Checksum field in the same packet is 0xb1d0 (the second word in
line 6).  Just as for UDP, the TCP checksum is calculated over all 16-bit
words in the TCP header, data, and pseudo-header.  The 16-bit words that
go into calculating the checksum are:

     From the TCP header:

0x0017, 0x07a8, 0x0614, 0x56f0, 0xd31d, 0xaaa4,
0x5018, 0x0068, 0x0000 (checksum field itself is initially zero),
0x0000.

     From the TCP data:

0x0d0a, 0x0d0a, 0x4d63, 0x4d61, 0x7374, 0x6572,
0x2055, 0x6e69, 0x7665, 0x7273, 0x6974, 0x7920, 0x5641, 0x5820,
0x3836, 0x3030, 0x0d0a, 0x0d00 (we have an odd number of data bytes,
so the last byte is zero-filled on the right to form a 16-bit word).

     From the pseudo-header:

0x0100, 0x000b (from the source IP address),
0x0100, 0x0023 (from the destination IP address),
0x0006 (zero-extended IP Protocol word, 0x6 = TCP),
0x0037 (the TCP Length, i.e. the length of the TCP header and data).

Here, the 32-bit sum of zero-extended words is 0x 0007 4e28, so the
16-bit one's complement sum is 0x4e2f and the checksum is 0xb1d0, as
required.


Note the TCP length must be calculated as the total IP Length (0x4b in
this case) minus the length of the IP header (5 32-bit words in this
case, or 0x14 (decimal 20) bytes).  The TCP header itself does not store
the number of bytes of TCP data, so the TCP layer relies on the IP layer
to supply it with this information.


This describes how the sender of a packet calculates the checksum.  The
receiver, on the other hand, can verify the checksum quickly in the
following manner: it simply one's complement sums the 16-bit words and
checks if the result is 0xffff (except UDP's special case behavior must
again be taken into account) -- if it is, the checksum is correct and
the packet data is valid.

A moment's thought should show why this works.  Recall that when the
sender calculated the checksum, the checksum field itself was zero; when
the receiver looks at the header, however, the field has been filled in.
The checksum is the one's complement of the one's complement sum, and
whenever a number and its one's complement are added together, the
result is 0xffff.


-- 
Many Americans work side by side with space
aliens who look human -- but you can spot
these visitors by looking for certain               Gordan Palameta
tip-offs, say experts.                              mnetor!maccs!gordan

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 01:04:00 GMT
From:      cpj@CITI.UMICH.EDU (Charles Jerian)
To:        comp.protocols.tcp-ip
Subject:   brl ping

The brl ping only records 6 routes and the documentation says
that  only 6 will fit into the ip header, however the one I wrote last year
has 9 routes
brl's gives
./ping -R umda.umd.edu
PING umda.umd.edu (128.8.10.10): 56 data bytes
64 bytes from 128.8.10.10: icmp_seq=1 time=1880 ms
citi->cntr (35.1.17.2)
cntr.pgw (35.1.1.12)
umich->cleveland (128.182.18.2)
cleveland->psc (128.182.16.2)
psc->sura (128.167.31.2)
sura->umdbogon (128.167.1.3)
while mine gives
 /etc/ping -r umda.umd.edu
options 7==7(RR) 39 40
citi->cntr
cntr.pgw
umich->cleveland
cleveland->psc
psc->sura
sura->umdbogon
129.2.1.5
bogon-gw.umd.edu
terp.umd.edu
umda.umd.edu is alive

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 09:12:00 PST
From:      Dave Crocker <dcrocker@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   on-/off-board protocol processing
As with most technical choices, each alternative has its appropriate uses.

The concern about reliability of processing, expressed by Vint, seems not
to apply to many of the current "intelligent-board" solutions.  Their 
interface to the host is essentially -- often exactly -- like accessing
standard primary memory.  So, if you don't trust your primary memory,
you probably have more serious architectural fish to fry that where you
put your protocol processing.  When the interface is more channel-oriented,
then reliability becomes factor.  That is, if you need a serious protocol,
to access your protocols, there is a reasonable chance that the access
protocol has bugs, so that you have a step in the networking chain
truly exposed to problems, and not detectable by the end-to-end
safety mechanism of the transport protocol.

On the other hand,

There is some interesting mythology about the benefits of moving your
protocols to an intelligent board.  Having a slow board and a fast
host has become a very significant issue, as discussed in some
messages, already.  My only comment is that when making a choice, you
should pay close attention to this issue.

Less well-understood are some beliefs that the intelligent board
makes the host less complex and relieves the host of substantial
overhead.  This is true only sometimes.  The only factor that is
always nicer about intelligent boards is that they do the checksum
calculation.

On the other hand,

They significantly increase the cost of networking hardware.  They
tend to limit the number of virtual circuits that you can have, due to
memory limitations on the board -- a factor that is becoming less of
a problem, with 512K and 1M boards.  They tend to make multiple-interface
configurations a problem, since you then have to add complexity to the
host, anyhow, to coordinate the cards.

That is, when you move the protocols to the board, then multiple
boards become multiple protocol implementations.  Coordinating IP
routing, UDP and TCP Port number allocation, etc, becomes a real
hassle.  Worse, customers seem to be inclined to try to do this
with implementations from different vendors(!)

The idea that intelligent boards reduce interrupt overhead sounds
appealing, but often does not prove out.  Most incoming packets
have their data handed immediately to the receiving application, so
that the network interrupt, caused when the packet arrives, still
causes the o/s device driver -- yup, you still need such a beast when
you have intelligent boards -- to interrupt and you still have the
kernel/user context switch.  In the case of heavy traffic with
small packets, the intelligent board does have an edge.  Otherwise,
the host-based solution seems to be a much more efficient use of
resources.

Now, suppose that you have a host that is tending towards saturation and
you believe that the extra processing on the board will relieve the
problem.  At one level of analysis, you would be correct. 

On the other hand,

It is a very short-sighted way to solve a system congestion problem.  If
your host has a problem at that level, you probably have only bought yourself
relief for a short time.  In all likelihood, you need to get yourself
another host.  

Given that most machines are in the micro-computer and small-minicomputer
range, this expense is not necessarily onerous.

Now, about the idea of having a non-networking-oriented access
model for the software, such as the view of fitting the network in
as a portion of a process's address space, so that the software need
not be aware of networking; it simply thinks that it is doing memory
transfers, and the underlying hardware/software handle the rest...

For general, "distributed processing" types of activities, this
will, no doubt, prove very, very useful.  In essence, it is the
natural evolution down the path that includes the remote procedure
call model, since you are integrating networking into increasingly
"natural" computing models.

This, also, is its problem.  While it often is very nice to hide
networking issues, it often is necessary to manipulate them directly.
Allowing a program to ignore the issues is great.  Preventing it from
paying attention is terrible.


-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 10:02:48 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        wb6rqn!brian@uunet.uu.net
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Network management ...

Brian,

On the network management side of the question, here's the recommended
reading list:

    - The March Issue of IEEE Network (a special issue on network management
    protocols).  Reportedly on its way to you now, although I have yet
    to receive my copy.

    - RFCs 1021-1024 on the High-Level Entity Management System (HEMS).

    - RFC 1028 on the Simple Gateway Monitoring Protocol (SGMP). (A proposed
	revision either has been or will shortly be released as an IDEA)

    - Other work of interest is the still-in-progress work by the NETMAN
    working group of the Internet Engineering Task Force (IETF) on a
    TCP-IP version of the Common Management Information Protocol (CMIP).
    Contact the chairman of that group (Lee LaBarre, cel@mitre-bedford.arpa)
    for current drafts.

Finally -- there is an Internet mailing list on network management.  Mail
to gwmon-request@sh.cs.net to join.

Craig
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 02:15:40 GMT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: GATE-D


   Posted-Date: Tue, 22 Mar 88 09:54:58 PST
   Date: Tue, 22 Mar 88 09:54:58 PST
   From: Annette DeSchon <deschon@venera.isi.edu>

   Jim,

   A person to contact regarding "gated" is

	   Mark Fedor <fedor@NISC.NYSER.NET>

   --Annette

Actually, Annette, Mark left Cornell last year.  The prime developer
is Jeff Honig, jch@devvax.tn.cornell.edu.  The gatedaemon is supported
by the Network Systems group at the Cornell Theory Center.
							Scott

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1988 07:39-EST
From:      CERF@A.ISI.EDU
To:        MAB@CORNELLC.CCS.CORNELL.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:      Conversion to ISO - Number of NCP Hosts
I can't give firm numbers but there were on the order of 20-25 different
operating system implementations of NCP and somewhat fewer for TCP at the
time the conversion was done - some hosts never made the change and were
simply retired (good excuse...).

The NCP/TCP and TCP/ISO analogies are not exact. For one thing, NCPwas
never a commercial product. TCP is. For another, only ARPANET hosts did NCP because
that was NOT an internet protocol, so a single administration could insist on
the conversion and was even able to turn off NCP capability within the 
subnet as a forcing function. This is not possible for TCP/ISO except perhaps
at the gateways (and maybe for the subnets if packet types for ISO IP and DoD IP
are distinct, as I suppose they are likely to be).

There must be literally tens of thousands of TCP/IP hosts by now compared to
at most a couple of hundred NCP hosts in Jan 83. 

Somehow I think the analogy is not very apt.

Vint
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 1988 07:47-EST
From:      CERF@A.ISI.EDU
To:        kwe@BU-CS.BU.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Rumors about the death of the ARPANET
The FCCSET committees, the NSF, the EDUCOM Network Forum, and a number
of other individuals, groups, organizations, random parties, etc. all
are interested in seeing a high speed network emerge which could benefit
the research community and ultimately the entire business population.

Serious work is going on in industry and in the research labs on very
high speed switching capble of operating in excess of 45 Mbps. A SONET
swiitch (circuit) was demonstrated recently at 135 Mb/s; a packet
mode switching fabric is under development at Bellcore which will
operate at 100-200 Mb/s per channel (packet mode).

Cost is an important consideration and it does seem as if various
forms of subsidy will be needed in the early stages, just as the
ARPANET was subsidized fully by the R&D funding activity of DARPA.
In the longer term, though, there are services which will dmeand the
bandwidth and make it far less expensive on average. To give a
trivial example, once ISDN emerges, 64 kb/s will be the standard rate
for voice - so you get to use it for data, too, without the cost
of a modem.

This isn't to say everything will happen easily or even very quickly,
but there are enough forces in motion that I believe the will and
the therewithall to make high speed nets a reality will be available.

Vint
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 03:00:36 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Network management, routing algorithms

Can someone give me a pointer to work being done in network management
and automatic routing algorithms for the internet protocol suite?  I 
would like pointers to papers if any exist that can be readily accessed.
Thanks.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 8:55:08 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   A network you can trust

During the past few days there have been several messages about "off loading
the protocol processing" from one's processor to an outboard box.  It appears
that networking ideas are coming full circle.  In a paper presented in May
1970, Larry Roberts of ARPA wrote:

	"In this paper a computer network is defined to be a set of autonomous,
	independent computer systems, interconnected so as to permit active
	resource sharing... The goal of the computer network is for each
	computer to make every local resource available to any computer in the
        net in such a way that any program available to local users can be
	used remotely without degradation....The communication pipelines
	offered by the carriers would probably have to be a components of 
	that service but were clearly inadequate by themselves.  What was
	needed was a message service where any computer and be sure it would be
	delivered promptly and correctly...The distributed store and forward
	system was chosen, after careful study, as the ARPA Network 
	communications system."

A companion paper, by several BBN authors, provided more detail:

	"The network is thus a store and forward system and as such must
	deal with problems of routing, buffering, synchronization, error
        control, reliability, and other related issues.  To insulate the 
	computer centers from these problems, and to insulate the network
	from the problems of the computer centers, ARPA decided to place
	identical small processors at each network node, to interconnect
	these small processors with leased common-carrier circuits to form
	a subnet, and to connect each research computer center into the 
	net via the local small processor.... The subnet should function 
	as a communications system whose essential task is to transfer bits
	reliably from a source location to a specified destination.  Bit
	transmission should be sufficiently reliable and error free to 
	obviate the need for special precautions (such as storage for
	retransmission) on the part of the Hosts."

In fact, the ARPANET met these specifications so well that NCP, the original
"Layer 4" protocol used until the end of 1982, had essentially no error
checking, retransmission, etc.  The protocol processing of Hosts using NCP
was largely off-loaded, into the subnetwork's Interface Message Processor.
---

During the mid-1970's however, there arose body of opinion that subnetwork
should provide only datagram service, and that the hosts should do the protocol
processing themselves.  There were 3 primary supporting arguments for this
viewpoint:

	1)  Some bugs in the code of the ARPANET packet switches caused two 
	    or three network "lockups" in the first few years.  A datagram-
	    only network would not be subject to such events.

	2)  A packet switch which didn't do all that work would be cheaper to
	    build and maintain.

	3)  Since no network can absolutely guarantee perfect service (it was 
	    obligatory to mention the X.25 "Reset" here), any host that cares
	    about reliability will have to provide its own end-to-end 
	    reliability mechanisms.  Since all hosts will probably care about
	    reliability some time, all hosts will need to implement end-to-end
	    reliability mechanisms.  Since all Hosts have to do this, the 
            network shouldn't bother to try.

In fact, a number of the networks which became components of the Internet were
built according to this minimalist philosophy, thereby insuring that all hosts
would often have to care about reliability.

It seems to me that as we begin to work on the next generation of networks we
ought to re-examine the datagram basis of the current Internet architecture.  I
think we've thrown the baby out with the bathwater.  I believe that a carefully
designed network can provide enough reliability for almost all host needs, and
this is the best way to offload protocol processing.  It is best because it
puts the responsibility for doing it right, fixing it when it breaks, and
improving it when research produces a better way, in the hands of a single
identifiable organization.  This is far superior to having each host procuring
yet another box to go between itself and the communication network with no one
(in many cases) responsible for the care, diagnosis, repair, or improvement of
the box.

Cheers,
Alex

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 12:04:00 PST
From:      Mike Anello <mja@TWG.COM>
To:        tcp-ip <tcp-ip@sri-nic.arpa>
Subject:   RE: (TLI HELP)
In reply to Gil Widdowson note about TLI HELP:



In both socket and tli calls sockaddr_in structure is used to specify an
internet address. Since sin_zero element of this  structure does not contain
any usefull data, only the first three elements (the first 8 bytes) should
be passed to buffers used in tli calls. Two constants UDP_BINDADDRLEN in udp.h
and TCP_BINDADDRLEN in tcp.h may be used for this purpose.

When using t_bind(fd, req, ret) call, you will get back in ret.addr.buf the
address assigned by the transport provider. This address is 8 bytes long 
and represents the first three elements of sockaddr_in structure.
In t_bind(fd, NULL, &ret) call, transport provider will assign INADDR_ANY
address, and the next available port number to the end point. 


Mohsen Mortazavi
The Wollongong Group


-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 14:52:42 PST
From:      "David Cheriton" <cheriton@pescadero.stanford.edu>
To:        mckenzie@labs-n.bbn.com, tcp-ip@sri-nic.arpa
Subject:   Re:  A network you can trust
There's a major difference between the offloading my group is working on now
and what was done in the ARPAnet days, namely:  Our protocol processor
implements a reliable transport (process-to-process) service whereas
the ARPAnet did/does reliable host-to-host communication.  There is
a fundamental flaw in trying to put multiplexing on top of a reliable
communication layer because of its interaction with flow control and
error control.  Anyone who puts a host-to-host reliable protocol in
a separate comm. processor has indeed gone a full circle and deserves
all the 1970's problems that will ensue.  However, because TCP and TP 4
and VMTP are all proces-to-process, I think we are likely to see "the right
thing being used in the right way" as opposed to "the wrong way",
which is a significant step forward.
David Cheriton
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 12:02:57 est
From:      scottr@csc-lons.ARPA (Scott W. Rogers)
To:        tcp-ip@sri-nic.arpa
Subject:   Ping for Excelan (4.1C BSD) ?
Does anyone out there have, or have any information reguarding, ping
based on the EXCELAN Software (8011 or 8051) for their TCP/IP board.
It is based on the Berkeley 4.1C (yeach ...) socket library.

Please, if posiible respond directly to me, I will summarize to the Net.

			Thanks in advance,
			Scott W. Rogers  <scottr@CSC-LONS.ARPA>
			Computer Sciences Corporation
---
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 12:09:37 EST
From:      fedor@nisc.nyser.net (Mark Fedor)
To:        PETTY@mitvma.mit.edu, deschon@venera.isi.edu
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re: GATE-D
>
>Subject: Re: GATE-D 
>Date: Tue, 22 Mar 88 09:54:58 PST
>From: Annette DeSchon <deschon@venera.isi.edu>
>
>Jim,
>
>A person to contact regarding "gated" is
>
>	Mark Fedor <fedor@NISC.NYSER.NET>
>
>--Annette
>>>

	Actually, I left Cornell last year and although I put my two
	cents in every now and then like everyone else, the main developer
	is now Jeff Honig at Cornell (jch@devvax.tn.cornell.edu).

	So please contact him, but.. if anyone out there wants to play
	softball this summer in Albany, contact me.  :^)

	see ya!

	Mark

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 12:30:01 EST
From:      Mills@UDEL.EDU
To:        CERF@a.isi.edu
Cc:        kwe@bu-cs.bu.edu, tcp-ip@sri-nic.arpa
Subject:   Re:  Rumors about the death of the ARPANET
My recent message left out a fine point. ISDN may in fact provide 64-kbps
ubiquitous interface, but a significant fraction of interoffice transport
will still be anaolg, with conversion where required. This means you can
ask (using the D channel) for 64-kbps data service, but the network may
tell you thanks, but no anyway. You may ask for 9.6-kbps data and the
network may be happy to oblidge you, then depreciate the modems at ratepayer
expense.

Hang on to your Telebits for awhile, at least.

Dave
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 07:50:55 GMT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  brl ping

You are correct in that up to 9 routes can fit in an IP header if
record route is the only option.  I'm not sure how ours ended up
set to six (the documentation just laments the max IP header size).
You can simply change the "#define NROUTES" from 6 to 9.  I have
done so to VGR's copy.

- Phil

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 13:22:09 EST
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        cerf@isi.edu, farber@cis.upenn.edu
Cc:        perry@mcl.unisys.com, tcp-ip@sri-nic.arpa
Subject:   Re:  Off loading the protocol
Dave, we had this type of discussion often at Los Alamos, namely,
how long is YOUR network (keep you evil thoughts to yourself!).  Teh
comparison was between 19inch rack or 10 miles out to the remote
canyon site.  But you are right, networking is just an extended case
of interprocess communication, with the processes spread over a
varying distance.  That distance can have an affect, if the time
required to travel that distance affects what the processes are doing.
At very high speed, the effect can be small to non-existant.

dennis
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 13:34:07 EST
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        KASTEN@mitvma.mit.edu, tcp-ip@sri-nic.arpa
Cc:        perry@mcl.unisys.com
Subject:   Re: Rumors about the death of the ARPANET
Frank, yes the Government is thinking about and looking at DS3.
One of the main questions at this point is cost and how it can be
shared among the agencies in ways other than multiplexing the DS#
down to T1s.  I think we will see DS3 before too long, unfortunately
it will be a while longer before we see a dark DS3 and can multiplex
at the packet level.

dennis
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 16:34:16 PST
From:      ultra!ted@ames.arc.nasa.gov (Ted Schroeder)
To:        tcp-ip@sri-nic.arpa
Subject:   Add to mailing list
Please add the following mail alias to the tcp-ip mailing list.

                                      ultra!tcp-ip@Ames.ARPA
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 tcp-ip@Ultra.COM
      408-922-0100


-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Mar 88 17:13:11 PST
From:      Jon Peha <peha@spam.istc.sri.com>
To:        tcp-ip@sri-nic.arpa
Subject:   precedence
I note in the RFC's that TCP and IP have three bits reserved
for precedence, but UDP does not.  I have a number of questions
about this.  The obvious place to start: is precedence really implemented?

I can see many obvious fairness problems.  One user could 
effectively shut out other users until their TCP connections
start timing out.  If they are allowed to, every one will
want to send high precedence packets.  How are these problems
resolved?

Why doesn't UDP hace precedence as well?

My questions arise from a desire to send packets over a token
ring.  The 802.5 spec allows packets to have different priorities,
but I can't figure out how you would use this feature with
the TCP suite.  Has any one out there ever done this?  This particular 
application is voice, so I want a connectionaless transport (UDP).
Thanks.

Jon Peha
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 12:39:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:      Conversion to ISO - Number of NCP Hosts

I can't give firm numbers but there were on the order of 20-25 different
operating system implementations of NCP and somewhat fewer for TCP at the
time the conversion was done - some hosts never made the change and were
simply retired (good excuse...).

The NCP/TCP and TCP/ISO analogies are not exact. For one thing, NCPwas
never a commercial product. TCP is. For another, only ARPANET hosts did NCP because
that was NOT an internet protocol, so a single administration could insist on
the conversion and was even able to turn off NCP capability within the 
subnet as a forcing function. This is not possible for TCP/ISO except perhaps
at the gateways (and maybe for the subnets if packet types for ISO IP and DoD IP
are distinct, as I suppose they are likely to be).

There must be literally tens of thousands of TCP/IP hosts by now compared to
at most a couple of hundred NCP hosts in Jan 83. 

Somehow I think the analogy is not very apt.

Vint

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 12:47:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

The FCCSET committees, the NSF, the EDUCOM Network Forum, and a number
of other individuals, groups, organizations, random parties, etc. all
are interested in seeing a high speed network emerge which could benefit
the research community and ultimately the entire business population.

Serious work is going on in industry and in the research labs on very
high speed switching capble of operating in excess of 45 Mbps. A SONET
swiitch (circuit) was demonstrated recently at 135 Mb/s; a packet
mode switching fabric is under development at Bellcore which will
operate at 100-200 Mb/s per channel (packet mode).

Cost is an important consideration and it does seem as if various
forms of subsidy will be needed in the early stages, just as the
ARPANET was subsidized fully by the R&D funding activity of DARPA.
In the longer term, though, there are services which will dmeand the
bandwidth and make it far less expensive on average. To give a
trivial example, once ISDN emerges, 64 kb/s will be the standard rate
for voice - so you get to use it for data, too, without the cost
of a modem.

This isn't to say everything will happen easily or even very quickly,
but there are enough forces in motion that I believe the will and
the therewithall to make high speed nets a reality will be available.

Vint

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 14:37:25 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Checksums

The advantage to using checksums with tcp and ip is that generating a
checksum is a relatively low-cost operation (the addition instruction in
most processors requires relatively few t-cycles).  When you begin to
talk about extracting pattern information from a bit stream you begin to
talk about an increase in processing overhead that is several orders of
magnitude greater.

To me the greatest feature of the Internet Protocol Suite is that it
tends to espouse the KISS principle: elegant simplicity.  I would be
loath to bog down the protocol with a lot of additional algorithmic
baggage.  I can see the point that it would be nice to determine that
someone is using an off-by-1 counter or has a pointer misalignment
problem, but that is not what goes on most of the time.  The things you
really want to know in an operational network are link quality,
throughput, packet loss rate, and delays.  What we REALLY need is a
protocol that allows us to gather information from the LLPs for
transmission so a network control center (either centralized or
distributed).  We may also want to discuss the use of forward error
correction over some links so that you can extract additional
information from the bitstream but we would probably want to do that at
the link layer where it would be sensible to put it in a front-end
processor.

I guess that I am responding to a suggestion that smacks of making
things more complex.  What we really need to do is to make things
simpler so that we can make things faster and more reliable.  Additional
complexity should be compartmentalized in such a way that it can be
safely ignored :-).

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 15:41:21 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: Conversion to ISO - Number of NCP Hosts

Scott,  You missed the chance to say "NCP is still alive in a well..."

Yes, NCP is still running in some classified environments where once you
get something to run that you (somehow) trust, you leave it alone.

As for the larger issue raised by Mark,  moving from NCP tp TCP/IP
was a large task, but it was ameliorated by the relatively small number
of hosts affected.  In those days there were probably only a thousand
hosts and ten system types to deal with.  It took a good amount of
coordination to get those hosts to all bring their software "forward"
to permit testing before we threw the switch on jan 1, 1983.  
When we go to make the change to OSI there will be a few million hosts
on hundreds of system types out there and there will be no "authority"
to tell everyone to switch.  So, Mark, you are quite right to be "worried"
that a conversion might take longer, be harder, etc.  

Dan
-------

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 17:12:00 GMT
From:      dcrocker@TWG.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   on-/off-board protocol processing

As with most technical choices, each alternative has its appropriate uses.

The concern about reliability of processing, expressed by Vint, seems not
to apply to many of the current "intelligent-board" solutions.  Their 
interface to the host is essentially -- often exactly -- like accessing
standard primary memory.  So, if you don't trust your primary memory,
you probably have more serious architectural fish to fry that where you
put your protocol processing.  When the interface is more channel-oriented,
then reliability becomes factor.  That is, if you need a serious protocol,
to access your protocols, there is a reasonable chance that the access
protocol has bugs, so that you have a step in the networking chain
truly exposed to problems, and not detectable by the end-to-end
safety mechanism of the transport protocol.

On the other hand,

There is some interesting mythology about the benefits of moving your
protocols to an intelligent board.  Having a slow board and a fast
host has become a very significant issue, as discussed in some
messages, already.  My only comment is that when making a choice, you
should pay close attention to this issue.

Less well-understood are some beliefs that the intelligent board
makes the host less complex and relieves the host of substantial
overhead.  This is true only sometimes.  The only factor that is
always nicer about intelligent boards is that they do the checksum
calculation.

On the other hand,

They significantly increase the cost of networking hardware.  They
tend to limit the number of virtual circuits that you can have, due to
memory limitations on the board -- a factor that is becoming less of
a problem, with 512K and 1M boards.  They tend to make multiple-interface
configurations a problem, since you then have to add complexity to the
host, anyhow, to coordinate the cards.

That is, when you move the protocols to the board, then multiple
boards become multiple protocol implementations.  Coordinating IP
routing, UDP and TCP Port number allocation, etc, becomes a real
hassle.  Worse, customers seem to be inclined to try to do this
with implementations from different vendors(!)

The idea that intelligent boards reduce interrupt overhead sounds
appealing, but often does not prove out.  Most incoming packets
have their data handed immediately to the receiving application, so
that the network interrupt, caused when the packet arrives, still
causes the o/s device driver -- yup, you still need such a beast when
you have intelligent boards -- to interrupt and you still have the
kernel/user context switch.  In the case of heavy traffic with
small packets, the intelligent board does have an edge.  Otherwise,
the host-based solution seems to be a much more efficient use of
resources.

Now, suppose that you have a host that is tending towards saturation and
you believe that the extra processing on the board will relieve the
problem.  At one level of analysis, you would be correct. 

On the other hand,

It is a very short-sighted way to solve a system congestion problem.  If
your host has a problem at that level, you probably have only bought yourself
relief for a short time.  In all likelihood, you need to get yourself
another host.  

Given that most machines are in the micro-computer and small-minicomputer
range, this expense is not necessarily onerous.

Now, about the idea of having a non-networking-oriented access
model for the software, such as the view of fitting the network in
as a portion of a process's address space, so that the software need
not be aware of networking; it simply thinks that it is doing memory
transfers, and the underlying hardware/software handle the rest...

For general, "distributed processing" types of activities, this
will, no doubt, prove very, very useful.  In essence, it is the
natural evolution down the path that includes the remote procedure
call model, since you are integrating networking into increasingly
"natural" computing models.

This, also, is its problem.  While it often is very nice to hide
networking issues, it often is necessary to manipulate them directly.
Allowing a program to ignore the issues is great.  Preventing it from
paying attention is terrible.

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 17:18:49 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Rumors about the death of the ARPANET

Vint,

Your suggestino that, once we get ISDN, we will have ubiquitous 64-kbps
digital service tripped me up. While making much the same comment at
a recent meeting, carrier representatives were quick to point out that
2B + D (two 64-kbps bearer plus 16 kbps data/control) might well be
ubiquitous in the feeder and distribution plants, but it may take much
longer for this to occur in the interexchange plant. What may happen for
many years is that 64-kbps data may not be ubiquitous outside your local
area. In fact, I was told the 16-kbps data/control channel would not
be end-to-end for a long time.

Why don't we chuck the whole thing and move to B-ISDN and SONET? The
general consensus of the carrier's R&D guys is that this would really be
the best course. Are you ready for 51.84 Mbps? You gete 125 microseconds to
make up your mind.

Dave

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 18:56:26 GMT
From:      cracraft@venera.isi.edu (Stuart Cracraft)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge Communications TCP/IP 20000

In article <1035@uni2.bcm.tmc.edu> sob@bcm.tmc.edu (Stan Barber) writes:
>Until recently, I was only marginally satisfied with the Bridge product. Now,
>I am quite pleased with it. My only major remaining complaint is the lack
>of support for a non-proprietary system logging function. I have suggested
>that they make their log information available to the unix syslog function.
>I hope they will.
>
>Stan Barber, Baylor College of Medicine
>
I'll second the kudo for Bridge. It's a good, solid product. We've
had smooth operation from it.

	Stuart

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 18:59:59 GMT
From:      lamaster@ames.arpa (Hugh LaMaster)
To:        comp.protocols.tcp-ip
Subject:   Re:  offloading the protocols

In article <8803160106.AA05728@Pescadero> cheriton@PESCADERO.STANFORD.EDU ("David Cheriton") writes:

>VMTP (RFC 1045) is specifically designed to work well with hardware support

I find it interesting to note that while some people are worrying about
the necessity for offloading protocol processing, Van Jacobson and Mike
Karels have contributed algorithms that together will push 10Mbits/sec
from a CPU with less than 2 MIPS.   In any reasonable model of the rates
of computation versus network traffic for any non-gateway host, it isn't
clear that there is any benefit at all to offloading protocol processing.
In fact, recent history seems to confirm that using a general purpose CPU
is a better way to go- easier to install new algorithms and bug fixes.  If
more processing power is needed, multiple (general purpose) CPU's seems
to be a much more cost effective way to go.  I note that Ardent Computer
seems to be applying the same principle to Graphics processing - instead
of special purpose graphics engines, build the system with multiple CPU's.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 20:04:00 GMT
From:      mja@TWG.COM (Mike Anello)
To:        comp.protocols.tcp-ip
Subject:   RE: (TLI HELP)

In reply to Gil Widdowson note about TLI HELP:



In both socket and tli calls sockaddr_in structure is used to specify an
internet address. Since sin_zero element of this  structure does not contain
any usefull data, only the first three elements (the first 8 bytes) should
be passed to buffers used in tli calls. Two constants UDP_BINDADDRLEN in udp.h
and TCP_BINDADDRLEN in tcp.h may be used for this purpose.

When using t_bind(fd, req, ret) call, you will get back in ret.addr.buf the
address assigned by the transport provider. This address is 8 bytes long 
and represents the first three elements of sockaddr_in structure.
In t_bind(fd, NULL, &ret) call, transport provider will assign INADDR_ANY
address, and the next available port number to the end point. 


Mohsen Mortazavi
The Wollongong Group

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 21:41:36 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Options and ICMP Messages

To all those who picked up the network exercising stuff from
lambda.lanl.gov.

I gave you a bum [ls]srr.sh.  Due to my lack of understanding how
BSD4.3 handles the loose/strict source route option on output, the lsrr
and ssrr scripts are in error.  It is not intuitive that BSD UNIX will
strip off the first address in the option to use as a destination,
ignoring the destination requested via an open system call.  I have another
script 'sr' which takes the above into account.  For example:

	sr loose 192.5.16.33 26.3.0.103 26.0.0.90

ships an icmp echo packet to the lanl gateway via gateways 192.5.16.33 and
26.3.0.103.  What the heck, here's the script (BTW, the ping is a modified
Muuse ping):
#! /bin/sh
# 
#  Los Alamos National Laboratory 
# 
#  Copyright, 1988.  The Regents of the University of California. This software
#  was produced under a U.S. Government contract (W-7405-ENG-36) by Los Alamos
#  National Laboratory, which is operated by the	University of
#  California for the U.S. Department of Energy.  The U.S. Government is
#  licensed to use, reproduce, and distribute this software.  Permission is
#  granted to the public to copy and use this software without charge, provided
#  that this Notice and any statement of authorship are reproduced on all
#  copies.  Neither the Government nor the University makes any warranty,
#  express or implied, or assumes any liability or responsibility for the use
#  of this software. 
#
#  ICMP ECHO with IP Loose/Strict Source and Record Route
#
#	"@(#)sr.sh	1.1 (LANL) 3/23/88"
#
Usage="
Usage: sr {loose,strict} destination(1), destination(2) ... destination(n)
"
NOP=1
SRPOINTER="4"
PING=/usr/local/etc/ping
TYPE=-v
list=""
if [ $# -lt 3 ] ; then
	echo "$Usage"
	exit 1
fi
if [ $1 = loose ]; then
	SR=131
elif [ $1 = strict ]; then
	SR=137
else
	echo "$Usage"
	exit 1
fi
shift
SRLEN=`expr 3 + \(  $# \* 4 \)`
GW1=$1 # it dont matter what host you "open a connection to"
for i
do
list="$list -o d$i"
done

$PING  $TYPE \
	-o d${NOP} \
	-o d${SR} \
	-o d${SRLEN}.${SRPOINTER} \
	$list \
	$GW1 12 1

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 22:30:56 GMT
From:      digi@megalon.UUCP (Klaus Altenburg)
To:        comp.protocols.tcp-ip,comp.windows.misc
Subject:   Re: Sun servers

In article <880321184301.105983@HIS-PHOENIX-MULTICS.ARPA> Houde@HIS-PHOENIX-MULTICS.ARPA writes:
>Sorry, but I never specified my address.  I wanted to know whether or not I
>could use a standard Unix box as a server for Sun workstations.  Please direct
>any responses to Houde at PCO-MULTICS.ARPA.

My company is also interrested in using workstations (like sun's) for CASE.
Here in Germany a reasonable sun-server costs about 35.000 - 40.000 DM.

So here some questions about CASE, workstations, NFS, RFS and
graphic environments on un*x :

	- Is it right, that we need only a unix-machine with a working
	  NFS to run diskless sun-workstations ?
	- Are the sun's bootable via the nfs of a non-sun-server ?
	- What about workstations based on RFS ?
	- is there software to use 386-based systems as workstations for CASE ?

Thanx in advance
-------
Klaus Altenburg, (Keywords: 'C', UN*X)
W.-Germany, 4100 Duisburg 46, An den Siffen 12, +49-2151-404087
Email: digi@megalon.{UUCP,?DE?}; Fido 2:507/777

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1988 03:37-EST
From:      CERF@A.ISI.EDU
To:        Mills@LOUIE.UDEL.EDU
Cc:        kwe@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Rumors about the death of the ARPANET
Dave,

I'm sure not holding my breath for ISDN or B-ISDN, but I would not
mind having them both!  The local loop is the last part and the one
which will take the longest, but for many city-based systems,
the pairs are short enough that there are no loading coils, so
the switchover requires only CPE and CO equipment. It is probably 
1996-2000 before we see 65% business penetration and 35% residential, but
your guess is as good as mine.

Vint
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 1988 04:01-EST
From:      CERF@A.ISI.EDU
To:        mckenzie@LABS-N.BBN.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  A network you can trust
Alex,

"a carefully designed network..." A network? But won't there be thousands of
them? Will they ALL be as reliable as you'd like?

I'm less persuaded that somehow datagrams are wrong and virtual circuits are
right, if that was what you meant in your note, than I am persuaded that
we need mechanisms which make apparent memory sharing a reality. Since
we need reliability mechanisms to do this SOMEWHERE in the design, I
certainly agree that if they aren't in the host, they must be in the
off-loaded part. 

Vint
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 88 23:20:32 GMT
From:      jeremy@swatsun.uucp (Jeremy Brest)
To:        comp.dcom.lans,comp.os.vms,comp.protocols.tcp-ip
Subject:   Request for information: NFS, Vax/VMS, tcp/ip

I would like to know about people's experiences using NFS under VMS to
connect to Suns.  How is the interface from the VMS side?  Unix?  Is
mounting supported in both directions?  How difficult is it to
administer?

Please mail replies, unless your response is of general interest.

Jeremy Brest
Swarthmore College
uucp:  ...seismo!bpa!swatsun!jeremy
CSnet: jeremy@swatsun.swarthmore.edu
Arpa:  jeremy%swatsun.swarthmore.edu@relay.cs.net

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 02:02:57 GMT
From:      stev@ftp.COM (Stev Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Ultrix

Posting-Front-End: GNU Emacs 18.47.2 of Thu Aug 13 1987 on ftp (berkeley-unix)



**> In article <8802060858.AA08978@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes:
**>> We have a uVAX running Ultrix that I would "like" to have SLIP on.
**
**> I took a look at an Ultrix system at one time and kind of came to the
**> conclusion that trying to do it yourself to a binary Ultrix
**> distribution was no fun.
**
**Trying to do anything to a binary distribution is no fun.  I hold the
**view that if you don't have source, you shouldn't even consider using
**it.
**					der Mouse
**
**			uucp: mouse@mcgill-vision.uucp
**			arpa: mouse@larry.mcrcim.mcgill.edu
**

ftp to ftp.com (128.127.25.100), user = anonymous, password = your
name, and get the file BUGLIX.SLIP.TAR. this is a distribution of slip
for a binary only ULTRIX 2.0 site. there is a readme file there to
explain how it should be done. if you have not rebuilt your kernel
before, here is not the place to start. if you have, this will get you
running. if you have problems with it, you can e-mail me questions.
(i dont get paid to support *this* code).

stev knowles
ftp software

stev@ftp.com

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 04:36:06 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Some Internet gateway performance data

Folks,

You might be interested in the following summary of data on NSFNET Backbone
Fuzzball performance, as well as a comparison with the ARPANET/MILNET
gateways, which operate in a similar state of massive traffic insult. These
data update those reported in the SIGCOMM 87 paper and include the period
since the source-quench policy described previously (and in a paper just
submitted) was implemented.

In July 1987 after the Fuzzball selective-preemption policy was installed, but
before the source-quench policy was implemented, the throughput per trunk
ranged from 0.3 to 4.0 packets per second, with a mean of 2.0. At that time
the total trunk throughput was 31 pps with drop rate due all causes of .09
percent. In March 1988, several months after quench was installed, the trunk
throughput ranges from 2.6 to 9.2 packets per second, with a mean of 4.7. At
this time the total trunk throughput is 71 pps with drop rate 0.48 percent and
with 0.27 percent of all trunk packets resulting in a quench.

The following table shows the performance of the NSFNET Backbone Fuzzballs for
periods ending on 21 March. These numbers include Ethernets as well as all
56-kbps trunks.

	Node   Mpkt    UpHr      PPS     Drop   Quench
	----------------------------------------------
	 1     3.49     100     9.75     0.17     0.04
	 2    18.48     260    19.72     0.38     0.39
	 3     6.33     102    17.33     0.16     0.17
	 4    15.08     262    15.99     0.31     0.45
	 5    19.36     266    20.20     0.85     0.18
	 6     2.97      48    17.35     0.17     0.14
	 7     7.02     262     7.44     0.71     0.04
	----------------------------------------------
	Total 72.74    1299    15.55     0.34     0.18

The "Mpkt" column shows the aggregate throughput in megapackets for all output
queues, including serial lines and Ethernet. The "UpHr" column shows the
aggregation interval in hours. The "PPS" column down through the "Total" row
shows the resulting throughput, which is the "Mpkt" column divided by the
"UpHr" column adjusted to the proper units. The "Drop" and "Quench" columns
show the percentage of packets dropped and quenched respectively. The value
shown in the "Total" row for these columns is the average of the column
itself. The existing NSFNET Backbone clearly meets the performance objective
of less than one percent drop rate.

For comparison the following table shows the performance of the ARPANET/MILNET
gateways for the week ending 21 March. So far as can be determined, each
gateway is connected to two 56-kbps data paths.

		ID     Mpkt    UpHr      PPS     Drop
		-------------------------------------
		 1     4.83     144     9.32     7.26
		 2     6.15     144    11.86     8.18
		 3     7.06     146    13.48     7.40
		 4     7.03     139    14.08    12.87
		 5     3.14     145     6.00     0.83
		 6     3.75     109     9.54     3.23
		 7     5.07     146     9.66     2.85
		 8     2.76     129     5.95     3.65
		-------------------------------------
		Total 39.79    1101    10.04     5.78

As evident from these figures, the NSFNET Backbone Fuzzballs carry a
throughput over fifty percent greater per node than the ARPANET/MILNET
gateways with a drop rate of over ninety percent less. Note that this
comparison may not be fair in two ways: first, the ARPANET/MILNET gateways are
connected to networks, not trunks, which can have large dispersive delays;
second, the NSFNET Backbone Fuzzballs are connected to Ethernets, which
provide no insulation against unruly traffic generators.

From measurements made last July and reported in the SIGCOMM paper last year,
the selective-preemption policy made a whale of a difference. The case for the
source-quench policy installed recently is less clear, although there is
recent evidence that it is in fact effective for those hosts that respond to
quench messages. However, even if the crafted policies and Fuzzball
implementations may be suboptimal and change next Monday, the data above
should be convincing beyond doubt that fairness policies and queue disciplines
similar to these will be necessary for future generations of connectionless
packet switches and gateways.

Dave

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 07:07:53 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Checksums (was Re: Ping, checksum algorithm?)

Thanks for an excellent tutorial on checksumming. Some additional notes:

The Internet checksum algorithm has an interesting property that is very
useful when working on little-endian machines: the sum of the
byte-swapped words is equal to the byte-swapped sum of the words.  In
other words, there is no need to byteswap each word on a little-endian
machine before summing it; you can sum the words in machine order and
then byteswap the result.

If you write an "assist" routine in assembler you can exploit the "add with
carry" instruction found in many machines. E.g., on the 808x family, you
can accumulate a sum as follows:

doit:	lodsw
	adc dx,ax
	loop doit

(once you've set everything up, of course). This can speed up
checksumming enormously on 16-bit machines like the PC since the long
(32-bit) arithmetic you would normally use to accumulate the carries is
much slower.  The actual code I use goes further, in that I unwound the
loop and used "Duff's Device" to handle blocks that are not integral
multiples of the loop length.

Phil

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 07:12:00 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: offloading the protocols

I would like to draw extra attention to the fact that Van and Mike were
able to do what they did WITHOUT cheating, i.e., turning off TCP checksums.

Somebody should tell Sun that this puts the final nail in the coffin of their
argument that NFS can't tolerate UDP checksums for "performance" reasons... :-)

Phil

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 08:37:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Rumors about the death of the ARPANET

Dave,

I'm sure not holding my breath for ISDN or B-ISDN, but I would not
mind having them both!  The local loop is the last part and the one
which will take the longest, but for many city-based systems,
the pairs are short enough that there are no loading coils, so
the switchover requires only CPE and CO equipment. It is probably 
1996-2000 before we see 65% business penetration and 35% residential, but
your guess is as good as mine.

Vint

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 08:49:32 GMT
From:      henk@hcsrnd.UUCP (Henk Willems)
To:        comp.protocols.tcp-ip
Subject:   Tandems connected to SUN systems

Question: 

  We want to connect SUN systems to a TANDEM machine, preferably using
  ethernet. Is there somebody that has experiences with such a configuration ?
  The SUN must be used as a colour-graphics workstation and for terminal 
  emulation to the TANDEM system.

Please reply by Email.


Henk Willems
mcvax!hcsrnd!henk@uunet.UU.NET

HCS Industrial Automation BV.
Landdrostlaan 51 
PO Box 20020
7302 HA Apeldoorn.
The Netherlands

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 09:01:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

Alex,

"a carefully designed network..." A network? But won't there be thousands of
them? Will they ALL be as reliable as you'd like?

I'm less persuaded that somehow datagrams are wrong and virtual circuits are
right, if that was what you meant in your note, than I am persuaded that
we need mechanisms which make apparent memory sharing a reality. Since
we need reliability mechanisms to do this SOMEWHERE in the design, I
certainly agree that if they aren't in the host, they must be in the
off-loaded part. 

Vint

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 13:26:39 GMT
From:      johnl@n3dmc.UUCP (John Limpert)
To:        comp.protocols.tcp-ip
Subject:   Re:  precedence

>I note in the RFC's that TCP and IP have three bits reserved
>for precedence, but UDP does not.  I have a number of questions
>about this.  The obvious place to start: is precedence really implemented?

I don't know about the arpanet, but many other DOD voice/data networks
implement precedence.

>I can see many obvious fairness problems.  One user could 
>effectively shut out other users until their TCP connections
>start timing out.  If they are allowed to, every one will
>want to send high precedence packets.  How are these problems
>resolved?

Precedence is supposed to be unfair :-).  The idea is to reduce delays
for high priority traffic, seizing resources from lower priority traffic
if necessary.  You need to have prior authorization for the use of the
higher precedence levels.  You shouldn't be able to use precedence
levels higher than ROUTINE without authority and need.  The requirement
for authorization can be enforced in a switch.  The switch can check a
table of maximum user precedence levels.  Just because you mark something
with 'FLASH OVERRIDE' doesn't mean the switch will believe you.  In a circuit
switched environment, the switch will preempt (drop) lower priority
connections if it runs out of resources.  I would expect packet switches
to sort queues by precedence.

By the way, this is one use of the 4 extra/missing DTMF (touch tone TM)
buttons on your telephone.  Some phones have 16 buttons, with 4 buttons
assigned to precedence.

John Limpert	johnl@n3dmc.UUCP
		bellcore!wb6rqn!n3dmc!johnl

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Mar 88 19:07:39 EST
From:      Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
To:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   ReChoosing gateways
A question....

Suppose a host is connected to a network which has two gateways on
it (G1 and G2) both of which have valid paths to some destination
network (the "cost" of those paths is irrelevant).

The host is using G1 to communicate with a host on the destination
network and G1 dies with no warning (e.g. the power supply blows up) so
that G1 can not send any kind of "I'm Dying" message (This death is NOT an
overload due to too many packets that can be fixed with a ICMP Source Quench
or Redirect).

Are there any rules/guidelines/standards/... as to how the host can "find"
G2?

Thanks In Advance
Frank Kastenholz
Atex Inc.
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 15:00:06 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums

> What we REALLY need is a ...

What we could have used was complience, by the many "rush to networking"
Vendor's out there, with the Internet IP / ICMP protocol suite.
Using the IP options, and various ICMP functions, it could be possible
to figure out:

> "...link quality, throughput, packet loss rate, and delays..."

One can get a glimmer about the above now, cause 'some' gateways and hosts
provide 'some' of the features, that work 'some' of the time.

So, before you/we go off an' invent another protocol which any number of
universities will jump on as a weekend project, and then any number of
vendors will grab at sometime in its life cycle and purvey to the public
as there own with out support, ... FIX IP AND ICMP!

Cornett Philip Wood  cpw@lanl.gov

Los  Alamos  National  Laboratory

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 15:00:41 GMT
From:      dab@ALLSPICE.LCS.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ARP hardware field


	    Does this make Proteon non-standard? I was quoting from rfc1010,
    and I must admit some confusion over the status of rfc's, I know that rfc
    stands for Request For Comment, but everyone seems to treat them as
    standards, so what are they? Standards or Drafts of proposed standards,
    and if they are drafts what are the final standards (if any exist) called?

The confusion comes from the fact that Assigned Numbers (RFC1010) and the
ARP RFC (RFC826) say slightly differing things.  Assigned numbers says that
protocol types are taken from the list of ethernet protocol types (as you
quoted).  The ARP RFC says (last paragraph on page 5):

"Generalization:  The ar$hrd and the ar$hln fields allow this protocol
and packet format to be used for non-10Mbit Ethernets.  For the
10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>.  For
other hardware networks, the ar$pro field may no longer
correspond to the Ethernet type field, but it should be
associated with the protocol whose address resolution is being
sought."

The people who implemented ARP for the ProNet-10 (CMU I believe)
implemented it from the ARP RFC instead of from Assigned Numbers.  They
therefore used protocol numbers from the protocol type field used on the
ProNet-10.

In a recent conversation with Postel and Reynolds, I was informed that
Assigned Numbers is now correct and all future implementations should use
Ethernet protocol types.
					David Bridgham

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 16:47:01 GMT
From:      wayne@petruchio.UUCP (Wayne Hathaway)
To:        comp.protocols.tcp-ip
Subject:   Re: on-/off-board protocol processing

One problem with offloading protocols which has not yet been mentioned
has to do with the "locked-up" nature of commercial on-board protocol
implementations.  A specific example from a place I used to be
associated with:  They used intelligent Ethernet cards (brand name
irrelevant) quite successfully -- until they extended their Ethernet
to the East Coast with a satellite link.  Needless to say, the
on-board Ethernet software was hardly tuned to the extra delay, and
the throughput was abysmal.  But since the on-board software was
proprietary there was nothing the host administrator could do, and
while the card manufacturer was sympathetic, tuning his software for
such a "strange" environment was very low priority.  The solution?
The satellite link was replaced with a slower (bandwidth) but faster
(throughput) land line!

Of course, this is nothing unique to network protocols; any
"intelligent controller" could have the same problem.  In the case of
something like a disk controller, however, one is considerably less
likely to suddenly add some 40,000 miles to the length of the cable!

      Wayne Hathaway                  ultra!wayne@Ames.ARPA
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 wayne@Ultra.COM
      408-922-0100

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 16:47:17 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   ARP protocol address space field on ProNET

Well, being as someone is calling my implmentation of ARP
non-standard, I will speak to the issue of the Protocol Address Space
in ARP for ProNET.

The first implementation of ARP on ProNET was done at Carnegie-Mellon
University, for the IP protocols.  (IP normally does not use ARP on
ProNET, but CMU's routing scheme at the time was based on ARP subnet
routing, so they needed ARP.)  At that time, the table of ARP Hardware
Address Space types were not in the current version of Assigned
Numbers, since the only value was 1 (Ethernet), which is specified in
ARP.

As we read RFC 826 (ARP), it only claimed that the Protocol Address
Space field was chosen from the field of Ethernet types if the
Hardware Address Space was Ethernet.  We decided (by default, really)
that it was obvious that we should use the space of ProNET types for
ProNET.  Aside from reasons of symmetry, the more important reason is
that there might well be protocols on ProNET which do not have
Ethernet types, but do need to use ARP.  Indeed, this is currently the
case for some protocols on ProNET.

The versions of assigned numbers that stated that Protocol Address
Space would always be Ethernet types came long after our ARPs were in
the field.  I have noted this discrepancy to the NIC before.

Currently, three protocols have been used with ARP on ProNET:
1.  IP (only at CMU, between 32 bit IP addresses and 8 nit node addresses)
14. XNS (between 48 bit XNS host addresses and 8 bit node addresses)
20. DECnet (between 48 bit DECnet/Ethernet addresses and 8 bit node addresses)

Yes, writing a multi-hardware multi-protocol implementation of ARP is
interesting, since there are all these variable-sized peices, and
different Protocol Address spaces.

Oh yes, the "standardness" level of an RFC depends on how and whether
it is cited in the current version of the "Official Internet
Protocols" RFC.  The current version of this RFC can be considered the
top of the tree.

Also, there will always be interpretation issues with standards.
ProNET ARP is just one example.

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 16:56:13 GMT
From:      lars@ACC-SB-UNIX.ARPA (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong TCP/IP for VMS and Cisco AGS routers interaction

To: enger@bluto.scc.com, info-vax@kl.sri.com, jerry@twg.com,
	tcp-ip@sri-nic.arpa, yehavi%hujivms.bitnet@cunyvm.cuny.edu
[Re-sent, due to typo in TCP-IP address]

Jerry Scott of the Wollongong Group forwarded me a copy of an INFO-VAX
message from Yehavi Bourvine asking about running TCP/IP over commercial
X.25 nets using WIN/TCP and ACC's ACP6250.

The driver for the ACP6250 (which Wollongong provides for WIN/TCP and which
ACC provides for 4.xBSD and Ultrix-32) allows the use of a commercial
X.25 network as the subnet carrier vehicle.

Two flags control the differences between this application and the 
"DDN Standard Mode" application:

- the "service" flag is set to "basic" to make the X.25 connection
  be host-to-host rather than host-to-PSN as in the DDN.
  This produces call requests packets with protocol type 'CC'hex
  (in the user call data field) and no "standard mode" facility request.
- the "PDN mode" flag is set to obtain X.25 addresses by table lookup
  rather than by algorithm from the IP address.

The "basic PDN" configuration should be interoperable with the
CSNET driver for the old INcard, but for mostly political reasons, this
has not to my knowledge been tested.

/ Lars Poulsen
  ACC Customer Service

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 17:01:05 GMT
From:      matthews@vax1.acs.udel.EDU (John,Iii Matthews)
To:        comp.protocols.tcp-ip
Subject:   Makefile for KA9Q BSD?


Does anyone out there know where I can get a makefile that will
successfully build the BSD version of KA9Q.  The makefile in the
ka9q archives on louie.udel.edu says to change a few CFLAGS defines
but there aren't even any references to any of the BSD specific modules
that appear in the archive.

-- 
John Matthews
4801 Plum Run Court     ARPA:   matthews@udel.edu
Wilmington, DE 19808    BITNET: FFO18429 AT UDACSVM
   (302) 454-1735       CSNET:  matthews%udel.edu@relay.cs.net
                        UUCP:   ... !uunet!udel.edu!matthews

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 88 20:46:00 GMT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   ARP protocol address space field on ProNET


    Date: Thu, 24 Mar 88 11:47:17 EST
    From: jas@monk.proteon.com (John A. Shriver)

Being the author of ARP...

    ...
    As we read RFC 826 (ARP), it only claimed that the Protocol Address
    Space field was chosen from the field of Ethernet types if the
    Hardware Address Space was Ethernet.  We decided (by default, really)
    that it was obvious that we should use the space of ProNET types for
    ProNET.  Aside from reasons of symmetry, the more important reason is
    that there might well be protocols on ProNET which do not have
    Ethernet types, but do need to use ARP.  Indeed, this is currently the
    case for some protocols on ProNET.

... this was certainly the intention.  When I heard the ProNet did not
use Ethernet types for their protocol dispatching field, I found that
"unfortunate."  The reasons they chose to be different may be good or
bad; I'm not concerned about that here.

    The versions of assigned numbers that stated that Protocol Address
    Space would always be Ethernet types came long after our ARPs were in
    the field.  I have noted this discrepancy to the NIC before.

The NIC is wrong, both by the intent and by the literal reading of the
RFC.  The fact that some other hardware types (e.g., packet radio,
certain serial links, etc) also use the 10MBit Ethernet hardware type
for ar$pro is a perfectly reasonable design convenience, but that's
where it stops: it is a convenience.

Summary: The NIC overstepped its authority by asserting that ar$pro is
always taken from the set of ethernet types.  Proteon did a reasonable
and valid thing in defining ar$pro to come from a different and rational
set of types.

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 00:00:54 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   SLIP working group?

What's going on with the SLIP working group that started up at the last
interoperability conference?  Has anyone come up with anything better than
Russ Hobby's ASLIP?  Can we get a status report from someone?

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 00:07:39 GMT
From:      KASTEN@MITVMA.MIT.EDU (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   ReChoosing gateways

A question....

Suppose a host is connected to a network which has two gateways on
it (G1 and G2) both of which have valid paths to some destination
network (the "cost" of those paths is irrelevant).

The host is using G1 to communicate with a host on the destination
network and G1 dies with no warning (e.g. the power supply blows up) so
that G1 can not send any kind of "I'm Dying" message (This death is NOT an
overload due to too many packets that can be fixed with a ICMP Source Quench
or Redirect).

Are there any rules/guidelines/standards/... as to how the host can "find"
G2?

Thanks In Advance
Frank Kastenholz
Atex Inc.

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 00:55:23 GMT
From:      budden@tetra.NOSC.MIL (Ray A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET


Maybe I'm missing something, but:

- we are getting 10-20 km between repeaters on fiber links these days,
perhaps somewhat more with high clarity and laser transmitters.

- FDDI rings accomodate 512 nodes before we have to split the net.

- FDDI starts life at 100 Mbits.

Looks to me that 500 nodes times 20 km multiplies out to a pretty
decent regional backbone -- internet a half dozen of these and you've
got the country covered.  Why are we fiddling around with ISDN?

Rex Buddenberg

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25 Mar 88 09:41:19 -0500
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
Cc:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: ReChoosing gateways

     host is using G1 to communicate with a host on the destination
     ...
     Are there any rules/guidelines/standards/... as to how the host can "find"
     G2?

Please don't take this as an oversimplification.  The general rule should be
'find G2 the same way you found G1'.  In the current state of affairs, both G1
and G2 are listed in some gateway initialization file.  If you are using G1
and are dissatisfied with the service, drop it from consideration and try all
other gateways you know about.

Perhaps unix wizards can talk about multiple default gateways.

On a network which has logical addressing (ethernet, arpanet) you could
arrange to have an address which will 'always' be a gateway.  On the arpanet,
the gateway joins the group when it is up, and is removed by the PSN when it
is down.  On an ethernet, you can use IP multicast, or be a bit kluge-y and
have G2 detect that G1 is down, and begin spoofing for G1 (answering G1 ARP
as well as its own).  (WARNING: This is all "blue sky".  I have NOT tried it.)

Mike
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 01:47:59 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

Alex,

I think that I will opt for datagrams too.  The only part of the network
that you can really trust is that which you control.  It is the only
part of the network that exists to serve YOUR needs.  For this reason I
am going to want some sort of reliable transport service sitting on top
of the network.  Sure the network may seem reliable but can you always
be sure?  At least a reliable transport service can keep trying even
though the underlying virtual circuit network has done a reset on your
logical channel.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 01:57:09 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   What we REALLY need ...

>So, before you/we go off an' invent another protocol which any number of
>universities will jump on as a weekend project ...

No, I was not suggesting that we invent a new protocol.  I believe in
the KISS principle that espouses simplicity over complexity.  If it can
be done with IP and ICMP (I don't really see how since IP and ICMP were
written to be totally independent of the underlying subnet) sobeit. 
Next choice would be to use something that exists.  Better to fight the
enemy you know than the enemy you don't.  Last on the list would be to
roll a new protocol.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 10:45:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   RE: TCP/IP Checksums

In <1080@maccs.UUCP> Gordan Palameta provides a discussion of TCP/IP checksums:

 >Of course, the value of the carry bit is not accessible from a
 >higher-level language like C.  A perfectly equivalent method (very
 >suitable if your machine has 32-bit integers) is:
 >
 >  INT32 sum32, word32
 >  INT16 *word;     /* pointer to start of 16-bit words to be summed */
 >
 >  sum32 = 0;
 >
 >  for (i = 0; i < `number of 16-bit words to be summed'; i++)
 >  {
 >    `byte-swap word[i], if necessary (see comments on byte-order)'
 >    `copy word[i] to word32, zero-extended (NOT sign-extended)'
 >              /* (e.g., 0xedcb -> 0x0000edcb, not 0xffffedcb) */
 >    sum32 += word32;
 >  }
 >
 >  sum = `add the two 16-bit halves of sum32 to each other'
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
THIS ADDITION CAN RESULT IN YET ANOTHER CARRY THAT MUST BE ADDED BACK IN IF
IT OCCURS!  This simplest way to do this is to make sure that the upper 16
bits of the accumulator are zeroed before adding carries back in and performing
the carry addition twice. (Another carry cannot happen with the second addition)

 >This works, since the carry bit values for 16-bit addition of the least
 >significant 16-bit word accumulate in the most significant 16-bit word
 >of the 32-bit sum.  (This is probably what you would use on a 68020 --
 >and you can forget about byte-swapping on a 68020 as well).

It also helps that addition is commutative :-).

 >After calculating a one's complement sum, you have to take its one's
 >complement (invert all the bits) to get the actual checksum used in IP,
 >TCP, and UDP (but note that UDP treats a calculated checksum of 0x0000
 >as a special case -- see the RFC).

					Art Berggreen
					art@acc.arpa

------
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 09:54:17 GMT
From:      dannyb@kulcs.uucp (Danny Backx)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.rt
Subject:   socket library on top of TLI wanted

A few months ago, there was a discussion in comp.protocols.tcp-ip.ibmpc about
TLI versus Berkeley sockets.

Somebody said that there is a library for offering a socket interface, provided
you have TLI.
We now have TLI as a part of AIX on IBM PC RT's, and we would like to keep
using sockets - as we do on all of the other systems (4.3 and SunOS 3.4).

Can anybody tell me where to get this library (or maybe mail it to me) ?

Thanks,
	Danny

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Katholieke Universiteit Leuven 
 Tel: +32 16 200656 x 3058              |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@blekul60.BITNET         |        Belgium     

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 12:52:27 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  ReChoosing gateways

We once did a thing where we picked an Internet Address that all gateways
would respond to.  When a host did an ARP, several gateways would respond,
and the host would pick one of them (I imagine the last, but it rather
depends on the host).  If the chosen gateway died, then subsequent ARPs
would find a living one.

In ISO (by the way), we have a host to gateway configuration protocol
(called ES-IS) that has a LAN multicast addresses that means "all gateways"
or "all hosts".  When a hosts hears "all gateways", then he gets the
packet, and records the internet level address (Network Entity Title,
in ISOese).

_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 13:08:29 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

There are really two issues with regards to this VC/datagram discussion.
One is what the network does, and the other is what the host does. 
It seems to me obvious that the host wants to protect itself and provide
itself good service regardless of what the network claims to provide,
and so should run a strong transport like TCP.  It is silly to argue
that one of the virtues of VCs is that it requires less work on the
part of the host.

Ignoring hosts, however, and just considering the network layer,
the discussion is still interesting.  I like datagram in the sense
that the network isn't obligated to do sequence and guarenteed
delivery and so on, and can squash packets if it has to.  However,
I like some of the "set up" notions of VC.  These days, there are
many things that one might want to "set up" (or more appropriately,
cache) in the gateways along the path.  These include routing
information, address information (like a Landmark Address, for instance),
VISA information.  All of these things can be done without destroying
the "datagram" aspect of the network.

Some people are thinking of more sophisticated network "setup", like
rate request and assignment.  This is not datagram in the sense that
the network tells you roughly how fast you can go, but it is not
VC in that the network is happy to squash packets if it needs to.


_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 16:13:38 GMT
From:      backman@interlan.UUCP (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   TCP/UDP Checksum algorithms



	[]

	There was a discussion a while back about clever checksum
	algorithms.  Does anyone have references, examples, whatnot,
	for some speedy algorithms.  Please reply directly to me
	rather than rehashing the discussion over the network
	again.



					Larry Backman
					Micom - Interlan
					backman@interlan

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 16:29:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re:  ReChoosing gateways


    Date: Fri, 25 Mar 88 07:52:27 EST
    From: tsuchiya@gateway.mitre.org (Paul Tsuchiya)

    We once did a thing where we picked an Internet Address that all gateways
    would respond to.  When a host did an ARP, several gateways would respond,
    and the host would pick one of them (I imagine the last, but it rather
    depends on the host).  If the chosen gateway died, then subsequent ARPs
    would find a living one.

Why would you need to ARP again?  You already have the protocol address
to hardware address translation, so why do you need to get it again?
Maybe you have a very, VERY small ARP cache timeout?

This doesn't answer the poser's question though, since I think the poser
wanted to know how to rechoose at the IP level, not at the link level.

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 17:49:32 GMT
From:      dab@oliver.CRAY.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)


I feel compelled to respond to the recent explanation of the TCP/IP
checksum algorithm, because the explanation makes things harder than
they really are.

So how do you calculate the checksum?  You add up all the 16 bit words
over the data that you want to checksum, and add all the carrys back
into the sum.  When you are all done, you take the one's complement
of the final sum.

For outgoing packets, put 0 into the checksum field, calculate
the checksum, and fill it in.

For incoming packets, the checksum will calculate to 0 if the
data is correct.

That is it.  Sweet and simple.

What about machine byte order?  You can ignore it.  It doesn't matter.
That's one of the great thing about this algorithm.  Look at it
this way: as you pull the words from memory, they get byte swapped
into the register.  So, all of our sum is done byte swapped.  But
when you write the sum back out to memory, it swaps it back for you.

Another way of looking at the checksum:  it sums up all the even bytes
into one sum, and all the odd bytes into another.  All of the carries
from the even byte sum get added into the odd byte sum, and all of the
carries from the odd byte sum get added into the even byte sum.
The following table explicitly shows that the calculated checksum would be
calculated the same by bytes, Big-endian, and Little-endian byte order,
and in 16 bits or 32 bits at a time.

					Big-endian	Little-endian
byte 0/1	 0x00	 0x01		 0x0001		 0x0100
byte 2/3	 0xf2	 0x03		 0xf203		 0x03f2
byte 4/5	 0xf4	 0xf5		 0xf4f5		 0xf5f4
byte 6/7	 0xf6	 0xf7		 0xf6f7		 0xf7f6
		-----	-----		-------		-------
sum1:		0x2dc 	0x1f0		0x2ddf0		0x1F2DC

		0xdc	0xf0		0xddf0		0xf2dc
carrys:		   1       2		     2		     1
		----	----		------		------
sum2:		0xdd	0xf2		0xddf2		0xf2dd

1's comp:	0x22    0x0d		0x220d		0x0d22

cksum back
to memory:	0x22	0x0d		0x22 0x0d	0x22 0x0d


For doing it 32 bits at a time, (like 4.3BSD does):

byte 0/1/2/3	0x0001f203	0x010003f2
byte 4/5/6/7	0xf4f5f6f7	0xf5f4f7f6
		----------	----------
sum1:		0xf4f7e8fa	0xf6f4fbe8

top half:	 0xf4f7		 0xf6f4
bottom half:	 0xe8fa		 0xfbe8
		-------		-------
sum2:		0x1ddf1		0x1f2dc

		0xddf1		0xf2dc
carrys:		     1		     1
		------		------
sum3:		0xddf2		0xf2dd

1's comp:	0x220d		0x0d22

back to memory:	0x22 0x0d	0x22 0x0d


Since I'm explaining all this, let me explain a tricky point for when
your data is not contiguous.  Assume your data that you are checksuming
is in two pieces, and further that the the first chunk ends on an odd
byte boundry, and the second chunk begins on an even byte boundry.

You can calculate this in two pieces:  one checksum for each piece
of data.  Then, you swap the bytes of the second piece, and add it
into the first piece to get your final sum. (Or swap bytes on the first
piece, do the sum, and swap the bytes again. Depending on the implementation,
one or the other may be faster...)  This gives you the speed
of doing word aligned operations, and you only need to add a minimal
amount of processing.

(note: when the byte count is odd, you fill in the missing part
with zeros)

	0/1	0x00	0x01	 0x0001
	2/ 	0xf2		 0xf200
				 ------
sum1:				 0xf201

	4/5	0x03	0xf4	 0x03f4
	6/7	0xf5	0xf6	 0xf5f6
	8/	0xf7		 0xf700
				-------
sum2:				0x1f0ea

sum2:				 0xf0ea
carry:				      1
				 ------
sum3:				 0xf0eb

sum1:				 0xf201
sum3 byte swapped:		 0xebf0
				-------
sum4:				0x1ddf1

sum4:				0xddf1
carry:				     1
sum5:				0xddf2


This got a little longer than I expected, but hopefully this should
clear things up some more.
			-Dave Borman
			CRAY Research, Inc.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 18:24:21 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP protocol address space field on ProNET

It was pretty apparent to me when I did the ARP-on-AX.25 (amateur packet
radio link protocol) implementation that I should use the universe of
AX.25 packet types in the ARP protocol field.  (The only one that is relevant
is CC hex, which means "DoD IP").

Phil

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 18:45:00 GMT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   RE: TCP/IP Checksums


In <1080@maccs.UUCP> Gordan Palameta provides a discussion of TCP/IP checksums:

 >Of course, the value of the carry bit is not accessible from a
 >higher-level language like C.  A perfectly equivalent method (very
 >suitable if your machine has 32-bit integers) is:
 >
 >  INT32 sum32, word32
 >  INT16 *word;     /* pointer to start of 16-bit words to be summed */
 >
 >  sum32 = 0;
 >
 >  for (i = 0; i < `number of 16-bit words to be summed'; i++)
 >  {
 >    `byte-swap word[i], if necessary (see comments on byte-order)'
 >    `copy word[i] to word32, zero-extended (NOT sign-extended)'
 >              /* (e.g., 0xedcb -> 0x0000edcb, not 0xffffedcb) */
 >    sum32 += word32;
 >  }
 >
 >  sum = `add the two 16-bit halves of sum32 to each other'
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
THIS ADDITION CAN RESULT IN YET ANOTHER CARRY THAT MUST BE ADDED BACK IN IF
IT OCCURS!  This simplest way to do this is to make sure that the upper 16
bits of the accumulator are zeroed before adding carries back in and performing
the carry addition twice. (Another carry cannot happen with the second addition)

 >This works, since the carry bit values for 16-bit addition of the least
 >significant 16-bit word accumulate in the most significant 16-bit word
 >of the 32-bit sum.  (This is probably what you would use on a 68020 --
 >and you can forget about byte-swapping on a 68020 as well).

It also helps that addition is commutative :-).

 >After calculating a one's complement sum, you have to take its one's
 >complement (invert all the bits) to get the actual checksum used in IP,
 >TCP, and UDP (but note that UDP treats a calculated checksum of 0x0000
 >as a special case -- see the RFC).

					Art Berggreen
					art@acc.arpa

------

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 19:12:51 GMT
From:      heckard%FORD-COS1@FORD-WDL1.ARPA (Max A. Heckard)
To:        comp.protocols.tcp-ip
Subject:   (none)

******************************************************************************
					   25 March 1988
Gentlepersons:

Does anyone know of any TCP/IP product that will apply a security
classification to an outgoing datagram?  We are currently searching for
an implementation that will run on a VAX 8600 cluster or a MicroVAX II (VMS).  
In general, we would like to become aware of vendors with an active interest 
in supporting the revised IP security option (RFC 1038) without charging an 
eighth of a megabuck "for access to source code to add the process."

Your responses will be appreciated.

	Max Heckard                         heckard@ford-cos1.arpa
	Ford Aerospace Corporation
	10550 State Hwy 83, N.
	Colorado Springs, CO 80921-3603     719-594-1379

******************************************************************************

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 20:29:41 GMT
From:      jsa@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   A network you can trust

Is it really that "obvious that the host wants to protect itself and provide
itself good service regardless of what the network claims to provide,
and so should run a strong transport like TCP."?  If this were true,
wouldn't the Europeans be using TP4 over their PTT-provided X.25 nets
instead of TP0?

_________________________________________________________________
Jim Ackermann    		The MITRE Corp.
jsa@gateway.mitre.org   	7525 Colshire Dr.
703-883-5360			McLean, VA 22102 USA
_________________________________________________________________

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 20:56:41 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

Sorry, what I really should have said is that it is obvious in an
Internet environment that one needs a strong Transport.  And in
fact, the Europeans are quickly becoming TCP users.  One
can now buy TCP from something like 30 European computer manufacturers,
and they have recently comandeered a large chunk of I think Class B
space for the European Internet.
_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 21:21:40 GMT
From:      braun@drivax.UUCP (Kral)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

In article <8803141728.AA08682@sun46.darpa.mil> boesch@VAX.DARPA.MIL writes:
>
>The follow on network experiment will be called the Defense Research
>Internet (DRI). We are also working in conjunction with other Federal
>agencies, most notably National Science Foundation, to integrate our
>networking experiments with the new regional networks, the NSFNET 
>project, and other agency networks.
>

Ahem.  I would like to take this opportunity to point out that nodes in the
to-be implemented drinet.com domain will have nothing to do with the to-be
implemented Defense Research Internet :-).


-- 
kral 	408/647-6112			...{ism780|amdahl}!drivax!braun
DISCLAIMER: If DRI knew I was saying this stuff, they would shut me d~-~oxx

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 88 22:09:16 GMT
From:      braden@venera.isi.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)

The TCP/IP checksum properties were discussed early in the TCP/IP
development.  See "TCP Checksum Function Design", IEN45, by Bill
Plummer of BBN; the data was almost 10 years ago-- June 1978.

   Bob Braden
   

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 05:54:03 GMT
From:      jeremy@swatsun.uucp (Jeremy Brest)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Request for information: tcp/ip mail with vax/vms

If anyone has tried (successfully or not) to integrate Vax/VMS
machines in a tcp/ip mail environment, please let me know.  The
specifics I am interested in are what mail software was used and what
tcp/ip software.  

Related query: Does the CMU tcp/ip software allow DECnet to remain
operational? 

Thanks,

Jeremy Brest
Swarthmore College
uucp:  ...seismo!bpa!swatsun!jeremy
CSNet: jeremy@swatsun.swarthmore.edu
ARPA:  jeremy%swatsun.swarthmore.edu@relay.cs.net

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 1988 11:06-EST
From:      CERF@A.ISI.EDU
To:        dalcs!thompson@UUNET.UU.NET
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: ARP hardware field
Mr. Thompson,

You may already have received other replies on the "status of RFCs" but
just in case... These are indeed Requests for Comment. Only a few of
the RFCs are adopted as Internet Standards; those that are will be 
identified by Jon Postel on the instruction of the Internet Activities
Board which is chaired by Dave Clark (MIT Lab for Computer Science).

There is an official documents list which is published as an RFC and
updated periodically by Jon Postel. Perhaps Jon will be good enough
to remind us of the RFC number of the most recent of these summaries.

Vint Cerf
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 07:34:59 GMT
From:      SAPPHO@SRI-NIC.ARPA (Lynn Gazis)
To:        comp.protocols.tcp-ip
Subject:   Re: Add to mailing list

I have added tcp-ip@Ultra.COM to the tcp-ip mailing list.
-------

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 09:34:38 GMT
From:      benoni@ssc-vax.UUCP (Charles L Ditzel)
To:        comp.protocols.tcp-ip,comp.windows.misc
Subject:   Re: Sun servers

In article <208@megalon.UUCP>, digi@megalon.UUCP (Klaus Altenburg) writes:
> My company is also interrested in using workstations (like sun's) for CASE.
> Here in Germany a reasonable sun-server costs about 35.000 - 40.000 DM.
 Usually it's the reverse.
> 
> 	- Is it right, that we need only a unix-machine with a working
> 	  NFS to run diskless sun-workstations ?
I believe their are now versions of NFS that allow diskless Sun's to boot
off of Vaxes and other machines. I could be wrong...it might still be
pending release.  Naturally diskless Suns can boot off of low-end
workstations like the Sun 3/60 (it's slower).  

> 	- is there software to use 386-based systems as workstations for CASE ?
When Sun's 386 machine (see InfoWorld and ComputerWorld) comes out the answer
is yes.  Look at Sun's NSE package (it works with CADRE, Interleaf etc)

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 16:06:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ARP hardware field

Mr. Thompson,

You may already have received other replies on the "status of RFCs" but
just in case... These are indeed Requests for Comment. Only a few of
the RFCs are adopted as Internet Standards; those that are will be 
identified by Jon Postel on the instruction of the Internet Activities
Board which is chaired by Dave Clark (MIT Lab for Computer Science).

There is an official documents list which is published as an RFC and
updated periodically by Jon Postel. Perhaps Jon will be good enough
to remind us of the RFC number of the most recent of these summaries.

Vint Cerf

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 16:19:26 GMT
From:      kohjin@marina.JUICE (Kohjin Yamada)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: PC/AT LANCE Card

In article <20842@amdcad.AMD.COM> toms@amdcad.AMD.COM (Tom Slykhouse) writes:
>
>Advanced Micro Devices has completed development on a Public Domain
>Ethernet board for the PC/AT's and Clones, based on our LANCE controller.
>Manuals, schematics and artwork are available for this product. 
>
>We are additionally considering porting several of the common
>communications packages to this board.  One possibility is KA9Q
>TCP/IP.  If anyone on the net would like this package ported, or would
>prefer another package please respond to me with EMail. 

Hi, Tom.

I'm really interested in your offer.
We've been looking for the Ethernet board for the XeniX use.
Would like to port it to KA9Q TCP/IP to communicate with Sun-3/50.
We have ported KA9Q TCP/IP package to XeniX and Sun-3 OS recentlly and operating
the net everyday.

Verry sorry that I don't have any chance to put a Email to you through this net
at present time.
Would you mind if I ask to send the detail to the following address?
Or would you mind to reply me how to reach you in an other way?

Mr. Kohjin Yamada
504-55 Shimo Yamaguchi, Hayama, Kanagawa, Japan

I've posted to reply to your offer before but ther're some chance of the lost
article, so I try once more.
Thanks in advance.
-- 
Kohjin Yamada, JR1EDE        
      *----/----*          JUICE: kohjin%marina.juice@junet
    Q-----S------T         AMPR:  kohjin@jr1ede.marina.ampr [44.129.20.128]
  *------/|-------*        AsiaNet: JR1EDE @ JR1EDE (SysOp @ AsiaNet.Tokyo)

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 19:55:35 GMT
From:      grr@cbmvax.UUCP (George Robbins)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

In article <670@tetra.NOSC.MIL> budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) writes:
> 
> Maybe I'm missing something, but:
 ...
> Looks to me that 500 nodes times 20 km multiplies out to a pretty
> decent regional backbone -- internet a half dozen of these and you've
> got the country covered.  Why are we fiddling around with ISDN?

Yes, and who do you have lined up to pay for a little fiber cable
terminating at your residence?  ISDN gives hopes of getting reasonable
bandwidth almost anywhere a reasonable cost, whereas fiber will
probably be limited to backbone applications and connecting super
computer ($$$) centers.

-- 
George Robbins - now working for,	uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 88 20:05:02 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   European interest in TCP

At a recent trade show where we (Sirius Systems) announced our
implementation of TCP/IP for the Convergent Technologies workstation
product line I was surprised at the level of interest exhibited by the
European attendees.  The consensus was that OSI really wasn't happening
and that they were all planning to go the TCP/IP route.  I guess that
the ISO/OSI hard-sell has created a market that only TCP can currently
fill.

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 88 03:35:47 GMT
From:      sauer@auschs.UUCP (Charlie Sauer)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.sys.ibm.pc.rt
Subject:   Re: SLIP on the IBM RT (w/AIX) or Apollo workstations

In article <55@hrsw2.UUCP>, bakken@hrsw2.UUCP (David E. Bakken) writes:
> 
> Does anyone know of a port of SLIP to the IBM RT (running AIX) or
> the Apollo workstations?  If so, please email me with the 
> details.  Thanks!!!!

SLIP is in AIX/RT 2.2.  2.2 is scheduled to be available in June.
-- 


Charlie Sauer   Dept D18, Bldg 802      aesnet: sauer@auschs
                IBM AES/ESD, Austin, TX   vnet: SAUER at AUSVM6
                (512) 823-3692           csnet: ibmaus!sauer@EMX.UTEXAS.EDU
                                          uucp: ut-sally!ut-emx!ibmaus!sauer

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 88 04:49:20 GMT
From:      mshiels@watmath.waterloo.edu (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP protocol address space field on ProNET


Is it possible to get the codes that PRONET does use??
-- 
  Michael A. Shiels (MaS Network Software)
  mshiels@watmath.waterloo.EDU
UUCP: ...path...!watmath!mshiels

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Mar 88 10:53
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        jsa <@nss:jsa@gateway.mitre.org>
Cc:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: A network you can trust
 
Speaking as a European who has access and is active in using both X25
nets and Internet -
 
X25 service within the UK appears to be very satisfactory. That is to say
the 'end-to-end' network service provided by BT on PSS is such that I
really have no memory of corrupted info, slow response etc. It could be
said that I am paying a 'price' for this, but I appear to have no
difficulty in seeing the price for this quality of service as other
than cost effective.
 
International X25 to Europe again appears very satisfactory. Indeed I
am using that as a means of extending the Internet from RSRE to my
European partners. Again this appears to be cost effective for the
level of our current requirement. Clearly there is a traffic level
at which a leased line is more cost effective - what that level is
with 'operational' traffic is part of the experiment.
 
I have no direct experience of using X25 to the US (yet) but it is
claimed to be less than satisfactory because it is necessary for BT
to downgrade its facilities to match the lowest common facilities of US X25
service providers. Fastest line speed (I think) is 9.6kb, window of 2,
cant extend packet size. 
 
The Internet works very well when lightly used, but standing here in
Europe working via a satellite path shows that too many of the Internet
solutions are local (CONUS) optimisations. These problems are now
well recognised in the specific attention of individuals eg Van J and
his TCP work, and a number of TF's.
 
I note with great interest that some folks in BBN and Mitre (who I
have great respect for the many scars they have acquired from years of
front-line work) have some degree of the so called 'European' view.
 
John Laws
Distibuted Information Systems Div
RSRE
Malvern UK
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Mar 88 11:25
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        Brian Lloyd <@nss:rochester!cci632!rlgvax!dolqci!irs3!wb6rqn!brian@rutgers.edu>
Cc:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: European interest in TCP
 
OSI is very much happening in Europe. It is true that not all the
'layers' are complete in implementation or definition. But there is
just as much faith in Europe that OSI will deliver as there is faith
in the US that TCP/IP etc will deliver.
 
Any company that ignores the momentum for OSI in Europe will not
be well placed for an expanding market in the early 90's. Specifically
within UK MOD, UK Other Government Departments, EEC and NATO the
clear policy directive is to procure systems to the OSI standards. This
policy was not undertaken lightly.
 
Yes TCP/IP is readily available in many products. Yes it is selling.
It is not selling because the buyer knows or cares that its TCP etc.
The buyer is buying a product and facility. The fact that many of
these TCP implementations are local optimisations will restrict their
effective use to local communities. The experience will educate the
buyer to better understand and define his requirement if his needs
are more than local.
 
John Laws
Distributed Information Systems Div
RSRE
Malvern UK
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 1988 11:49-EST
From:      Alessandro.Forin@SPEECH2.CS.CMU.EDU
To:        csl!hercules!auerbach@spam.istc.sri.com  (Karl Auerbach)
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: Off loading the protocol

> Date: 19 Mar 88 18:18:09 GMT
> From: csl!hercules!auerbach@spam.istc.sri.com  (Karl Auerbach)
> Subject: Re: Off loading the protocol
> Sender: tcp-ip-request@sri-nic.arpa
> To: tcp-ip@sri-nic.arpa
>
> Just curious: How does the shared memory paradigm handle the case where
> the machines are of different memory architectures with different
> data representations?

As far as I know, my system (Agora) is the only one that specifically
addresses your question.  A description of our work will appear in the
August issue of IEEE Trans. Computer, and you can find also a paper now
in the proceedings of the ASPLOS-II conference (it is in the list I
posted earlier to the tcp-ip list).

The answer is basically to keep around at runtime data type
descriptors, so that you can translate a datum coming from an
incompatible machine into the appropriate local representation.  

This is much the same problem you have with the description of data
inside messages for any remote procedure call package (Sun, Apollo,
Xerox, Mach-MiG, etc..).  It is in no way specific to the shared memory
paradigm.

Sorry for the delay in answering...
sandro-
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 88 16:49:00 GMT
From:      Alessandro.Forin@SPEECH2.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Off loading the protocol


> Date: 19 Mar 88 18:18:09 GMT
> From: csl!hercules!auerbach@spam.istc.sri.com  (Karl Auerbach)
> Subject: Re: Off loading the protocol
> Sender: tcp-ip-request@sri-nic.arpa
> To: tcp-ip@sri-nic.arpa
>
> Just curious: How does the shared memory paradigm handle the case where
> the machines are of different memory architectures with different
> data representations?

As far as I know, my system (Agora) is the only one that specifically
addresses your question.  A description of our work will appear in the
August issue of IEEE Trans. Computer, and you can find also a paper now
in the proceedings of the ASPLOS-II conference (it is in the list I
posted earlier to the tcp-ip list).

The answer is basically to keep around at runtime data type
descriptors, so that you can translate a datum coming from an
incompatible machine into the appropriate local representation.  

This is much the same problem you have with the description of data
inside messages for any remote procedure call package (Sun, Apollo,
Xerox, Mach-MiG, etc..).  It is in no way specific to the shared memory
paradigm.

Sorry for the delay in answering...
sandro-

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 88 18:53:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: A network you can trust


 
Speaking as a European who has access and is active in using both X25
nets and Internet -
 
X25 service within the UK appears to be very satisfactory. That is to say
the 'end-to-end' network service provided by BT on PSS is such that I
really have no memory of corrupted info, slow response etc. It could be
said that I am paying a 'price' for this, but I appear to have no
difficulty in seeing the price for this quality of service as other
than cost effective.
 
International X25 to Europe again appears very satisfactory. Indeed I
am using that as a means of extending the Internet from RSRE to my
European partners. Again this appears to be cost effective for the
level of our current requirement. Clearly there is a traffic level
at which a leased line is more cost effective - what that level is
with 'operational' traffic is part of the experiment.
 
I have no direct experience of using X25 to the US (yet) but it is
claimed to be less than satisfactory because it is necessary for BT
to downgrade its facilities to match the lowest common facilities of US X25
service providers. Fastest line speed (I think) is 9.6kb, window of 2,
cant extend packet size. 
 
The Internet works very well when lightly used, but standing here in
Europe working via a satellite path shows that too many of the Internet
solutions are local (CONUS) optimisations. These problems are now
well recognised in the specific attention of individuals eg Van J and
his TCP work, and a number of TF's.
 
I note with great interest that some folks in BBN and Mitre (who I
have great respect for the many scars they have acquired from years of
front-line work) have some degree of the so called 'European' view.
 
John Laws
Distibuted Information Systems Div
RSRE
Malvern UK

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 88 19:25:00 GMT
From:      LAWS@rsre.mod.UK (John Laws, on UK.MOD.RSRE)
To:        comp.protocols.tcp-ip
Subject:   Re: European interest in TCP


 
OSI is very much happening in Europe. It is true that not all the
'layers' are complete in implementation or definition. But there is
just as much faith in Europe that OSI will deliver as there is faith
in the US that TCP/IP etc will deliver.
 
Any company that ignores the momentum for OSI in Europe will not
be well placed for an expanding market in the early 90's. Specifically
within UK MOD, UK Other Government Departments, EEC and NATO the
clear policy directive is to procure systems to the OSI standards. This
policy was not undertaken lightly.
 
Yes TCP/IP is readily available in many products. Yes it is selling.
It is not selling because the buyer knows or cares that its TCP etc.
The buyer is buying a product and facility. The fact that many of
these TCP implementations are local optimisations will restrict their
effective use to local communities. The experience will educate the
buyer to better understand and define his requirement if his needs
are more than local.
 
John Laws
Distributed Information Systems Div
RSRE
Malvern UK

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 01:08:35 GMT
From:      bc@halley.UUCP (Bill Crews)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.rt
Subject:   Re: socket library on top of TLI wanted

In article <1214@kulcs.kulcs.uucp> dannyb@kulcs.uucp (Danny Backx) writes:
>Somebody said that there is a library for offering a socket interface, provided
>you have TLI.
 
>Can anybody tell me where to get this library (or maybe mail it to me) ?

The one I am aware of was developed by Wollongong.  I don't know if they offer
this as a product.  As far as I know, they do not.  I don't know of any
freebies out there.  Anyone?

-bc
-- 
Bill Crews                                   Tandem Computers
bc@halley.UUCP                               Austin, Texas
..!rutgers!im4u!halley!bc                    (512) 244-8350

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 01:33:42 GMT
From:      att-cb!clyde!watmath!utgpu!utzoo!yunexus!maccs!gordan@ucbvax.Berkeley.EDU  (gordan)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Checksums (was Re: Ping, checksum algorithm?)
In article <1080@maccs.UUCP> I wrote:

[A verbose description of one's complement checksums]


Thanks to Mike Brescia, Dave Borman, and Bill Westfield for setting me
straight on this...

Machine byte-order doesn't matter for purposes of doing one's complement
checksums.  The quickest way to see this is to note that carries from
the least significant byte get added to the MSB (as in ordinary
addition), and carries from the MSB get added to the LSB (since we add
the hardware carry bit into the sum).  Because of this symmetry, the
exact same checksum algorithm can be used on both big-endian and
little-endian machines.

A concise definition of one's complement checksums (from Dave Borman):

--  So how do you calculate the checksum?  You add up all the 16 bit
--  words over the data that you want to checksum, and add all the
--  carrys back into the sum.  When you are all done, you take the one's
--  complement of the final sum.

--  For outgoing packets, put 0 into the checksum field, calculate the
--  checksum, and fill it in.

--  For incoming packets, the checksum will calculate to 0 if the data
--  is correct.

--  That is it.  Sweet and simple.


From Bob Braden:


--  The TCP/IP checksum properties were discussed early in the TCP/IP
--  development.  See "TCP Checksum Function Design", IEN45, by Bill
--  Plummer of BBN; the date was almost 10 years ago-- June 1978.


I suppose the only question I have is whether this document is readily
available... is it part of the standard set of RFCs available from the
DDN NIC?



The corrected checksum info here is posted for the benefit of all the
clueless folks out in bangland (like myself), with apologies to the
the rest of you (I guess this group is top-heavy with gurus).


-- 
Many Americans work side by side with space
aliens who look human -- but you can spot
these visitors by looking for certain               Gordan Palameta
tip-offs, say experts.                              mnetor!maccs!gordan
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Mar 88 9:34:24 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        Paul Tsuchiya <tsuchiya@GATEWAY.MITRE.ORG>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  A network you can trust
Paul,

I think you are mixing cause and effect.  It is only "obvious in an Internet
environment that one needs a strong Transport" because of the deliberate,
conscious decision made in designing the DoD internet to require that every
connected system would use a strong Transport.  A different internet would have
been built if some other decision had been made about the strength of one's
Transport, and then, no doubt, some other conclusion would be obvious.

My suggestion was that as we begin to think about the design of the next
generation of networks we re-consider this very decision.  The suggestion was
"inspired" by the recent messages about off loading protocol processing, and
about having a communication channel you trust as much as you trust your disk
drive channel.  I believe that we can choose to decide to require any level of
reliability we want (short of absolute perfection) from the next generation
internet.  Any point in the spectrum of possibilities will have advantages and
disadvantages, and will require more or less protocol processing in the
connected systems.  I do not believe the choice of operating point is strongly
related to the number of next-generation networks which constitute the next-
generation internet as Vint Cerf suggested; the constituent networks always
have to be engineered to play by the rules.

Cheers,
Alex McKenzie
 
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 05:36:51 GMT
From:      jh@tut.fi (Juha Hein{nen)
To:        comp.protocols.tcp-ip
Subject:   Re: European interest in TCP

In article <8803261505.AA04812@wb6rqn.UUCP> brian@wb6rqn.UUCP (Brian Lloyd) writes:
>European attendees.  The consensus was that OSI really wasn't happening
>and that they were all planning to go the TCP/IP route.  I guess that
>the ISO/OSI hard-sell has created a market that only TCP can currently
>fill.

Pretty much a correct observation.  The POLITICAL plan is to go the
connection oriented (X.25) OSI route that doesn't care about local
area networks (it only cares about the profits of PTT monopolies). So
if you want to build a LAN and connect it to another LAN what else
have you got except TCP/IP?
-- 
	Juha Heinanen
	Tampere Univ. of Technology
	Finland
	jh@tut.fi (Internet), tut!jh (UUCP)

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 1988 13:34-EST
From:      CERF@A.ISI.EDU
To:        mckenzie@LABS-N.BBN.COM
Cc:        tsuchiya@GATEWAY.MITRE.ORG, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  A network you can trust
Alex,

I was trying to react to your single network language "engineer the network"
because the internet will involve many nets and administrations. To the extent
we are able to produce common engineering objectives and stick with them, this
need not be an impediment, but it is almost always harder to engineer a 
collection of systems than a single one.

I also believe that some form of end/end reliability will be needed, whether
it is explicitly visible to the host or process software or not. Even if
the reliability features are off-loaded on a peripheral controller board,
they'd still be part of the architecture. 

I'm not sure whether we are having a disagreement or not.

Vint
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 14:34:24 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

Paul,

I think you are mixing cause and effect.  It is only "obvious in an Internet
environment that one needs a strong Transport" because of the deliberate,
conscious decision made in designing the DoD internet to require that every
connected system would use a strong Transport.  A different internet would have
been built if some other decision had been made about the strength of one's
Transport, and then, no doubt, some other conclusion would be obvious.

My suggestion was that as we begin to think about the design of the next
generation of networks we re-consider this very decision.  The suggestion was
"inspired" by the recent messages about off loading protocol processing, and
about having a communication channel you trust as much as you trust your disk
drive channel.  I believe that we can choose to decide to require any level of
reliability we want (short of absolute perfection) from the next generation
internet.  Any point in the spectrum of possibilities will have advantages and
disadvantages, and will require more or less protocol processing in the
connected systems.  I do not believe the choice of operating point is strongly
related to the number of next-generation networks which constitute the next-
generation internet as Vint Cerf suggested; the constituent networks always
have to be engineered to play by the rules.

Cheers,
Alex McKenzie
 

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 15:06:19 GMT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

Alex,

I knew I would regret being so arrogant.

I don't disagree with you with regards to rethinking how the host
views the internet.  I especially feel this way with regards to routing
paradigms.

However, if we make the host think that it sees memory over the
wire, then the thing that it is directly over the wire (the first gateway,
or the front-end, or whatever), will have to have strong transport.
I guess I haven't quite defined what I mean by strong transport here.
I don't necessarily mean something exactly like TCP with windowing and
all, but something that does essentially the same job.

_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 16:11:30 GMT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   ARP protocol address space field on ProNET

Well, we keep a copy in all the manuals, but I'll post it anyways,
since some of those are getting dated.  Quite a few proprietary
(customer) protocols are supressed in this list, sorry.  At least
we'll post most of it, unlike Xerox/ANSI on Ethernet.

Proteon ProNET-10/80 data link types:
1	IP
2	IP with trailing headers
3	Address Resoloution Protocol
4	Proteon HDLC
5	VAX Debugging Protocol (MIT)
10	Novell NetWare
11	Vianetix
12	PUP
13	Watstar protocol (University of Waterloo)
14	XNS
15	Diganostics
16	Echo protocol (link level)
17	Banyon Vines
20	DECnet (DEUNA Emulation)
21	Chaosnet
23	IEEE 802.2 or ISO 8802/2 Data Link
24	Reverse Address Resolution Protocol
29	TokenVIEW-10

Just because a protocol is on this list does not mean that there is
any implementation of it on ProNET.

Of these, protocols 1, 14, and 20 are the only ones that have ever
been seen in ARP packets to my knowledge.

For reference, the header is (one byte/line):

	destination hardware address
	source hardware address
	data link header version (2)
	data link header protocol number
	data link header reserved (0)
	data link header reserved (0)

Some protocols have been known to tuck stuff in the reserved fields.

Those who need a protocol number on ProNET-10/80 should contact me
(jas@proteon.com).

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 17:39:46 GMT
From:      hscfvax!mohamed@husc6.harvard.edu  (Mohamed_el_Lozy)
To:        tcp-ip@sri-nic.arpa
Subject:   Reviews articles on network security
Are there any journal articles that review the field of network security?

Thanks
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 18:34:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A network you can trust

Alex,

I was trying to react to your single network language "engineer the network"
because the internet will involve many nets and administrations. To the extent
we are able to produce common engineering objectives and stick with them, this
need not be an impediment, but it is almost always harder to engineer a 
collection of systems than a single one.

I also believe that some form of end/end reliability will be needed, whether
it is explicitly visible to the host or process software or not. Even if
the reliability features are off-loaded on a peripheral controller board,
they'd still be part of the architecture. 

I'm not sure whether we are having a disagreement or not.

Vint

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 18:59:08 GMT
From:      VAF@SCORE.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)


    The TCP/IP checksum properties were discussed early in the TCP/IP
    development.  See "TCP Checksum Function Design", IEN45, by Bill
    Plummer of BBN; the data was almost 10 years ago-- June 1978.

       Bob Braden

Are there references to IEN45 in the IP/TCP/UDP specs? If not, there probably
should be. As someone who once was looking for the definition of the checksum
algorithm, I can say that a pointer to IEN45 would have been useful.

	Vince Fuller, Stanford Networking
-------

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 21:08:37 GMT
From:      shan@mcf.UUCP (Sharan Kalwani)
To:        comp.sys.dec,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   LAN Hardware/Software advice needed

Dear Fellow Netters,

Well... it looks like we'll be getting a VMS system here (most likely
a microVAX-II). I already run a VAX-11/750 with 4.3bsd +NFS on it,
plus a number of IBM PC's(60) and growing number of Mac SEs. My questions
are :

(i)	I would like to run Ethernet between the microVAX and the
	11/750. Which ethernet controller should i buy for the uVAX?
	I already have a DEUNA on the 750 but might trade it in for
	a DELUA.

(ii)	How can I set things up so that folks on the uVAX logon to the
	UNIX machine and vice-versa? I think I would like to get TCP/IP
	and all the rlogin/telnet/ftp,etc. stuff for the uVAX. Which is the
	best (or recommended) options to buy?
	Will the uVAX-II be able to support all this? Will VMS block
	ethernet logins?

(iii)	How can the IBM PC's and Mac SEs also do the rlogin/telnet/ftp,etc.,
	action with either of the UNIX VAX or VMS uVAX? How should
	be go about doing this? Money is no object but of course
	a few hundred feet above the ground is our limit (read $50,000
	to $150,00 is my anticipated budget :-). Feel free to share your
	expreriences and flights of fancy. I'm all ears! 

(iv) 	This was added as an after thought, but we have an HP 3000
	as well. How can we network that to the configuration above?

If I need to be specific please let me know I can supply details.
If this needs to be included in other groups, do modify the newsgroup header.
All advice appreciated.

-- 
sharan "alf" kalwani		     internet:  shan%mcf.uucp@umix.cc.umich.edu
usenet:     ...!{ihnp4!mibte, uunet!umix, pur-ee!iuvax, ucbvax!mtxinu}!mcf!shan
dec enet: decwrl::"umix.cc.umich.edu!mcf!shan" bitnet: mcf!shan@psuvax1.psu.edu
% setenv DISCLAIMER "`cat /your/favorite/disclaimer.h`"

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 23:46:31 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)

Several have pointed out that IEN45 on checksums is not online. It is true.
Jon Postel and I are getting that fixed, and as soon as it is fixed, I
will send a short note to this list.

IEN45, while interesting, does not contain the nifty fact that Phil Karn
pointed out: the checksum is invariant to arbitrary byte permutations.
I don't know where that is documented; it was pointed out to me in 1983
by Peter Higginson of University College London, and enabled me to speed
up the IBM MVS ACP checksum routine by about a factor of 2.  This is
probably one of the great underground tricks in TCP implementations
(or do they teach it to undergraduates these days??).

We should turn some of the recent messages on this topic into an RFC, or
include them as an Appendix to the Host Requirements RFC which is now
being drafted. Any volunteers to write about checksum implementations? 

Bob Braden

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 88 23:51:21 GMT
From:      budden@tetra.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

In article <3528@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
>In article <670@tetra.NOSC.MIL> budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg) writes:
>> Looks to me that 500 nodes times 20 km multiplies out to a pretty
>> decent regional backbone -- internet a half dozen of these and you've
>> got the country covered.  Why are we fiddling around with ISDN?
>
>Yes, and who do you have lined up to pay for a little fiber cable
>terminating at your residence?  ISDN gives hopes of getting reasonable
>bandwidth almost anywhere a reasonable cost, whereas fiber will
>probably be limited to backbone applications and connecting super
>computer ($$$) centers.
>
Who do you know who has a 56k trunk in his home now?  I was talking
about backbone connectivity (where the fiber is already laid),
not local loop.

By the way, at least some local phone companies are providing local
loop fiber now.  They figure it is more cost effective, considering
growth and weather resistance.

B

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 00:11:35 GMT
From:      chris@ACC-SB-UNIX.ARPA (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Wang TCP/IP

Afternoon All,
		I happened to receive a inquiry from a customer regarding 
getting his WANG system talking to his TCP/IP network and the best I could
do was hem and haw about what I had read about a month ago. Basically, WANG still
had not delivered a solution. Has this changed to any significant degree?
Does anyone out there have any real hardware, hands-on experiences they can
share(please, no vapor-ware stories. I've seen more than my share of WANG
bashing done here.)
		As always, any input would be truly appreciated!
				Chris VandenBerg
				ACC
				chris@acc-sb-unix.arpa

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 00:33:30 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

Summary: Alternatives to ASLIP, SLIP, KISS, et al...
	 let add in some reliability and universality to solving the problem.
References: <625@sun.soe.clarkson.edu>


 I remember seeing some articles here on the net regarding the
use of these somewhat homegrown solutions to the problem of
packet data transmission (your choice of protocol suite) over
an asynchronous link.  As part of the work that our non-profit
Amateur Radio group (the Radio Amateur Telecommunications Society)
is doing on OSI protocols we have developed a package for 
transmitting generic HDLC frames over an asynchronous interface.

This package is based on the Asynchronous Framing Technique
that was published by Toby Nixon from D. C. Hayes.  This
proposal has been well received in various ISO workgroups and
basically offers a couple of reasonable variations.

The first is basic framing, transparency, and error checking.
This mode uses two characters for special purposes.  The
framing character (7EH) and the escape character (7DH) are
all that require special handling.  In the normal data flow
you prefix a 5EH (corresponding to a 7EH) or a 5DH
(corresponding to a 7DH) with a 7DH.  The appearance of a 7EH
uniquely signals a frame start or end.  This mode also
contains a feature not found in SLIP (and I believe ASLIP):
ERROR CHECKING.  There is a check calculation (I forget what
type) on every frame.  

The second mode adds the X-ON and X-OFF characters to the list
of characters transmitted transparently.

The third adds in most control characters.

There are several other options like 7-bit character
transparency and packet forwarding characters which can be
added AFTER the flag to force the packet to be forwarded.

In any case, our software was written by John Howell, N2FVN
and includes source code, source for some MS-DOS drivers and
test programmes, binaries for everything for MS-DOS and a lot
of GOOD documentation.

I will post this code to the net in a few days.  It will be
posted in the same sequence as the RATS Open Systems
Environment (ROSE, formerly COSI) software to the
comp.sources.misc and comp.sources.ibmpc newsgroups.

I will also post an announcement here for those who need to
be signalled to the availability of the software.



Thanks,
            J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office)     201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 04:13:32 GMT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP checksum byte-swap invariance

The invariance follows (I am tempted to say `is intuitively obvious',
but I suppose that would be teasing) from the fact that carries are
added back in at the low end of the sum as one goes along.  To
visualise this, imagine the bits arranged in a ring.  Note that the
ring is rotation independent---each bit depends only upon itself and
its nearest clockwise neighbour (in the figure below)---and that a byte
swap is simply an eight-bit rotation.

               1  0  15
             2         14
           3             13
          4               12
           5             11
             6         10
               7  8  9

(Apologies to those with proportionally spaced fonts.)  The only
time an orientation is imposed upon this ring is when it is placed
in a TCP or IP header, so this is the only time the machine's
byte sex must affect the calculation.

(As far as I know, I came up with this explanation myself.  It
seems obvious enough that someone else should have used it before.)

Chris

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88 10:40:43 EST
From:      tsuchiya@gateway.mitre.org (Paul Tsuchiya)
To:        tcp-ip@sri-nic.arpa
Subject:   world record
 Read this on internal MITRE mail, thought I might pass it on........
     
   David is a 7 year old boy who is dying from cancer.
   Before he does, he has a dream of one day being in the Guiness Book of
   Records for the person who has had the most postcards sent to him.
   If you would like to help David achieve his dream, all you have to do is send
   a postcard to him as soon as possible.
   Send to :
              David
              c/o Miss McWilliams
              St. Martin de Porres Infant School
              Luton,
              Bedfordshire
              England       **DON'T FORGET TO SIGN YOUR NAME**


_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________


-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88 14:41:10 -0500
From:      dan@WILMA.BBN.COM
To:        Paul Tsuchiya <tsuchiya@gateway.mitre.org>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: world record
There was a lengthy discussion of this message on the ETHICS-L mailing
list.  The consensus was that it was probably a hoax, based on (among
other things) the fact that the Guinness Book of Records has no category
for "most postcards received".  Some posters warned against overloading
local P.O.s, as happened in the past (this is apparently not the first
time this message has gotten around).

Sorry to disappoint everybody...

	Dan
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88 11:59:05 EST
From:      David Quarterman <DLQ%UGA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP discussion list <tcp-ip@sri-nic.arpa>
Subject:   Domain Nameservers
Here at the University of Georgia we are setting up a TCP based network.
The need for a Domain Nameserver has arisen.  I have looked for on which
would run on an IBM PC/AT or similiar machine.  So far I have not found
one.

What options are available?  The only ones I've found so far are a SUN
workstation, a MicroVax running Berkley Unix, or some other small system
Running Unix.

Currently we do not have an Unix machine in the Computer center.

Thank you for your assistance.
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88 12:49:18 EST
From:      bzs%bu-cs.bu.edu@buita.BU.EDU (Barry Shein)
To:        tsuchiya@gateway.mitre.org
Cc:        tcp-ip@sri-nic.ARPA
Subject:   world record

> Read this on internal MITRE mail, thought I might pass it on........
>     
>   David is a 7 year old boy who is dying from cancer.

Bing bing bing...Red alert red alert

Almost certainly a hoax, this particular hoax is covered by Jan
Brunveld (sp?) in one of his books on urban legends (stories that go
around and tons of people believe to be true but turn out to have
little or no factual basis). Classic examples: Alligators in the NY
Sewer system, Mrs Fields Cookie recipes (allegedly being given out
because someone misunderstood a price for them, "two-fifty", over the
phone and found a $250 charge on the credit card bill, variation on
the Red Velvet cake story), tax simplification and user-friendly
computer systems (:-) etc.

Usually this starts a flurry of attempts to show that this particular
instance of the hoax is true, usually just more word of mouth
information purporting to be true ("I have a friend who *called*
Guiness and they said it was true..."), usually just more hype.

	-Barry Shein, Boston University
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88 17:08:57 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tsuchiya@gateway.mitre.org
Cc:        tcp-ip@sri-nic.arpa
Subject:   Re: world record
> *Excerpts from: 29-Mar-88 world record Barry Shein@buita.BU.EDU (1034)*

> Almost certainly a hoax, this particular hoax is covered by Jan
> Brunveld (sp?) in one of his books on urban legends (stories that go> around
> and tons of people believe to be true but turn out to have
> little or no factual basis).
That's Jan Brunvand.

Drwe
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88  14:31:42 EST
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CUNYVM.CUNY.EDU>
To:        dlq@uga
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Domain Nameservers
> Here at the University of Georgia we are setting up a TCP based network.
> The need for a Domain Nameserver has arisen.  I have looked for on which
> would run on an IBM PC/AT or similiar machine.  So far I have not found
> one.
>
> What options are available?  The only ones I've found so far are a SUN
> workstation, a MicroVax running Berkley Unix, or some other small system
> Running Unix.
>
> Currently we do not have an Unix machine in the Computer center.
>
> Thank you for your assistance.

FTP Software is selling a domain name server that runs on a PC under DOS.
We've ordered a copy, but the paperwork is still in progress.  Therefore
I have no experience to report.

Wollongong does have name server support in their VMS product.  Someone
here is bringing up one of that flavor.

We are very interested in the PC option, as we would like to distribute
the responsibility for name service out to our subdomains.
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Mar-88 15:17:27 EST
From:      robert@hcrvx2.UUCP (Robert Tsui)
To:        comp.protocols.tcp-ip
Subject:   message to Amit Joshi, asjoshi (Turbo C verson of KA9Q)

*******
I hope I don't offend anyone by posting this here, I have run out
of choices.

asjoshi (Amit Joshi),

I have tried e-mailing you the following mail but it keeps bouncing
back.  I am posting here to this newsgroup and hope that you can
see it and respond to my request.  Thank you.
*******

I heard that you have converted Phil Karn's KA9Q into Turbo C 
and I'm very much interested in getting a copy of it.  I will appreciate
if you can email me a copy.  Thank you in advance for taking care of
my request.

Robert





-- 
----
Robert Tsui	{utzoo,utcsri,ihnp4}!hcr!robert (UUCP)
HCR Corporation	(416)922-1937

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Mar 88 20:22:15 EST
From:      Nick Gimbrone <NJG@CornellA>
To:        Frank Kastenholz <KASTEN@MITVMA.MIT.EDU>
Cc:        TCP/IP List <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: ReChoosing gateways
>host is using G1 to communicate with a host on the destination
...
>Are there any rules/guidelines/standards/... as to how the host can
>"find" G2?
We run the IBM product for VM (FAL) and have thought about this same
problem. In this case the package is configured with but one "default"
gateway. Several alternatives seem to exist (perhaps we'll do one one of
these days). One could build a list of "default" gateways and if you
note G1 isn't talking start using G2 (G3, G4, etc). You could even add
active steps to look for G1 not talking (ping it once in a while?).
Another alternative is to "listen" to whatever internal routing protocol
is used on the LAN. For us we use lots of RIP, which talks via
broadcasts. This makes it easy for any host that cares to to "listen in"
on what the RIPers are saying. The host can then act accordingly for
all their routing decisions.
-njg
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 16:59:05 GMT
From:      DLQ@UGA.BITNET (David Quarterman)
To:        comp.protocols.tcp-ip
Subject:   Domain Nameservers

Here at the University of Georgia we are setting up a TCP based network.
The need for a Domain Nameserver has arisen.  I have looked for on which
would run on an IBM PC/AT or similiar machine.  So far I have not found
one.

What options are available?  The only ones I've found so far are a SUN
workstation, a MicroVax running Berkley Unix, or some other small system
Running Unix.

Currently we do not have an Unix machine in the Computer center.

Thank you for your assistance.

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 19:01:06 GMT
From:      steiner@athena.mit.edu  (Jennifer Steiner)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Reviews articles on network security
In article <547@hscfvax.harvard.edu> mohamed@hscfvax.harvard.edu
(Mohamed_el_Lozy) writes:
>Are there any journal articles that review the field of network
>security?

A good survey can be found in:

"Security Mechanisms in High-Level Network Protocols"
by Victor L. Voydock and Stephen T. Kent
(Computing Surveys, Vol. 15, No. 2, June 1983, pp. 135-171)

Jennifer
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 19:41:10 GMT
From:      dan@WILMA.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: world record

There was a lengthy discussion of this message on the ETHICS-L mailing
list.  The consensus was that it was probably a hoax, based on (among
other things) the fact that the Guinness Book of Records has no category
for "most postcards received".  Some posters warned against overloading
local P.O.s, as happened in the past (this is apparently not the first
time this message has gotten around).

Sorry to disappoint everybody...

	Dan

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 20:22:41 GMT
From:      brunner@SPAM.ISTC.SRI.COM (Thomas Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Reviews articles on network security

One "reference" is the "Trusted Network Intperpretation of Trusted Computer
Systems, Evaluation Criteria" (aka "the RED book"), which is ORANGE book
derived. You can get it from the NCSC, the number is: NCSC-TG-005, version 1.

You also may want to look into the course specific to this area put on by
Dan Lynch's organization, this month in Maryland as part of a TCP and OSI
group of courses. Contact Dan for the particulars, his email addr should be
in your site's archive of this list's traffic.

Cheers,
Eric

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 22:18:32 GMT
From:      dsnow@watdcsu.waterloo.edu (Doug Snow)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: Request for information: tcp/ip mail with vax/vms

In article <1706@carthage.UUCP> jeremy@carthage.UUCP (Jeremy Brest) writes:
>
>Related query: Does the CMU tcp/ip software allow DECnet to remain
>operational? 
>
Yup, it sure does.


Doug Snow, ACO, University of Waterloo, Waterloo, Ontario.

     dsnow@{watdcsu||watpix}.UWaterloo.EDU   ...!watmath!watdcsu!dsnow
     dougsnow@watdcs.NETNORTH dsnow@wataco.BITNET
     doug@artspas.watstar.waterloo.EDU

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 22:24:22 GMT
From:      carrs@TROUT.NOSC.MIL (Stephen M. Carr)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Fiber Optic Ring Backbone

-------
Folks,
 
1.  We are in the process of admiring the pros and cons of
implementing a fiber optic ring backbone versus a straight
vanilla 50 Ohm baseband coaxial cable backbone to support IEEE
802.3 CSMA/CD Ethernet and TCP/IP.  This backbone would support
other subnets, as well as support a gateway for all subnets into
the DDN MILNET.
 
2.  We had somebody propose installation of a fiber optic ring as
the backbone.  They were adamant that this is an IEEE 802.3
CSMA/CD Ethernet solution that supports TCP/IP on top of it.  I
was taken aback, for I never heard of IEEE 802.3 implemented in a
"ring" topology.  Seems senseless to implement IEEE 802.3 in a
"ring" topology to begin with, since IEEE 802.5 Token Ring is
specifically matched to a ring topology.
 
3.  Nevertheless, I am assured that just such a TCP/IP IEEE 802.3
CSMA/CD Ethernet solution in a fiber optic ring environment is
available from Fibercom Corporation.
 
4.  Aside from the fact that at first blush it appears silly to
me to even try to implement IEEE 802.3 in a ring topology, I have
other misgivings.
    a.  The cost per device connection would be significantly
higher.
    b.  A fiber optic ring backbone, even if feasible in an IEEE
802.3 environment, is not as generic as a 50 Ohm baseband coaxial
environment.  In a 50 Ohm baseband coaxial environment, I can
procure interface devices from several vendors at least.  I fear
that a Fibercom Corporation implementation of IEEE 802.3 in a
fiber ring environment would lock us into procurement of
gateway/router and interface devices from only one firm,
"Fibercom".  I wouldn't like to see us being maneuvered into
procurement of a "vendor proprietary" solution with little
flexibility regarding choice of gateway/routers and vendor
interface devices.
    c.  Implementation of IEEE 802.3 in a ring topology seems to
me would require something akin to the opposite of IEEE 802.4
Token Bus.  In other words, implement me a bus protocol in a ring
topology.  Not that IEEE 802.4 doesn't make sense, but it appears
that essentially the MAP folks have implemented a ring protocol
in a bus environment.  I am sure they have their reasons, the MAP
community isn't stupid.  But what about implementing IEEE 802.3
in a ring topology?  Is this for real?  I confess, I am ignorant.
    d.  I would think that in a ring topology, be it fiber or
coaxial cable, by definition requires an order of magnitude
greater configuration management overhead, in the sense that you
can't just pick a 2 meter mark on an Ethernet cable and screw in
a tap.  Adding or deleting nodes in a ring topology seems to me
requires very involved physical and software configuration
management processes.  Whereas management of a baseband Ethernet
appears relatively simple, requiring no extraordinary services or
talent.  Hmmm, maybe somebody is setting themselves up for a LAN
configuration management follow on contract.
    e.  Fault isolation.  I had been warned a long time ago about
the problems encountered in fault isolating and repairing a ring
topology.  A baseband coaxial cable plant seems so much more
straightforward and maintainable.
    f.  We are talking about building a fiber optic backbone for
one large building approximately 2 football fields long, and one
football field wide.  It is a one story structure.  Since we do
not exceed the limits of 500 meter segment and 2.5 kilometer span
restrictions of 50 Ohm baseband coaxial IEEE 802.3, I don't
understand what advantage a fiber optic ring is going to buy us
in terms of distance.  Besides, most if not all of the subnets
within this building are going to be other 50 Ohm baseband IEEE
802.3 gatewayed/routed/bridged into this backbone.
    g.  To the best of my knowledge, the FDDI (Fiber Optic
Distributed Device Interface) standard has yet to be promulgated,
and is still a draft standard.  If we wanted to maintain
interoperbility and conform to standards, I would think we should
be picking FDDI as a target for a fiber optic backbone.  Right
now, I am not even sure of the correct physical specifications
for an FDDI cable.  Is this cast in concrete?  Personally, I
would avoid entertaining fiber optic backbones until such time
that the FDDI standard is promulgated.
 
5.  We have precious little networking experience, but this fiber
optic ring solution seems to have gained a lot of popularity.  I
fear that people, in their zeal to become state of the art, are
throwing caution, reliability, interoperability, and the KISS
principle to the wind.
 
6.  Can anybody comment and shed light on this situation?  Does
anybody have first hand experience with such a TCP/IP Fibercom
Corporation IEEE 802.3 Ethernet fiber optic ring?  My apologies
for any statements above which may appear patently stupid from a
technical perspective.  Your candid response citing pros/cons and
errors in my logic would be greatly appreciated.
 
                       Very Respectfully,
                           Steve Carr
                          LCDR, SC, USN
 
Navy Management Systems Support Office (Code 42A)
Naval Air Station
Norfolk, Virginia 23511-6694
 
Commercial:  (804) 445-2171, 445-1595
AUTOVON:     565-2171, 565-1595
MILNET:      carrs@nosc.mil
             navmasso42a@nardacva.arpa
-------

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 23:39:21 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

I have a couple of RFC's partially completed.  One RFC deals specifically with
the framing protocol on async serial lines, called the "Asynchronous Framing
Protocol (AFP)".  It is basically the same as Rick Adams' defacto standard but
includes a type field, a 16-bit crc, and a strong suggestion to transmit an
extra FRAME_END character at the beginning of a non-back-to-back packet.
Another RFC defines the "Point-to-Point Protocol (PPP)" which allows option
negotiations over point-to-point links.  It is written in the telnet spirit and
allows future extensions to be easily incorporated.  Other RFC's will handle IP
address negotiation (via a PPP option) as well as some simple compression
schemes.

I'm currently implementing PPP on 4.3 in order to find problems before they're
cast in stone.  I should be finished real soon now.

Drew

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 88 23:51:55 GMT
From:      ted@ultra.UUCP (Ted Schroeder)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

In article <671@tetra.NOSC.MIL> budden@tetra.nosc.mil.UUCP (Rex A. Buddenberg)
 writes:
>Who do you know who has a 56k trunk in his home now?  I was talking
>about backbone connectivity (where the fiber is already laid),
>not local loop.

One of the wonders of ISDN is the fact that local loop supports the BRI (2B+D)
directly with the proper driving chips.  So the answer to the question is:
Everyone who happens to have a CO that's set up to talk ISDN.  

      Ted Schroeder                   ultra!ted@Ames.arc.nasa.GOV
      Ultra Network Technologies
      2140 Bering drive               with a domain server:
      San Jose, CA 95131                 ted@Ultra.COM
      408-922-0100

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 01:22:15 GMT
From:      NJG@CornellA (Nick Gimbrone)
To:        comp.protocols.tcp-ip
Subject:   Re: ReChoosing gateways

>host is using G1 to communicate with a host on the destination
 ...
>Are there any rules/guidelines/standards/... as to how the host can
>"find" G2?
We run the IBM product for VM (FAL) and have thought about this same
problem. In this case the package is configured with but one "default"
gateway. Several alternatives seem to exist (perhaps we'll do one one of
these days). One could build a list of "default" gateways and if you
note G1 isn't talking start using G2 (G3, G4, etc). You could even add
active steps to look for G1 not talking (ping it once in a while?).
Another alternative is to "listen" to whatever internal routing protocol
is used on the LAN. For us we use lots of RIP, which talks via
broadcasts. This makes it easy for any host that cares to to "listen in"
on what the RIPers are saying. The host can then act accordingly for
all their routing decisions.
-njg

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1988 06:34:23.26 EST
From:      <droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   NFS across the Internet
I'd like to hear from anyone who has successfully run NFS across the
Internet, or who can point me to references reporting the use of NFS
across the Internet.  By "across the Internet", I mean between sites
on separate LANs, managed by disjoint administrations.  Thanks...

- Ralph Droms
  Department of Computer Science
  Bucknell University
  droms@bknlvms.bitnet

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 1988 06:44:04.83 EST
From:      <droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Checksums (again)
Having come in at only at the tail end of this discussion, I don't know
if anyone has pointed out that, assuming a packet length of < 2**16-1
words, the checksum algorithm can wait to add back all the carry bits
until *after* the checksum loop is completed.  I.e.:

while (computing-the-checksum) {
    checksum += buf[i++];
    }
checksum = checksum && 0xFFFF + (checksum >> 16);
checksum = checksum && 0xFFFF + (checksum >> 16); /* sic - the first carry */
                                                  /* "add back" may cause  */
                                                  /* a second carry out    */

Using this technique, and unrolling the loop to do 32 additions in line,
I was able to reduce the average number of instructions per short word
from ~10 to 3+ on an IBM RT PC (since the RT is a register-to-register
RISC CPU, 3 instructions per short word is the minimum to load the word,
add to the checksum and increment the pointer).  This optimization
reduced the time spent in the RT 4.2BSD checksum routine from 10% to
about 1% on large TCP data transfers, with a resulting increase in
throughput of about 10%.

- Ralph Droms
  Department of Computer Science
  Bucknell University
  droms@bknlvms.bitnet

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 88 10:25:26 -0500
From:      dkovar@VAX.BBN.COM
To:        Paul Tsuchiya <tsuchiya@GATEWAY.MITRE.ORG>
Cc:        tcp-ip@SRI-NIC.ARPA, bboard@VAX.BBN.COM
Subject:   Re: world record
  This made the rounds of USENET recently. Two important points:

	1) Usually, this type of thing is a hoax. Another one of the
	   urban legends. Surprisingly, this one was not just another
	   legend.

	2) It's over. It's done. He's in. They're being flooded with
	   mail and really want it to stop. Please. That's one of
	   the major problems with starting this sort of thing: How
	   do you stop it? So please do not continue passing this
	   plea for letters along and help out both the US and British
	   postal services.

-David Kovar
 DKovar@BBN.COM
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 1988 0743-EST
From:      hsw@TYCHO.ARPA  (Howard Weiss)
To:        hscfvax!mohamed at husc6.harvard.edu
Cc:        tcp-ip at sri-nic.arpa
Subject:   RE: Reviews articles on network security

A book you might be interested in is put out by the IEEE Computer Society
entitled "Tutorial: Computer and Network Security" by Marshall Abrams
and Harold Podell (IEEE Computer Society Order Number 756, IEEE Catalog
Number EH0255-0).  This book contains over 400 pages of papers from
various authors and publications in the area of computer and network
security.

-------

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 88 08:35:02 EST
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: world record
This sounds like an "urban legend" that has circulated many times.

                                            Bob Dixon
                                            Ohio State University
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 04:17:29 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?


I still maintain that in the real world, there is no need for
a checksum with packet transmission. IP and TCP do it fine.

This is based on 4 years experience with 8 "real world" SLIP installations
including leased lines from Washington, DC to Amsterdam, San Diego, Albany,
and a few "local" sites < 50 miles away.

Current modem technology is such that the connection is already
virtually error free. The same can be said of dialup modems if
you don't buy the cheapest junk you can get. (I.e. if you're cheap buy
something with MNP error correction. If you want something to work great,
spend the $1000 on a Trailblazer.)

The biggest virtue of "my" SLIP is that it is so trivial to implement.
A big part of that reason is that it makes TCP/IP do the
retransmission & error detection. Complicated protocols won't catch
on no matter how nice they look on paper. (E.g. a previous RFC on
Async protocols for serial lines that was never implemented (or at
least widely implemented.)

Does anyone REALLY have proof that it is necessary to complicate the
protocol? Or is it just an obsession with what is theoretically
required.

Often practical engineering confounds theoretical science.

--rick

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 04:42:48 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

> I still maintain that in the real world, there is no need for
> a checksum with packet transmission. IP and TCP do it fine.
 
> Does anyone REALLY have proof that it is necessary to complicate the>
> protocol?
The unfortunate proof is in UDP.  Adding a CRC (not a checksum!) is a necessary
result of some vendors (read SUN) reluctance to use checksums.  The UDP spec
unfortunately allows this.  Although most people disagree with this decision
(not to checksum UDP), we decided to add the CRC to SLIP so that you have a
lower chance of getting burned if you are following the spec.  Calculating and
sending the CRC really isn't a big deal.  Depending on the implementation, the
CRC calculation can be done incrementally with each character received thereby
amortizing the cost over each character.  Combined with table driven crc
calculations, the cost is very low.  It can also be argued that the time to
send the crc is not a big deal if you use even crude compression schemes.  I
intend to document simple header compression schemes (similar to Noel's scheme)
and probably some simple forms of run-length encoding for the data.

> The biggest virtue of "my" SLIP is that it is so trivial to implement.
> A big part of that reason is that it makes TCP/IP do the
> retransmission & error detection.

We are not making SLIP non-trivial.  We are still counting of TCP/IP to do the
retransmissions (error correction).   We are only making it do error detection
which is *much* simpler.  It is not going to be anything like TCP or LAPB as
was suggested by previous RFC's.

Drew

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 88 09:49:13 EST
From:      Mary Bastian <PETTY@MITVMA.MIT.EDU>
To:        "Stephen M. Carr" <TCP-IP@SRI-NIC.ARPA>
Subject:   TCP/IP Fiber Optic Ring Backbone
I have never heard of a fiber optic ring for TCP/IP.  I agree with you
that it sounds a bit bizarre.  I do, however, know of another company
that might be able to help you with your fiber optic network as well
as your FDDI questions.  The company is Fibronics, and you can contact
a regional office in your area at 703-648-1533.  You'd want to talk
with Sharon Bittorie.

Good luck!
Mary
-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 04:53:37 GMT
From:      smiller@umn-cs.cs.umn.edu (Steven M. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

> terminating at your residence?  ISDN gives hopes of getting reasonable
> bandwidth almost anywhere a reasonable cost, whereas fiber will
> probably be limited to backbone applications and connecting super
> computer ($$$) centers.

I recently attended a presentation on ISDN given by a rep from 
Northwestern Bell.  He talked about the local loop being Fiber with
ISDN only being a small part of the bandwidth, with the rest being
things like super hi res cable tv and other goodies.

-Steve
-- 



			-Steve Miller, U of MN

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 05:01:55 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

Again, you haven't said that the actual line is bad enough that you
have to worry about it. You've said that you think you need
another checksum because some vendors stupidly doesn't use it.

Do you have actual data showing the CRC16 is needed? Is so (or if not),
why is a CRC16 strong enough and a "better checksum" not needed.
No "feelings" or "guesses" need apply.

Turning off the UDP checksums for performance reasons is VULGAR. It's
really an admission that your vendor's engineering is either
incapable or unwilling to fix the fundamental problem.
(Besides, if you are running NFS over a 9.6 kbps line, the
overhead of the UDP checksums is the least of your performance
concerns.)

Claiming that a low level protocol is broken because you are using
lobotomized higher lever protocols is no solution. Fix the problem!
Don't kludge around it!

---rick

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 05:38:00 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)

Bob,

Fuzzballs have a long memory. IEN45.TXT is now on faithful fuzzball
udel2.udel.edu in the file du3:ien45.txt and is accessable via anonymous
FTP with password guest. You probably wouldn't even be surprised about
the incredible dusty archives that are still living on du3: after then
ten years of Internet wars. Snarfers are welcome, but please be gentle,
since there is only one 9600-bps line accessing that fuzzy at my home and
it is used for lots of other things.

Dave

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 88 11:30:45 EST
From:      bzs%bu-cs.bu.edu@buita.BU.EDU (Barry Shein)
To:        Messenger.SBDERX@Xerox.COM
Cc:        INGRIA@G.BBN.COM, subgenius@MEDIA-LAB.MEDIA.MIT.EDU, tcp-ip@SRI-NIC.ARPA, bboard@cch.bbn.COM, NCRAMER@G.BBN.COM, BNEVIN@CCH.BBN.COM, dan@WILMA.BBN.COM
Subject:   World Record (The Other Shoe)

Hugh,

I'm glad to hear this hoax was true, or used to be true etc. I can't
see why it would be a good idea for everyone to pick up a telephone
and dial overseas (for many of us) and bother some hospital about a
message we saw on the net posted to some inappropriate places anyhow.

Yes, hoaxes have taken this form (the "Little Buddy" messages, almost
the exact same story and always overseas [for a lot of us], probably
calculated to make people hesitate to phone and just drop a postcard.)

The point is that skepticism is the appropriate reaction, and posting
such a message to TCP-IP is not (not yours, the original.)

Perhaps now someone *will* find an alligator in the NYC sewers.

	-Barry Shein, Boston University

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 88 15:00:45 PST
From:      Robert Allen <robert@spam.istc.sri.com>
To:        bzs%bu-cs.bu.edu@buita.bu.edu (Barry Shein)
Cc:        Messenger.SBDERX@xerox.com, INGRIA@g.bbn.com, subgenius@media-lab.media.mit.edu, tcp-ip@sri-nic.arpa, bboard@cch.bbn.com, NCRAMER@g.bbn.com, BNEVIN@cch.bbn.com, dan@wilma.bbn.com
Subject:   Re: World Record (The Other Shoe)

>> Perhaps now someone *will* find an alligator in the NYC sewers.
>> 
>> 	-Barry Shein, Boston University

	What!  You mean there really aren't Aligators in the
	New York sewers? (half a :-) )
-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Mar 88 16:11:29 PST
From:      Niels P. Mayer <mayer%hplnpm@hplabs.HP.COM>
To:        Robert Allen <robert@spam.istc.sri.com>
Cc:        Messenger.SBDERX@xerox.com, INGRIA@g.bbn.com, subgenius@MEDIA-LAB.MEDIA.MIT.EDU, tcp-ip@sri-nic.ARPA, bboard@cch.bbn.com, NCRAMER@g.bbn.com, BNEVIN@cch.bbn.com, dan@wilma.bbn.com
Subject:   Re: World Record (That's it for the other one)
>         What!  You mean there really aren't Aligators in the
>         New York sewers? (half a :-) )

no, but there are rats the size of cats. 

You see, it happend like this: pet store sells a rat to unwitting customer
who thinks he's receiving a gerbil. customer uses rat as suppository. after
a few hours of extatic constipation, poots rat into toilet, flushes it.
Rat, beleiving he's a gerbil trapped in a rat's body, sublimates these
desires by overeating irradiated nouvelle cuisine cheesburgers in east
village sewer. Cat sized rat gets cancer, asks for postcards to be sent to
his deathbed, but eventually mutates into poodle out of spite. Deus ex
machina story ending finds gerbil-cum-rat-cum-cat-cum-poodle ending up in
microwave, exploding into a cloud of cat-sized-rat viroids to reinfest
NYC's teeming sewer system. Shit happens.

In the meantime, please send postcards to a little boy dying of ennui:

	Niels Mayer
	355 Webster #C
	Palo Alto, CA 94301.

Thank you for your consideration.
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 10:20:09 GMT
From:      Messenger.SBDERX@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: World Record (The Other Shoe)


Re: The postcard story

I don't know about the other instances of postcard appeals cited as hoaxes, but
this one was definitely TRUE.  I live a few miles from Luton (which, incidently,
a large industrial town and not a "tiny village") and phoned Miss Williams (not
McWilliams) just now.  The appeal closed at Christmas, David went on TV to say
that he had enough postcards to get the record and he didn't want anymore.

Please, please, please check your facts before mailing this kind of emotive
stuff.  No excuse in this case - a full postal address was given, and there is
such a thing as International Directory Enquiries for getting hold of phone
numbers.  I am totally amazed that a "lengthy discussion" could be held about
this and reach a "consensus was that it was probably a hoax" and nobody even
bothered to pick up a telephone!

Come on guys 'n gals, there is a world outside ...

   -- Hugh
   

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 12:29:16 GMT
From:      steinar@TOR.NTA.NO (Steinar Haug RUNIT)
To:        comp.protocols.tcp-ip
Subject:   Re: The postcard story

There was a similar discussion about the postcard story on the BITNET
distribution list REXXLIST a short while ago. Started (of course) when
someone posted the 'original' postcard story to REXXLIST.

I have received the same postcard story on at least five other lists,
in addition to at least ten copies sent me directly from friends on
the net. Now of course I feel sympathy for the boy in this story, and
the consensus on REXXLIST seemed to be that the story was indeed true.
But folks, *please* let's stick to relevant topics! In my opinion it's
irrelevant whether or not the story is a hoax, it still doesn't belong
on these lists! The TCP-IP list is for discussion about TCP/IP, REXXLIST
for discussion about REXX.

Steinar Haug
Computing Center at the University of Trondheim, Norway

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 12:43:00 GMT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   RE: Reviews articles on network security


A book you might be interested in is put out by the IEEE Computer Society
entitled "Tutorial: Computer and Network Security" by Marshall Abrams
and Harold Podell (IEEE Computer Society Order Number 756, IEEE Catalog
Number EH0255-0).  This book contains over 400 pages of papers from
various authors and publications in the area of computer and network
security.

-------

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 13:35:02 GMT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re: world record

This sounds like an "urban legend" that has circulated many times.

                                            Bob Dixon
                                            Ohio State University

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 14:49:13 GMT
From:      PETTY@MITVMA.MIT.EDU (Mary Bastian)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Fiber Optic Ring Backbone

I have never heard of a fiber optic ring for TCP/IP.  I agree with you
that it sounds a bit bizarre.  I do, however, know of another company
that might be able to help you with your fiber optic network as well
as your FDDI questions.  The company is Fibronics, and you can contact
a regional office in your area at 703-648-1533.  You'd want to talk
with Sharon Bittorie.

Good luck!
Mary

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 14:50:48 GMT
From:      mminnich@UDEL.EDU (Mike Minnich)
To:        comp.protocols.tcp-ip
Subject:   ien45 (was Re: Checksums (was Re: Ping, checksum algorithm?))

I have placed a copy of ien45.txt on louie.udel.edu in ~ftp/pub/ien45.txt
that is accessible via anonymous ftp for those who might not be able to
get at udel2.udel.edu.

mike

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 15:05:56 GMT
From:      lekkas@cernvax.UUCP (George  P.  Lekkas)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: XENIX TCP/IP software (IBM PC)

In article <1407@inco.UUCP> fennell@inco.UUCP (Tim Fennell) writes:
>	HELP!!!
>	I need to  know if and  where  I can find TCP/IP
>	to run on the IBMPC/AT under XENIX OS. [...]
I would also like to see something like it. I'm working now on a BSD sockets
emulation package on Xenix, so that 3270 can be transferred, so if somebody
already done that,.. (no such luck,I suppose)
	And thanx to Barry Shein. VERY good answer..
							Giorgos Lekkas

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 15:25:26 GMT
From:      dkovar@VAX.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: world record


  This made the rounds of USENET recently. Two important points:

	1) Usually, this type of thing is a hoax. Another one of the
	   urban legends. Surprisingly, this one was not just another
	   legend.

	2) It's over. It's done. He's in. They're being flooded with
	   mail and really want it to stop. Please. That's one of
	   the major problems with starting this sort of thing: How
	   do you stop it? So please do not continue passing this
	   plea for letters along and help out both the US and British
	   postal services.

-David Kovar
 DKovar@BBN.COM

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 16:12:10 GMT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.sys.dec,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: LAN Hardware/Software advice needed

Q:	I would like to run Ethernet between the microVAX and the
	11/750. Which ethernet controller should i buy for the uVAX?
	I already have a DEUNA on the 750 but might trade it in for
	a DELUA.
A:	GO with the DELUA, there was a bug with DEUNA's in 750's that
	they sunk so much power when they energized the transciever that
	DCLO would occur on the UNIBUS crashing the machine.

Q:	How can I set things up so that folks on the uVAX logon to the
	UNIX machine and vice-versa? I think I would like to get TCP/IP
	and all the rlogin/telnet/ftp,etc. stuff for the uVAX. Which is the
	best (or recommended) options to buy?
	Will the uVAX-II be able to support all this? Will VMS block
	ethernet logins?
A:	Answer, best bet in a mixed environment is to run TCP/IP (of
	course, I'm a IP bigot).  You can get TCP/IP for the VAX from
	a couple of commercial sources.  We deal with Wollengong.  The
	price is around $6000 list for a multiuser VMS uVAX, but you
	may be able to convince them to give them a discount.  They have
	a very liberal discount for Universities now.   This will allow
	full connectivity for login/telnet between the two machines.
	You could get DECNET for the UNIX machine, but this is not such
	a good solution.

Q:	How can the IBM PC's and Mac SEs also do the rlogin/telnet/ftp,etc.,
	action with either of the UNIX VAX or VMS uVAX? How should
	be go about doing this? Money is no object but of course
	a few hundred feet above the ground is our limit (read $50,000
	to $150,00 is my anticipated budget :-). Feel free to share your
	expreriences and flights of fancy. I'm all ears! 
A:	You can fully equip an IBM-PC with an Ethernet card and TCP
	software for less than $500 dollars.  You can probably do it
	for less than $300 if you rely on Public Domain software and
	the cheaper Ethernet cards.  We tend towards the Micom 5210
	cards these days.  For Macintoshes, there is no good way for
	the non-MAC-II's to hold an Ethernet card.  However, you can
	run TCP/IP nicely by using an Appletalk->Ethernet gateway.
	Specifically, the Kinetics FastPath (less than $2000) which will
	serve an entire Appletalk net.  We use this in conjunction with
	the public domain NCSA telnet.  You can get Ethernet cards for
	the MAC-II's and rumor has it for the SE, but I have no experience
	with this as the FastPath box is more economical when you have
	more than one or two Macs to hook up.

Q: 	This was added as an after thought, but we have an HP 3000
	as well. How can we network that to the configuration above?
A:	HP has now announced TCP/IP for the 3000 as well.  Unfortunately
	they don't use the standard Ethernet format so you have to buy
	a converter box from a company called CISCO.  This costs around
	$6000 (list) but you can also use the same box to provide interface
	for telnet and rlogin from regular ASCII terminals to the network.

-Ron

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 16:17:16 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

Rick,

I second your motion. I've been running fuzzballs with raw IP over everything
from noisy leased lines to transcontinental dial-up circuits since 1978 with
no problems. I ran my home fuzzball over a 1200-bps 15-mile dial-up circuit
for five years and then a 4800-bps leased circuit for four years in raw IP.
Those instances when the 24-hour dial-up circuit would drop, maybe once
every month or so, plus the number of packets dropped due congestion, timeout
and similar causes, easily outnumbered the number dropped due checksum
errors. Yes, there is some chance that a few error bits did survive somewhere
in the many megabytes of data transferred over that nine-year period, but I
strongly suspect most of them were due to causes other than checksum errors.

Having said that, I still would not recommend running raw IP between heavy-
hitting nodes like backbone switches or gateways. The NSFNET Backbone fuzzies
use DDCMP links with CRC checking and they do find significant numbers of
errors sometimes on marginal trunks. I would be a little uneasy if the IP
and/or TCP checksums were the only protection. However, I am completely
comfortable without CRC protection on single-user PCs and workstations
and would be even more comfortable if the drat Backfuzz links did NOT use
retransmission (DDCMP interface retransmissions are done in hardware and
cannot be disabled).

Dave

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 16:33:23 GMT
From:      neerma@COD.NOSC.MIL (Merle A. Neer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Fiber Optic Ring Backbone

Hi,

I must confess I am totally unaware of 802.3 "ring" technology.
I have never heard of such a beast, however, I will comment on
some of your other concerns to the effect that I agree totally.
I am currently involved in evaluation of local net architecture
solutions for NOSC Hawaii.  In this effort I have been looking
at 802.3 vs. 802.5, FDDI, SAFENET, etc.  I concur with your
comment that you dont want to lock yourself into a vendor
proprietary solution; open systems is the name of the game. In
the absence of a valid reason to do otherwise(need for process
control, real-time applications, etc.) others have already made
the observation that Ethernet is the safest, most conservative,
and ubiquitous technology here today.  The product choices both
for hardware and software favor this solution.  Tomorrow FDDI
and for the military, SAFENET(a variant on FDDI), will probably
be the technology of choice.  For maximum interoperability,
consider that gateways(routers), bridges, etc. are available now
for Ethernet.  As far as performance goes, we have an Ethernet
here(at NOSC) used by some 50 hosts for the usual traffic mix
of interactive login, file transfer, transaction processing, tape
backups, etc.  I have never seen the peak utilization go above
2%.  This is typical I believe.  It could be that the kind of
applications you will run will require higher performance than
802.3 can offer; if this is the case, of course, the correct
solution is not Ethernet.  

Anyway, it will be interesting to hear more about this 802.3
"ring"!

Regards,
Merle Neer
NOSC
neerma at nosc.mil
619-553-4135

-------

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 16:49:13 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   SLIP working group?


>The unfortunate proof is in UDP.  Adding a CRC (not a checksum!) is a necessary
>result of some vendors (read SUN) reluctance to use checksums.  The UDP spec
>unfortunately allows this.  Although most people disagree with this decision
>(not to checksum UDP), we decided to add the CRC to SLIP so that you have a
>lower chance of getting burned if you are following the spec.

I've always thought that the optional checksum in UDP was a feature,
if I choose not to use the UDP checksum I may have some good reasons
(eg.  I might be sending an ECC with each packet to avoid
retransmission on every error.) This defeats this and would force
someone to, well, even sending IP won't help, they'd have to re-write
the SLIP, bother. It's straightforward to turn on UDP checksumming
on a Sun, at worst you can fault them for not making it easier:

	% adb -w -k /vmunix /dev/mem
	udpcksum?W 1
	$q
	%

That could be put into a command script trivially enough. I think
putting a CRC into SLIP is a rather odd way to disagree with Sun's
design decision (which might still be wrong, that's irrelevant is my
point.) Add that to Rick's experiences that IP and TCP seem to do the
job well enough at that level, that UDP checksumming is trivial to
turn on in Unix and the fact that modems which will do end to end
checksumming are so common and inexpensive and we have an odd
situation, let's calculate a checksum 3 or 4 times as we route all
data?

Seems like over-engineering, at least until someone can come up with
better reasoning than doing it because the user may have turned it
(left it) off at a higher layer. The user may have *wanted* it off.

I'll anticipate the argument that the system admin who manages the
file server may have turned it off and is out of the user's control.
How is this putative user getting SLIP supported and NFS connections
allowed if they have no influence with the sysadmin? Is the protocol
spec the correct place to try to workaround bad personal relationships
between users' and their sysadmins? &c.

Of course, the real issue of simplicity of implementation has to be
factored in also, as Rick points out, in the end that's a critical
decision point.

	-Barry Shein, Boston University

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 17:08:19 GMT
From:      scottr@CSC-LONS.ARPA (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Ping for EXCELAN (4.1C BSD)

Does anyone have any information on a PING program for the EXCELAN 
TCP/IP interface.  The socket library is based on 4.1C Berkley sockets (yeach)

Please respond direct to me, I will summarize to the network.

	Excelan Products 8011-03, 8011-04	SCO XENIX V
			 8051-02		PC/MS-DOS

					Thanks in advance,

					Scott W. Rogers
					<scottr@csc-lons.arpa>
---

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 17:19:50 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (was Re: Ping, checksum algorithm?)

Dave,

Yes, indeed, IEN45 is alive and well on udel2 as claimed!
I'm impressed at what long memories Fuzzballs have.  And big disks, too,
apparently.  We will make sure the NIC gets a copy of IEN45
for their public files, which will relieve your 9.6bps path.

   Bob Braden

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 17:29:58 GMT
From:      dab@oliver.CRAY.COM (Dave Borman)
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (again)

> Having come in at only at the tail end of this discussion, I don't know
> if anyone has pointed out that, assuming a packet length of < 2**16-1
> words, the checksum algorithm can wait to add back all the carry bits
> until *after* the checksum loop is completed.  I.e.:
>
> while (computing-the-checksum) {
>     checksum += buf[i++];
>     }
> checksum = checksum && 0xFFFF + (checksum >> 16);
> checksum = checksum && 0xFFFF + (checksum >> 16); /* sic - the first carry */
>                                                   /* "add back" may cause  */
>                                                   /* a second carry out    */

You can only wait to do the folding in of checksum overflow if
you are adding 16 bit quantites in a 32 bit sum.  The BSD
implementation adds 32 bits at a time in a 32 bit sum, so you
have to add in the carry bit as you go.  On just about any machine
it will probaboy be faster to do one memory reference to get the
32 bit quantity, and then add in the carry, rather than doing two 16
bit memory references.  (As a side note, on a CRAY computer you do
not have a carry bit, so we do the sum by reading up 64 bit quantities,
splitting them into two 32 bit quantites, and summing into a 64 bit
sum.  We then add in all the carry bits at the end.)
			-Dave Borman
			CRAY Research, Inc.

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 19:07:56 GMT
From:      ehrlich@blitz (Dan Ehrlich)
To:        comp.sys.dec,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: LAN Hardware/Software advice needed

In article <Mar.30.11.12.09.1988.26831@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
>...
>A:	GO with the DELUA, there was a bug with DEUNA's in 750's that
>	they sunk so much power when they energized the transciever that
>	DCLO would occur on the UNIBUS crashing the machine.
>

That's funny.  We have an 11/750 that runs just fine with a DEUNA installed.

Dan Ehrlich <ehrlich@blitz.{cs.psu.edu,bitnet,uucp}>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723
Dan Ehrlich <ehrlich@blitz.{cs.psu.edu,bitnet,uucp}>
The Pennsylvania State University, Department of Computer Science
333 Whitmore Laboratory, University Park, PA   16802
+1 814 863 1142 or +1 814 865 9723

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 19:12:05 GMT
From:      karn@thumper.bellcore.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   yet another IEN/RFC repository

I'm also keeping a complete collection of RFCs and IENs on
flash.bellcore.com (128.96.32.20). They are available by anonymous ftp;
look under /pub/rfc and /pub/ien. Note that the file names end in '.Z';
the files are all compressed with the UNIX "compress" program.

Phil

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 20:00:35 GMT
From:      phil@amdcad.AMD.COM (Phil Ngai)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.sys.ibm.pc.rt
Subject:   Re: SLIP on the IBM RT (w/AIX) or Apollo workstations

In article <31@auschs.UUCP> sauer@auschs.UUCP (Charlie Sauer) writes:
,SLIP is in AIX/RT 2.2.  2.2 is scheduled to be available in June.
,Charlie Sauer   Dept D18, Bldg 802      aesnet: sauer@auschs
,                IBM AES/ESD, Austin, TX   vnet: SAUER at AUSVM6

Wonder if it runs better than the brain dead "TCP" we have on our
AIX/RT 2.1.1. 

-- 
 I love my VT-320.

I speak for myself, not the company.
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 20:37:17 GMT
From:      jonab@CAM.UNISYS.COM (Jonathan P. Biggar)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

Why don't we make the new versions of SLIP upwards compatible?  Add a
negotiation feature to SLIP that will be ignored by the current
implementations (such as a packet shorter that the minimum IP header size),
and then negotiate the use of such things as checksum, CRC, header 
compression, etc.  Everything can just default to the current SLIP usage.

Jon Biggar
jonab@cam.unisys.com

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 20:55:26 GMT
From:      karn@thumper.bellcore.com (Phil R. Karn)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

The framing technique you describe is EXACTLY the same as SLIP, with one
important difference -- the specific values of the "escape" and "frame
end" characters are different. Why? Is gratuitous incompatibility with
de-facto standards a prerequisite for ISO approval?

I distinguish between the framing technique used by SLIP and the format
of the information carried in a frame. There's nothing about SLIP
framing that says you can't add a link-level CRC or checksum if you
wish. It just hasn't been necessary, as there are already checksums at
the IP and TCP layers.  The error rate of a typical dialup link (if it
works at all) is low enough that the extra software processing required
to recompute a checksum over an entire packet at each hop is hard to
justify. I keep a nailed-up 9600 bps V.32 modem link between work and
home. In the 6 days since it was last rebooted, my machine at home has
received 13,186 packets over the serial link. Of these, however, only 6
had IP header checksum errors and 8 contained TCP header checksum
errors. I have also used SLIP heavily elsewhere, but I have NEVER seen a
file corrupted by the failure of the TCP checksum to catch an error.

The propensity of the ISORMites to reinvent the wheel (with seemingly
deliberately incompatible lug-nut threads) never ceases to amaze me.
Considering the popularity of SLIP, your time would be much better spent
making incremental, desirable improvements (e.g., logins and passwords
for switched environments) instead of devising totally new and
gratuitously different protocols to do what is already being done.

Phil

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 21:36:42 GMT
From:      randy@LARRY.CS.WASHINGTON.EDU (Randy)
To:        comp.protocols.tcp-ip
Subject:   Re: CRC calculation costs (was Re: SLIP working group? )

Drew:

I'm interested by your statements that checksuming is a very small part of
the procotcol processing. "Common wisdom" I've always heard, and 
Cabrera et.al. in "User-Process Communication Performance in Networks of
Computers" (IEEE Trans. on Software Eng. Jan. 88) say that data copying and
checksumming are the two biggest components of protocol processing in
BSD4.2 Unix implementations.

Have you done any instrumentation of your code to get performance statistics
of which parts of the protocol processing account for the bottlenecks?

Randy Day.
Internet (ARPA): randy@cs.washington.edu
CSNET: randy%washington@relay.cs.net
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 22:01:52 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Time server status

Folks,

At this time all five fuzzball primary time servers (WWVB and GOES)
are back in service. However, it turns out that the present NTP time
daemon ntpd does not recognize when a server explicitly indicates that
its time is invalid, as when first coming up and before resynchronization
is complete. This condition is indicated when the two high-order bits of
the status octet in the NTP header are set, as described in the latest
documentation issued a month or so ago. I have reports that some VAXen
running domain-name servers get mighty sore when this happens, since
their caches... Well, you can figure that out for yourself.

Mike Petry is now working on a new ntpd daemon to conform to the latest
specs; however, it might be useful to update the present version to ignore
packets received with the bits set.

Dave

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 22:06:09 GMT
From:      timk@NCSA.UIUC.EDU (Tim Krauskopf)
To:        comp.protocols.tcp-ip
Subject:   Re: Fiber 802.3 ring


I'm surprised that no one else has volunteered experience with Fibercom
modems or other fiber used to bridge Ethernet at the MAC level.

We have three fiber rings now, in use as backbones for our level-2
Ethernet (Suns).  We have run as many as seven 900-1000 foot 
thin Ether segments off of a central ring.  Until we split it, traffic
from 40+ Suns traversed this ring along with a couple hundred PCs, Macs,
etc.  Yes, we broke all the rules, it worked for a while, now we have
split it with IP routers.

I think the technology is fairly straightforward.  They use a proprietary
ring system to emulate an 802.3 bus.  Even jams and shorts are emulated
across the ring.  There is a lockout switch on each fiber modem which
can isolate a coax segment without affecting the ring.
The "documentation" says up to 2km per station, 10's of kms total ring
length.  We run them on fairly short runs (100m) with excellent reliability.

Justifiable cost per backbone is probably in question here, but . . .
"If it ain't broke, don't fix it"

 Tim Krauskopf                                        timk@ncsa.uiuc.edu (ARPA)
 National Center for Supercomputing Applications      14013@ncsavmsa (BITNET)
 University of Illinois
 Standard disclaimer: "Just a customer"

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 22:50:57 GMT
From:      david@ms.uky.edu (David Herron -- Resident E-mail Hack)
To:        comp.sys.dec,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: LAN Hardware/Software advice needed

In article <3405@psuvax1.psu.edu> ehrlich@blitz (Dan Ehrlich) writes:
>In article <Mar.30.11.12.09.1988.26831@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
>>...
>>A:	GO with the DELUA, there was a bug with DEUNA's in 750's that
>>	they sunk so much power when they energized the transciever that
>>	DCLO would occur on the UNIBUS crashing the machine.
>>
>
>That's funny.  We have an 11/750 that runs just fine with a DEUNA installed.

Yeah ... so do we.  But I think it's on its own unibus in our machine.
I don't remember.  Anyway, the DELUA being a newer design is a better
board.

For the same reason you want to get DELQA's for uVaxen instead of
DEQNA's.
-- 
<---- David Herron -- The E-Mail guy            <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- I don't have a Blue bone in my body!

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 88 22:59:24 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?


If you are going to add multiple protocol support to SLIP, please do it
in the following manner.

The first byte following a FRAME_END is the protocol type byte.

If the byte is 0x40 - 0x4F the packet is considered to be an IP packet
and the protocol type byte IS INCLUDED as part of the packet.
(Astute observers will realize that this is an IP Version Number of 4
combined with all of the possible IP header lengths.)

Otherwise, the protocol type byte selects a protocol family from the
following table (stolen from socket.h on 4.3BSD) and the protocol type
byte IS NOT INCLUDED as part of the packet.

This will allow "old" SLIP implementations to talk to your new system
without modification. It also provides all of the functionality you
might need. If you feel that you MUST have error detection, error
correction, header compression, or even encryption, please define a new
address family number and add it to the table. That way those who
feel it is not necessary will not be burdend with it and everyone is
happy.

It should be very easy to implement. I'd do it, but I have no need for
multiple protocols.

---rick

/*
 * Address families.
 */
#define	AF_UNSPEC	0		/* unspecified */
#define	AF_UNIX		1		/* local to host (pipes, portals) */
#define	AF_INET		2		/* internetwork: UDP, TCP, etc. */
#define	AF_IMPLINK	3		/* arpanet imp addresses */
#define	AF_PUP		4		/* pup protocols: e.g. BSP */
#define	AF_CHAOS	5		/* mit CHAOS protocols */
#define	AF_NS		6		/* XEROX NS protocols */
#define	AF_NBS		7		/* nbs protocols */
#define	AF_ECMA		8		/* european computer manufacturers */
#define	AF_DATAKIT	9		/* datakit protocols */
#define	AF_CCITT	10		/* CCITT protocols, X.25 etc */
#define	AF_SNA		11		/* IBM SNA */
#define AF_DECnet	12		/* DECnet */
#define AF_DLI		13		/* Direct data link interface */
#define AF_LAT		14		/* LAT */
#define	AF_HYLINK	15		/* NSC Hyperchannel */
#define	AF_APPLETALK	16		/* Apple Talk */

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 00:34:06 GMT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   link level crap protection

For my two cents...
If the purpose of a SLIP checksum is ONLY to allow SLIP to know
a packet is bad and to discard it, then it is tolerable.
If it does ANYTHING beyond inspect it for damage, trash
the broken packet, and increment a counter, it is wrong.

I understand Rick's experience, but I have also felt that the
protocols really expected to get a Good packet or No packet.
The checksumming is there for the occassion when the No packet
case screws up and the wire delivers junk.

This may not have been spelled-out anywhere, but has been
a religious believe of mine.

	-Mike O'Dell

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1988 06:48-CST
From:      SNELSON@STL-HOST1.ARPA
To:        smiller@UMN-CS.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Rumors about the death of the ARPANET
Just keep in mind that on wire the CENTRAL OFFICE is supplying the power
for your telephones. When you go fiber and you got no 'lectricity= no
'lectrons= no signal.
Steve
-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Mar 88 07:57:11 EST
From:      Tony Michel <michel@cct.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   Public RFCs still needed
I access the Internet from my Macintosh, using NCSA Telnet, which includes
a SERVER ftp.  I can't initiate a transfer.  To fetch a file I must
log in to your system, and send the file back to myself.  Any of you
charitable folks willing to install some sort of "anonymous" account with
login priveleges (maybe only able to run user ftp)?  Then I could actually
fetch those RFCs and IENs.  I suspect I'm not the only one.

AXM

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 03:01:41 GMT
From:      brian@wb6rqn.UUCP (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   SLIP complexity

Rick, you are right, 95% of the time it is a waste to add error
correction to a SLIP link.  On the other hand the checksum routines in
TCP and IP are not very robust.  They work just fine in the presence of
single bit errors but will fall down in the presence of burst errors.  I
am perfectly willing to allow TCP to handle the request for
retransmission of "lost" packets but I do not want to rely on the
checksum routines to ensure that the packets are good.  Too much margin
for error. 

At Sirius Systems we are adding an option that will allow you to turn on
one of three error handling modes: current SLIP (no error checking),
CRC-CCITT error checking where it discards bad frames, and lastly the
retransmission of bad frames.

I expect that most sites will run in the first mode and the rest will
run in the second mode.  We may just ignore the third mode altogether,
especially in light of modems like the trailblazer (which we love too).

Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1988 09:03-EST
From:      CLYNN@G.BBN.COM
To:        dab%oliver.CRAY.COM@UMN-REI-UC.ARPA
Cc:        droms%BKNLVMS.BITNET@CUNYVM.CUNY.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Checksums (again)
Dave,	I've never used a CRAY, but assuming it has unsigned arithmetic,
would it be faster to read & split 64-bit quantities similar to
	sum += (((unsigned) DATA) >> 32) + (0xFFFFFFFF & DATA);
or to
	if ( (sum += DATA) < DATA ) sum++;
?

Charlie
-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Mar 88 9:16:00 EST
From:      Alex McKenzie <mckenzie@LABS-N.BBN.COM>
To:        carrs@COD.NOSC.MIL, tcp-ip@SRI-NIC.ARPA
Subject:   Ethernet ring
I believe the product in question was designed with the following goals:

1) Use Ethernet interface, so customer could use any standard Ethernet card in
    the attached equipment.

2) Use FO transmission medium for less bulk and greater resistance to
   environmental electrical issues (noise, grounding, wiretapping)

The ring topology was chosen as the easiest way to get the signal around to all
the stations with FO. The above is based on my fuzzy recollection of a
conversation with the vendor a few years ago.

As I recall, the taps are active, which makes them cost more.  Collisions
happen within the taps, where the signals are regenerated, rather than on the
"wire".  This means that the Ethernet cable length restrictions don't apply,
since those restrictions are required only to insure that if one station sees a
collision, all stations will.  I think it also means Ethernet packet size
restrictions are not required, but since the intent was to use standard
Ethernet boards, this restriction is retained.

If you want to use Ethernet and FO, another alternative is the FO "star
couplers" sold by Siecor and Codenoll, among others.  In this approach the
light signals from a number of fiber runs are combined optically in a fused
glass central location.  We are using one of these at BBN as the "backbone" to
which each of our many coax Ethernets is connected (via a bridge).  The biggest
disadvantage to this approach is that any changes are harder than one would
like, due to the careful consideration that has to be given to the light level
on each arm of the star (the signals have to be well enough balanced so that a
collision between the strongest and the weakest is noticed, and the signal
input on each arm has to be strong enough so that 1/n-th of it is strong enough
to be detected by the receiver which is fartherst away).

A third approach is to install coax Ethernet in every machine cluster and
bridge each one to one of the "Ethernet in a box" devices; the bridges can be
connected via FO cable.  This uses FO for the long runs, while keeping the cost
of attachment of individual devices low.  This approach is currently my
personal favorite.

Hope this helps,
Alex McKenzie
 
-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Mar 88 10:53:48 EST
From:      Susan Anderson <APDU@PUCC>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: world record
We all shall send postcards from the Outer Banks!
-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Mar 88 12:06:05 EST
From:      Tony Michel <michel@cct.bbn.com>
To:        tcp-ip@sri-nic.arpa
Subject:   NCSA Telnet
Well, Thanks!  I got a lot of helpful offers about how to get RFCs!  More to
the point, enough people were surprised by the notion of Telnetting from
a Mac, that it's worth a few sentences.

My Mac SE is linked with many other Macs on my floor, and to some LaserPrinters
and to a gateway, by AppleTalk.  The gateway is built by Kinetics.  It is co
connected in turn to the BBN Ethernet segment in my building, which somehow
is gateway'ed into the INternet.  On my Mac i run a program created by
the National Center for Supercomputing Applications (NCSA), which implements
a terminal emulator, user Telnet, TCP and IP, and knows how to package the
IP datagrams up in AppleTalk to send them across to the Kinetics gateway.
My Mac is a real host on the Internet!  

This system works very well, and is shockingly cheap.

Having said something nice, now let me grumble.  The correct solution to
my previous query would be to have the NCSA software support  User FTP, and
I'm not sure why it does not.  Perhaps they have plans?  Anyway, for
something FREE, it's great.

While waiting for User FTP, I have to log into your system, however.
The problem is not confined to RFCs.  This approach means that I cannot
access any of the anonymous ftp services anywhere.  Naturally it is possible
to use a third party that has User FTP, but I really believe in this desk-top
computing stuff!  I don't want to log into my klunkey old UNIX system, if
I can avoid it.

Hmm, while I'm grumbling...it would be nice if the terminal emulator did
a better job of emulating the VT100.  How about installing tn3270 as well?
If only it could do tnUNISCOPE as well, I'd be in Seventh Heaven!

Anyway, Thanks, NCSA!  It's a great program just as it stands (V 1.12)

AXM

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Mar 88 12:13:24 EST
From:      ves@mitre-bedford.ARPA (Sovinsky)
To:        tcp-ip@sri-nic.ARPA
Subject:   spec for ulana sw and sec
Introductory Note:

The Standard System Center is preparing an Air Force-wide acquisition
of LAN interface software (ULANA compatible) and PC security
hardware/software.

The equipment performance specification which follows this
introductory note is provided for comments and suggestions.  This is
an informal medium, and the Standard Systems Center will not be held
accountable for the disposition of the comments received.  This is
provided as a courtesy to the vendor community and provides them a
chance to point out any errors we may have made.  The Standard Systems
Center in no way has to provide any response to the vendor about the
comments received.

The suspense date for comments is April 7, 1988.  Your prompt action
will be appreciated.  You may direct your comments to the following
two points of contact:

     Technical Issues:  Lt Robinson, 205-279-4555

     Contracting Issues:  Dwynell Streeter 205-279-5520


You may also contact the following staff at MITRE:
     
     Stan Ames  617-271-3182

     Vivian Sovinsky 617-271-7780



We apologize for attaching to this message the complete draft
specification which is about ten pages in length.

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



HQ SSC/SSMC                                                      EPS-88-001
Gunter AFS, AL 36114                                           08 Mar 1988


                 DRAFT EQUIPMENT PERFORMANCE SPECIFICATION
                                    FOR
                 LAN SOFTWARE AND SECURITY MODULE CONTRACT

1.0.  SCOPE.

1.1.  Intent.  This aquisition is for disk operating system (DOS) hosts
with integral ULANA host attachments.  This Equipment Performance
Specification (EPS) defines the requirement to obtain local area network
(LAN) software and a microcomputer security module through an indefinite
delivery, indefinite quantity requirements contract.  This shall be a
procurement of commercial off-the-shelf (COTS) products.  In order to be
considered COTS, not more than 10 percent of the original code may be
changed or added.  (For example, if the original program consisted of
10,000 lines of code, not more than 1,000 lines can be changed or added.)

1.2.  Documents.  Supporting documentation for the operation of the
packages shall be delivered in accordance with paragraph 3.3.

2.0.  APPLICABLE DOCUMENTS.

2.1.  Government Documents.  The following documents of the exact issue
shown (or successors where indicated) form a part of this specification to
the extent specified elsewhere in this specification.  In the event of a
conflict between the documents referenced below and the contents of this
specification, the information in this document shall be considered
superseding requirements.

      2.1.1.  Military Standards.

      MIL-STD-1777, 12 Aug 83, Internet Protocol (IP).
      MIL-STD-1778, 12 Aug 83, Transmission Control Protocol (TCP).
      MIL-STD-1780, 10 May 84, File Transfer Protocol (FTP).
      MIL-STD-1781, 10 May 84, Simple Mail Transfer Protocol (SMTP).
      MIL-STD-1782, 10 May 84, TELNET Protocol.
      MIL-STD-129J, 25 Nov 86, Marking for Shipment and Storage.

      2.1.2.  Requests for Comment (RFC).

      RFC 904 (or successor), Apr 87, Exterior Gateway Protocols.
      RFC 1001, 1002, Feb 87, NETBIOS.
      RFC 960 (or successor), Dec 85, Assigned Numbers.
      RFC 768, Aug 80, User Datagram Protocol.
      RFC 792, Sep 81, Internet Control Message Protocol.
      RFC 821, Aug 82, Simple Mail Transfer Protocol.

      2.1.3.  Government Specifications.

System Specification for the Air Force Unified Local Area Network
Architecture (ULANA I), 17 Apr 87.
                                                                 EPS-88-001
                                                                08 Mar 1988

System Specification for the Standard Multiuser Small Computer
Requirements Contract (SMSCRC), 20 Feb 87.

      2.1.4.  Other Standards.

Institute of Electrical and Electronics Engineers Standard 802.3 (IEEE
802.3), 1985.

2.2.  Availability of Applicable Documents.  The specifications,
standards, and other documents cited herein that are not provided as a
part of the solicitation and are not readily obtainable may be examined at
HQ SSC/PKB, Bldg 1011, Gunter AFS AL  36114.

3.0.  REQUIREMENTS.

3.1.  General.  The LAN software shall allow users in various locations to
communicate with one another, share data and executable files, and share
peripherals via the ULANA network.  The security module shall prevent
unauthorized  access to workstations.  The government shall have the right
to make working backup copies of each software package purchased for its
use.  Copy protected software is not acceptable.  The backup copies must
execute in the same manner as the originally shipped disks.

3.2. Operational Concept.  The contractor(s)  shall provide software and
documentation as described in the following paragraphs for use at
worldwide government locations.  The software shall be orderable on both 3
1/2-inch and 5 1/4-inch media.

      3.2.1. Overall Operational  Criteria - LAN Software.  The contractor
provided LAN software shall fully support the following functionally
described minimum characteristics and requirements:

              3.2.1.1.  The required software shall operate and be
completely compatible with the Zenith Z-150, Zenith Z-200T, Zenith Z-248,
Sperry PC, and IBM PC XT/AT or compatibles running MS-DOS 3.1 and later
with ULANA host attachments.  The LAN software shall not interfere with,
degrade the performance of, or prevent the proper operation of the ULANA
host attachments.

              3.2.1.2.  The software shall provide the functions necessary
to support the following client-server architectures:

              3.2.1.2.1  Non-dedicated LAN server - the software shall
allow two or more PCs to function as servers in a non-dedicated mode.  The
software shall not use more than 256 KB of base memory.  The software
running in a client machine may use but  not require  extended memory
which is
available from Zenith Data Systems for the Zenith microcomputers.  The
available extended memory on the Zenith microcomputers is between 512 KB
and 2.5 MB.  The software shall be limited to the use of 256 KB of
extended memory for server and slave operation.  A PC shall have the
capability to act as a server and a client on the network at the same time.
                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.1.2.2. Dedicated LAN server - the software shall allow
two or more PCs to function as servers in a dedicated mode.  If the
dedicated server requires a different operating system (other than DOS 3.1
and later) it must be included with the LAN software.

             3.2.1.2.3.  Client workstation - The software shall not use
more than 128 KB of base memory when installed and configured as a client.
The software running in the client machine may use but does not require
extended memory  which is available from Zenith Data Systems for the
Zenith microcomputers.  The available extended memory on the Zenith
microcomputers is between 512 KB and 2.5 MB.  The software shall be
limited to the use of 256 KB of extended memory for server and slave
operation.  A PC shall have the capability to act as a server and a client
on the network at the same time.

             3.2.1.2.4.  SMB Server Interoperability - The software shall
interoperate with an SMB server that conforms with NETBIOS as per RFCs
1001 and 1002.

              3.2.1.3. Each micro-computer listed in 3.2.1.1 that must run
the local area network application software provided under this contract
will be provided with an installed ULANA host attachment.  A NETBIOS
service level interface that conforms to RFCs 1001-1002 will be provided
as part of this host attachment.  The LAN Application software shall
utilize this service level interface to communicate with other
micro-computers across the LAN.  While running the local area network
software it shall be possible to execute TELNET, FTP,  and other DOS-based
applications provided under the ULANA contract.

              3.2.1.4.  The software shall be icon-driven, menu driven and
command driven at the users option (2 out of the 3 options).

              3.2.1.5.  The software shall provide the capability of
switching between the network and the operating system.  It shall
accomplish this through use of options available in 3.2.1.4..

              3.2.1.6. For  all  machines  listed in 3.2.1.1., the
software shall support a minimum of 16 concurrent users per server.

              3.2.1.6.1  For all machines listed in 3.2.1.1., the software
shall support a minimum of 100 users per server.

              3.2.1.7.  The software shall support the following input
devices:

       Device                               Zenith Data Systems Part No
       ------                               ---------------------------
Z-150/200
Keyboard                                              181-6894
TEMPEST Kurta Tablet                                  AFP-11-T
                                                                 EPS-88-001
                                                                08 Mar 1988

Z-248
Keyboard                                              HE-163-24
Summagraphics Summasketch Input Device                SI-1201
Logitech Mouse                                        LG-7
Tempest Kurta Tablet                                  AFP-11-T

              3.2.1.8  The software shall allow the sharing of output
devices, to include as a minimum:

       Device                               Zenith Data Systems Part No
       ------                               ---------------------------
Z-150/200
Z-150 CGA Color Monitor                               ZVM-133-T
Z-150 Monochrome Monitor                              ZVM-122-T
Dataproducts DP55Q Letter Quality Printer             TT-5155
Dataproducts TCG200 Dot Matrix Color Printer          AFP-4-T
DMP-29T Plotter                                       DMP-29-TM

Z-248
Monochrome Monitor                                    ZMM-1470-G
EGA Color Monitor                                     ZVM-1380
ALPS P2000G Dot Matrix                                AL-2000
Diablo TC150 Ink Jet Printer                          AFP-8-T
Western Graphtec MP 2300 Plotter, 8 Pen Self Capping  WG-2300
CTS 2424 Dial Up Modem                                ZM-2424
Zenith Modem (Hayes 2400 baud)                        ZM-2401
Xerox 4020 Ink Jet Printer                            DS-200
Asynchronous 9600 Baud Voice/Data Modem               ZM-192
MPI Printmate 350 Dot Matrix Printer                  MPI-350-B1
Primage 90 Letter Quality Daisy Wheel Printer         PP-252
Genicom 3184 Dot Matrix Printer                       AFP-6-TG
Diablo 630 Daisy Wheel Printer
Okidata 83A Dot Matrix Printer
MPI Printmate 180 FT Dot Matrix Printer
Diablo Advantage 80 Daisy Wheel Printer
DMP-29 Plotter, 8 Pens
HP HGL Output Devices
Postscript Output Devices

              3.2.1.9  The software shall provide a backup capability for
shared network files utilizing the users choice of the following:

Irwin 20 MB Tape Backup System                  Z-427-20
Interdyne 20 MB Tape Backup System              ID-6025
Scorpion 60 MB Internal Tape Backup Drive       ZD-60

Shall back up 20 MB in less than 20 minutes and have unlimited capacity.

              3.2.1.10  The software shall allow the user to run the
following application programs when stored on the server from the standard
small computer requirements contracts and their NETBIOS compatible LAN
versions when they become available:
                                                                 EPS-88-001
                                                                08 Mar 1988

     Package                     Version                   Contract
     -------                     -------                   --------

Wordstar Professional         3.31 and later       Z-248 (F19630-86-D-0002)
Multimate                     3.3 and later        Z-248 (F19630-86-D-0002)
dBASE II                      2.43 and later       Z-248 (F19630-86-D-0002)
dBASE III                     1.1 and later        Z-248 (F19630-86-D-0002)
Condor III                    2.11 and later       Z-248 (F19639-86-D-0002)
Microstat                     4.0 and later        Z-248 (F19630-86-D-0002)
Supercalc 3                   2.1 and later        Z-248 (F19630-86-D-0002)
Graftalk                      3.27 and later       Z-248 (F19630-86-D-0002)
4-Point Composition Graphics  1.57 and later       Z-248 (F19630-84-D-0009)
Cad Key                       2.0 and later        Z-248 (F19630-86-D-0002)
Timeline                      2.0 and later        Z-248 (F19630-86-D-0002)
Enable                        1.15 and later       Z-248 (F19630-86-D-0002)
Microsoft Windows             1.01 and later       Z-248 (F19630-86-D-0002)

              3.2.1.11.  The software shall provide windowing and
multitasking capability.  It shall allow the capability to create a
minimum of eight windows allowing the concurrent viewing of eight tasks.
One application selected by the user will execute, and the others will be
suspended until selected.  The tasks may consist of eight different
applications or eight separate executions of a single application.

              3.2.1.12.  The software shall provide network administration
functions to allow for installation and maintenance of the network
software.  These functions shall include adding users, deleting users,
changing passwords, adding shared peripherals, and diagnostics and
statistics tools to identify network load and problems.  The information
provided by the diagnostics and statistics tools shall be more than raw
data--it shall help the user to interpret the data.  This shall not be a
separate software package.

              3.2.1.13.  The software shall allow a password for each user
identification with different levels of access (i.e.:  read only, read
write, etc).  Passwords shall be initially assigned by the network
administrator.  User shall have the ability to change their password.

              3.2.1.14.  The software shall provide full file sharing
capabilities that allow the user to:

              3.2.1.14.1.  Grant, remove, and change access to their files
on the LAN.

              3.2.1.14.2.  Grant file access to a single user, multiple
users, and all users on the LAN using options available in 3.2.1.4.

              3.2.1.14.3.  Specify type of access granted to other users
to include: none, read only, write only, execute, and read-write.

              3.2.1.14.4.  Grant access to a single file, a group of
files, an entire subdirectory, and an entire drive.
                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.1.14.5.  Place a password on files to which the user has
granted access to others so that the other user must use that password to
access the files.

              3.2.1.14.6.  Display a listing of all files to which the
user has granted access to other users and the type of access they have.

              3.2.1.14.7.  Display a listing of all the files to which
others have granted the user access and the type of access they have.

              3.2.1.15.  While running the LAN software, the user shall be
able to invoke all DOS application programs.

              3.2.1.16.  The software shall provide options available in
3.2.1.4 for the installation procedure.

              3.2.1.17.  The software shall allow workstations to link to
any shared peripheral on the network.

              3.2.1.18.  The software shall provide print spooling with
the capability to reorder print queues, delete print files and queues, and
move print files and queues to other printers.

              3.2.1.19.  The software shall provide context sensitive help
facility accessible from all workstations.

              3.2.1.20.  The software shall provide error messages that
correctly identify the error and explain how to correct it.

              3.2.1.21.  The software shall provide remote dial-in
capability that allows access to all network resources and capabilities.
It shall support user selectable data transmission speeds ranging from 300
BPS to 19.2K BPS (300, 1200, 2400, 9600, 19,200).

              3.2.1.22.  As a late deliverable, the contractor shall
provide a version of the software that will run with the SMSCRC operating
system that is functionally conformable with the System V Interface
Definition (SVID).  This version shall provide a user interface as similar
to that of the PC version as possible.

               3.2.1.23.  Additional consideration shall be given to those
contractors who offer a version of the software to be installed and
configured on the Zenith Z-100 computer to enable it to operate as a
client node on a network.  This version of the software must operate the
same as and provide a user interface identical to that of the software for
the machines cited in 3.2.1.1.

              3.2.1.24.  The software shall provide electronic mail
facilities.  It shall support a minimum of 100 mailboxes, which shall be
established by the network administrator.  It shall support both text and
non-text (8-bit ASCII).  The maximum size of electronic mail messages
shall be limited only by the amount of storage space the user has
available.




                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.1.24.1.  The capabilities shall include:

                  3.2.1.24.1.1.  Choose and read a message.

                  3.2.1.24.1.2.  Create a message with an editor supplied
by the vendor.

                  3.2.1.24.1.3.  Send a message.  Retain a copy of the
message if desired.

                  3.2.1.24.1.4.  Reply to a message.

                  3.2.1.24.1.5.  Forward a message and/or series of
messages.

                  3.2.1.24.1.6.  Delete a message and/or series of
messages.

                  3.2.1.24.1.7.  Send a courtesy copy (cc) of a message to
addresses upon transmission.  Shall allow for the creation, storage, and
use of distribution lists.

                  3.2.1.24.1.8.  Copy a message and/or series of messages
into a file.

                  3.2.1.24.1.9.  Insert files into the body of a message
and include as attachments to a message. (minimum of 10 files)

                  3.2.1.24.1.10.  Display headers including:  Date,
Subject, Return address, Read and unread, Answered and Unanswered, Flagged
and Unflagged.

                  3.2.1.24.1.11.  The user should be able to send and
receive electronic mail using this electronic mail facility to and from
other hosts on the network that only utilize the SMTP protocol for
electronic mail exchange from a host supported by ULANA using SMTP
protocol.

                  3.2.1.24.1.12.  Shall provide positive confirmation of
addressee receipt of message.

                  3.2.1.24.1.13.  Notify user upon log-in that he has new
mail.

                  3.2.1.24.1.14.  Save mail to a file of user's choice.

              3.2.1.24.2.  The message shall include the following fields
in data area:

                  3.2.1.24.2.1.  Subject.
                                                                 EPS-88-001
                                                                08 Mar 1988

                  3.2.1.24.2.2.  Comments (on forwarded or resent
messages).

                  3.2.1.24.2.3.  Return path (explicit series of
forwarding hosts/gateways).

                  3.2.1.24.2.4.  Return address.

                  3.2.1.24.2.5.  Date.

              3.2.1.25.  The software shall have a network calendaring
capability with the following functions:

              3.2.1.25.1.  It shall allow creation and use of a minimum of
100  calendars per server.

              3.2.1.25.2.  It shall provide for public and private
calendars that shall cover a minimum of 12 previous months and 12
subsequent months to the current month.

              3.2.1.25.3.  It shall display a planning calendar by day,
week, or month at the users option.  As a minimum, the daily calendar
shall allow 80 characters per entry; the weekly calendar 40 characters per
entry; and the monthly calendar 20 characters per entry.

              3.2.1.25.4.  It shall allow the user to print a hard copy of
daily, weekly, and monthly calendars.

              3.2.1.25.5.  It shall allow the user the capability to
designate other users who will have access to view and modify his calendar.

              3.2.1.25.6.  It shall allow the user to input information to
his own calendar and to calendars to which he has access.

              3.2.1.25.7.  It shall have appointment scheduling
capabilities such that a user may specify individuals whose calendars
should be checked for open time (during a specified day or week).  When a
common time is found, it shall reserve the time slot on each attendees
calendar.  It shall also check the availability of meeting rooms and
equipment for the meeting and schedule them as well.  In case of multiple
openings, the utility shall query the user scheduling the appointment as
to the desired time.

              3.2.1.25.8.  It shall allow the user to delete a scheduled
event from multiple calendars with a single action.

              3.2.1.25.9  It shall provide a calendar "scratch pad"
function which allows any user to propose calendar updates to any other
users' "scratch pad", plus a calendar update utility which allows each
user to review his scratch entries off-net and accept or reject proposed
updates to their actual calendar file.
                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.2.  Operational Concept - Security Module.  The
contractor-provided security module shall, through the use of a  software
and hardware combination and without affecting the normal operation of the
PC, fully support the following functionally described minimum
characteristics and requirements:

         3.2.2.1.  Shall be completely compatible with the Zenith Z-248
model computers manufactured by Zenith Data Systems running MS-DOS 3.1 or
later.

         3.2.2.2.  Shall have a password for each user identification with
different types  of access (disk, directory, and files).  This password
shall be user modifiable.

         3.2.2.3.  Shall keep an audit trail of user accesses both
successful and unsuccessful.  After a given number of unsuccessful log-on
attempts (as determined by the network administrator), shall record the
access attempts and the time in the audit trail and shall lock out the
unauthorized user by disabling the keyboard or CPU.

         3.2.2.4.  When a successful access is completed, shall provide an
audit trail report showing all access attempts made and what functions
were done during each access.  This report shall cover the previous 24,
48, or 72 hours at the users option.  At the end of the user specified
period, the audit trail data will be deleted. (For example, if the user
specifies a 24 hour audit trail, at the end of the 24th hour, the data for
hour 1 is deleted to make room for the data for hour 25.)

         3.2.2.5.  Shall prevent unauthorized users from booting system
(including booting from the floppy drive).

         3.2.2.6.  Additional consideration shall be given to those
contractors who offer a security module package to be installed and
configured on the Zenith Z-100 computer.  This version of the security
module must operate the same as and provide a user interface identical to
that of the software for the Z-248.

Note:  If meeting these requirements requires the use of an internal
board, that board shall fit into an available PC slot in the Z-248 and an
available slot in the Z-100 (if offered).  Different boards will be
permitted for each model of computer.  This board, if offered, shall not
interfere with the normal operation of the system in which it is installed.

3.3.  Documentation.

              3.3.1.  Contractor(s) shall provide comprehensive
documentation to accompany each software package.  Proposals should be
made for documentation as a separately orderable item and as bundled with
the software.  When bundled with the software, the price of the
documentation will be included in the price of the software.  This
documentation shall contain
                                                                 EPS-88-001
                                                                08 Mar 1988

explanations of each capability and how to perform it, an error message
key to provide further explanations of error messages described in
3.2.1.19., and a glossary of applicable terms.  It shall be aimed at the
novice user so that even a beginner can use the software with minimal
assistance.

              3.3.2.  The contractor(s) shall furnish the government any
changes to documentation within 60 days after notification of errors in
the original documentation or of discrepancies in the software that render
the documentation incorrect.

              3.3.3.  The contractor(s) shall furnish an installation
manual with each file server package.  This volume shall describe, in
detail, the software installation process and procedures, and how to set
up the network.

3.4.  Delivery of Orders.

      3.4.1.  The first delivery of each CLIN/SLIN shall be delivered to
Gunter AFS Alabama 6 work days after receipt by contractor of a delivery
order.  Subsequent deliveries shall be made to the "ship to" address
indicated on each delivery order.

      3.4.2.  The contractor(s) shall ship orders within 21 days of
arrival of the delivery order at the contractor's location.

3.5.  Warranties.

      3.5.1.  All software and hardware components purchased through this
contract shall be warranted against all defects and failures for a period
of 1 year.  All defective items that fail during the warranty period will
be returned to the contractor via a common carrier at government expense.
Replacements of defective items shall be made free of charge within 4
working days of contractor's receipt of the returned defective item.
Contractor shall pay the cost of shipping the replacement items.

     3.5.2.  For CONUS deliveries, the warranty period for a given
delivery order shall not begin until delivery of the items to the
specified destination or 15 days after government acceptance of the
delivery, whichever occurs first.

    3.5.3.  For OCONUS deliveries, the warranty period for a given
delivery order shall not begin until delivery of the order to the
specified location or 30 days after government acceptance of the delivery,
whichever occurs first.

3.6.  Updates and Upgrades.

    3.6.1.  Updates.

             3.6.1.1.  An update shall be defined as:  Corrections and/or
additions to existing versions of a product that cause the product to
operate as specified in this solicitation.
                                                                 EPS-88-001
                                                                08 Mar 1988

             3.6.1.2.  Free updates and corrected documentation shall be
made available to Air Force users not more than 60 days after the
contractor(s) receives official notification by the government of a
problem, or within 30 days after commercial availability of the update.
When an update is necessary, users will send the contractor a letter
stating the serial numbers from their originally purchased packages and
the address to which the update should be mailed.  The contractor shall
send updates on diskette and corrections to documentation in hardcopy
form.  These items must be mailed to the user within 7 work days after
contractor received the letter from the user.

    3.6.2.  Upgrades.

             3.6.2.1.  An upgrade shall be defined as: A new version of
the product with corrections and enhancements not available in previous
versions.

             3.6.2.2.  If, after the contract is awarded, the
contractor(s) markets a new commercial version of the product, the added
features and enhancements of the new commercial version and updated
documentation shall be proposed to the government in the form of an
upgrade to the government version of the package.  This proposal shall be
made within 30 days of the availability of the new commercial version.
The government may elect to modify the contract and, at its option, may
have the new version delivered in lieu of the originally specified
package.  Upgrades shall be listed as a separate contract line item.

              3.6.2.3.  Method of distribution is negotiable prior to
contract award.  Suggested method is to notify government users of the
update and have them send their original diskettes to the contractor who
in turn will return the upgraded version to the user.  The user shall
receive the upgraded versions within 7 working days of contractor receipt
of the original diskettes.

              3.6.2.4.  The price of the upgrade will be proportional to
the price of the originally offered package.  For instance, if the
original package was offered to the Air Force at 50 percent of its
commercial price, then the upgrade must also be offered to the Air Force
at 50 percent of its commercial price.

3.7.  Support.

    3.7.1.  The contractor(s) shall furnish a point of contact for
questions/problems.  This individual or individuals must be identified by
name, address, and toll-free telephone number.  The toll-free number shall
be manned between 0800 and 1700 Central Time, Monday through Friday
(except Federal Holidays) for the life of the contract.

    3.7.2.  The contractor(s) shall be required to maintain a data base
providing the following information on one screen:

             3.7.2.1.  order acceptance date (date order received by
contractor)

             3.7.2.2.  ship date (expected and actual)


                                                                 EPS-88-001
                                                                08 Mar 1988

             3.7.2.3.  ship-to address

             3.7.2.4.  list of items on order

Note:  The government shall have access to this data base at any time
through the use of the contractor-supplied toll-free phone line described
in 3.7.1. above and a standard asynchronous telecommunications package
(such as HyperAccess or Enable).  The data base shall be accessible by
delivery order number or by ship-to address at the users option.

3.8.  Monthly Reports.

    3.8.1.  The contractor(s) shall provide monthly production and
delivery reports on the fifth work day of each month.  These reports shall
contain the ordering status for the previous month (number ordered, number
delivered, number returned with defects) and the dollar amount associated
with these orders.  In addition, the ordering status and dollar figures
for the total period of the contract up to the end of the previous month
are also required (number ordered-to-date, number delivered-to-date,
number returned-to-date, explanation of backorders).

    3.8.2.  The contractor(s) shall also furnish the Small Computer Office
Automation/Service Organization (SCOASO) at Gunter AFS a monthly report
synopsizing the calls received over the toll-free line described in 3.7.1.
above.  This report shall specify the problem calls received and the
solutions given.

3.9.  Training.  The offered packages shall provide a computer aided
instruction module and interactive tutorial to provide an overview of the
products and aid the user in learning the capabilities of the products.

3.10.  Preparation for Delivery.

    3.10.1.  Packaging.

            3.10.1.1.  The contractor(s) is responsible for the
preservation, packaging, and packing of all items to be delivered under
the terms of this contract in such a manner that adequate protection is
provided against corrosion, deterioration, and physical damage during
shipment and handling from source of supply to final destination.  The
contractor's commercial packaging practice is acceptable in the event
these practices provide the required protection.  The contractor(s) is
fully liable for any damage, deterioration, and losses incurred during
shipment and handling unless the damage, deterioration, and losses are the
fault or negligence of the government.  Marking shall be in accordance
with MIL-STD-129J,  25 Sep 84, Marking for Shipment and Storage.

             3.10.1.2.  The government shall be responsible for the
preservation, packaging, and packing to the above standards of all items
returned to the contractor(s) for warranty service.





                                                                 EPS-88-001
                                                           08 Mar 1988

    3.10.2.  Delivery.  For deliveries to CONUS, Alaska and Hawaii
locations, deliverable items shall be F.O.B. destination.  For overseas
deliveries, deliverable items shall be F.O.B. point of exportation (POE).
Examples of initial delivery points for POE shipments are as follows:

    McChord AFB, WA (Japan and Korea)
    Travis AFB, CA (Philippines and Guam)
    Dover AFB, DE (Europe)
    Charleston AFB, SC (Panama)
    Patrick AFB, FL (Puerto Rico)


                    

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 12:48:00 GMT
From:      SNELSON@STL-HOST1.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Rumors about the death of the ARPANET

Just keep in mind that on wire the CENTRAL OFFICE is supplying the power
for your telephones. When you go fiber and you got no 'lectricity= no
'lectrons= no signal.
Steve

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 12:57:11 GMT
From:      michel@CCT.BBN.COM (Tony Michel)
To:        comp.protocols.tcp-ip
Subject:   Public RFCs still needed

I access the Internet from my Macintosh, using NCSA Telnet, which includes
a SERVER ftp.  I can't initiate a transfer.  To fetch a file I must
log in to your system, and send the file back to myself.  Any of you
charitable folks willing to install some sort of "anonymous" account with
login priveleges (maybe only able to run user ftp)?  Then I could actually
fetch those RFCs and IENs.  I suspect I'm not the only one.

AXM

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 12:57:25 GMT
From:      steve@cs.umd.EDU (Steven D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?

As of the last time I looked (SunOS 3.2), you can't turn UDP checksums on
for NFS packets.  A code path that is completely separate from the "normal"
UDP and IP output code paths is being taken.  Has this changed since 3.2
came out?  How many NFS licensees are also not using checksums here?

I still agree with Rick, though; why stuff additional checksumming into
SLIP because of one vendor's code?  NFS at SLIP speeds is likely to be
too painful to contemplate seriously, anyway.  Maybe Sun could add a
"cksum" mount option if they're still reluctant to run with checksums on
UDP/RPC/NFS packets in general?

I fear I'm getting off the subject, though...

	-Steve

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 1988 18:01-EST
From:      CERF@A.ISI.EDU
To:        LYMAN_CHAPIN%ICE9.CEO.DG.COM@ADAM.DG.COM
Cc:        mcvax!enea!tut!jh@UUNET.UU.NET, tcp-ip@SRI-NIC.ARPA
Subject:   Re: OSI does not mean X.25

Not to put too fine a point on it, how many different vendors have
implementations which are either known to interoperate or have been
through COS certification? I'm glad to know the specs are finished.
I will be even more happy to know that there are implementations for
many operating system and hardware bases which can work together and
which you can buy off the shelf. 

Vint
-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Thu, 31 Mar 88 18:15:47 EST
From:      Nick Gimbrone <NJG@CornellA>
To:        tcp-ip@sri-nic.arpa
Subject:   TCP/IP for IBM's MVS
Has anyone compared the alternatives for TCP/IP implementations for the
IBM MVS operating system (e.g. KNET, ACC, etc). A full function
alternative, preferably with nice gateway capability to&from SNA
networks would be ideal (dream on :-).
-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 13:45:21 GMT
From:      petry@TRANTOR.UMD.EDU ("Michael G. Petry")
To:        comp.protocols.tcp-ip
Subject:   Re: link level crap protection

Let me second Mike's statement.  I believe the link level check was only
to give a good/bad indication.  There was no desire to do any kind of
link level correction or retransmission.  The idea was that the limited
line bandwith was "THE" critical resource.  If a system consist of multiple
low speed SLIP hops, you want the toss bad packets ASAP that might clog an
under-bandwidth pipe. If the model is stub only SLIP lines, it may not be
as critical. In a low speed SLIP model CPU should be relatively cheap and
thus the cost for doing the link level check considered tolerable.

I thought the idea was features such as checksum, CRC, compression, etc. were
negotiated on a link by link basis. If you have a link level that delivers an
error rate that is acceptable (ex. trailblazers), don't negotiate for a check.
If you have low tech noisy 2400 (like me) then I'll pay the extra cost.

Mike

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 14:03:00 GMT
From:      CLYNN@G.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re:  Checksums (again)

Dave,	I've never used a CRAY, but assuming it has unsigned arithmetic,
would it be faster to read & split 64-bit quantities similar to
	sum += (((unsigned) DATA) >> 32) + (0xFFFFFFFF & DATA);
or to
	if ( (sum += DATA) < DATA ) sum++;
?

Charlie

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 14:16:00 GMT
From:      mckenzie@LABS-N.BBN.COM (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Ethernet ring

I believe the product in question was designed with the following goals:

1) Use Ethernet interface, so customer could use any standard Ethernet card in
    the attached equipment.

2) Use FO transmission medium for less bulk and greater resistance to
   environmental electrical issues (noise, grounding, wiretapping)

The ring topology was chosen as the easiest way to get the signal around to all
the stations with FO. The above is based on my fuzzy recollection of a
conversation with the vendor a few years ago.

As I recall, the taps are active, which makes them cost more.  Collisions
happen within the taps, where the signals are regenerated, rather than on the
"wire".  This means that the Ethernet cable length restrictions don't apply,
since those restrictions are required only to insure that if one station sees a
collision, all stations will.  I think it also means Ethernet packet size
restrictions are not required, but since the intent was to use standard
Ethernet boards, this restriction is retained.

If you want to use Ethernet and FO, another alternative is the FO "star
couplers" sold by Siecor and Codenoll, among others.  In this approach the
light signals from a number of fiber runs are combined optically in a fused
glass central location.  We are using one of these at BBN as the "backbone" to
which each of our many coax Ethernets is connected (via a bridge).  The biggest
disadvantage to this approach is that any changes are harder than one would
like, due to the careful consideration that has to be given to the light level
on each arm of the star (the signals have to be well enough balanced so that a
collision between the strongest and the weakest is noticed, and the signal
input on each arm has to be strong enough so that 1/n-th of it is strong enough
to be detected by the receiver which is fartherst away).

A third approach is to install coax Ethernet in every machine cluster and
bridge each one to one of the "Ethernet in a box" devices; the bridges can be
connected via FO cable.  This uses FO for the long runs, while keeping the cost
of attachment of individual devices low.  This approach is currently my
personal favorite.

Hope this helps,
Alex McKenzie
 

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 14:31:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?


    Date: Wed, 30 Mar 88 17:59:24 EST
    From: rick@seismo.CSS.GOV (Rick Adams)

    If the byte is 0x40 - 0x4F the packet is considered to be an IP packet
    and the protocol type byte IS INCLUDED as part of the packet.
    (Astute observers will realize that this is an IP Version Number of 4
    combined with all of the possible IP header lengths.)

Modular programmers and people who program generically will realize this
is a Rube Goldberg mentality and will barf.

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 15:00:58 GMT
From:      LYMAN_CHAPIN@ICE9.CEO.DG.COM
To:        comp.protocols.tcp-ip
Subject:   OSI does not mean X.25

This just in from Juha Heinanen in Finland:

>> In article <8803261505.AA04812@wb6rqn.UUCP> brian@wb6rqn.UUCP (Brian Lloyd)
>> writes:
>> >European attendees.  The consensus was that OSI really wasn't happening
>> >and that they were all planning to go the TCP/IP route.  I guess that
>> >the ISO/OSI hard-sell has created a market that only TCP can currently
>> >fill.
>>
>> Pretty much a correct observation.  The POLITICAL plan is to go the
>> connection oriented (X.25) OSI route that doesn't care about local
>> area networks (it only cares about the profits of PTT monopolies). So
>> if you want to build a LAN and connect it to another LAN what else
>> have you got except TCP/IP?

Evidently there are still people who see "OSI" and hear "X.25" and
"connections".  ** THIS IS NOT A VALID ASSUMPTION! **

You can have OSI with a Transport protocol similar to TCP (ISO 8073)
and a connectionless internetwork protocol (ISO 8473) even more similar
to IP.  You do not have to have X.25.  You do not have to have PTTs.
You do not have to have network connections.  There is NO part of OSI
that requires X.25 (although if X.25 is all you have, you can use it to
support OSI).  OSI loves LANs.  The OSI IP likes nothing better than
to connect LANs together (or to any other type of subnetwork).

With the ISO IP, you also get a host-gateway routing protocol (ISO
9542), and you will soon get a gateway-to-gateway routing protocol
(a link state routing scheme based on DECnet Phase V routing).  If
you need X.25 to get across a PTT (or for any other reason), you
can run ISO IP on top of it (it looks like just another point-to-
point link), keeping the connectionless internet intact.

ALL OF THIS IS AVAILABLE *NOW*.  The Transport, Internet, and host-
gateway protocol standards are done.  They are not "working drafts".
They are being implemented.  They are already available in commercial
products from at least one large computer manufacturer (DG).  You
can get copies of the standards from your local national standards
body.  In Finland, call Esko Ojanpera at (+358)-0-456 65-6.

-----------------------------------------------------------------------------
Lyman Chapin                  lyman@ice9.ceo.dg.com
Data General Corp.            [lyman%ice9.ceo.dg.com@relay.cs.net]
(617) 870-6056
-----------------------------------------------------------------------------

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 15:18:36 GMT
From:      louie@TRANTOR.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP working group?

Just to add fuel to the fire..  The NFS implementation under Ultrix (DEC's
UNIX product) does in fact use UDP checksums.  Works just fine.

The intent of the CRC on the SLIP frame wasn't exclusively to support SUN
NFS, although it was a large motivating factor.  Once we thought about it,
it seemed to be a good idea to be able to drop a frame which has been
trashed in transit.  This way you wouldn't be forwarding a broken frame
across multiple (probably slow) SLIP links.

There was no intention of having SLIP retransmit or attempt to recover 
broken frames.

louie

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 16:11:00 GMT
From:      leff@smu
To:        comp.protocols.tcp-ip
Subject:   Integrated Network Management Call



____________________________________________________________

              ANNOUNCEMENT AND CALL FOR PAPERS
           FIRST IFIP INTERNATIONAL SYMPOSIUM ON
               INTEGRATED NETWORK MANAGEMENT

                  BOSTON, May 14-17, 1989

The First  International  Symposium  on  Integrated  Network
Management  sponsored  by  IFIP WG 6.6 and hosted jointly by
the National Bureau of Standards and MITRE corporation  will
be  held  in  Boston.  The  objective of the symposium is to
create an international forum for information  exchange  and
cooperation  between  vendors,  system  integrators,  users,
researchers, and standardization  bodies.  Presentations  on
management  policy,  administration,  and operation of local
and wide area communication networks, including data, voice,
and integrated communications are solicited.  In particular,
the program of the symposium will concentrate on the follow-
ing  subjects, emphasizing the integration of different sys-
tems:

    o management requirements and standardization issues

    o models/architectures/algorithms

    o fault, configuration and name, accounting,
      performance, and security management

    o heterogeneous networks

    o protocols

    o quality of service

    o management data bases

    o knowledge based systems

    o planning systems

    o user interfaces and management languages

    o implementations and case studies

    o and other related topics

The Proceedings of the symposium  will  be  published  as  a
hardbound  volume  by  the North-Holland publishing company.
Authors are invited to submit unpublished papers on the top-
ical areas indicated. Contributions of a more general nature
(tutorial) are also welcome. Please submit five  copies  (in
English,  restricted to 12 single spaced pages) to either of
the two addresses by September 1, 1988. The cover page  must
contain:  the  paper title, full name, affiliation, complete
address and phone number of each author. All papers will  be
refereed.    Acceptance  notifications  will  be  mailed  by
December 1, 1988. Final camera  ready  papers  will  be  due
January 10, 1989.



General Chair:                   Program Committee:
Paul Brusil, MITRE, USA          Sudhir  Aggrawal,  Bell   Com.
                                 Res., USA

General Vice-Chair               Eric Aupperle, U. of Michigan,
Dan Stokesberry, NBS, USA        USA

                                 Dave Clark, MIT, USA

                                 Andre Danthine, University  de
                                 Liege, Belgium

                                 Deborah Estrin, U.  of  South.
                                 California, USA

Program Co-Chair                 Guy  Juanole,  LAAS  du  CNRS,
Branislav Meandzija, SMU, USA    France

                                 Kim   Kappel,   Digital   Com.
                                 Assoc., USA

                                 Dipak  Khakhar,  Lund  Univer-
                                 sity, Sweden

Program Co-Chair                 Gautam Kar, IBM Research, USA
Jil Westcott, BBN Labs., USA
                                 Yoshikazu   Kobayashi,    IBM,
                                 Japan

                                 Koos Koen, Informatica, ZA

Submit papers to either          Gerard Le Lann, INRIA, France
Branislav Meandzija (Americas,
Australia)                       Gesualdo   LeMoli,   Pol.   di
SMU, CSE Department, 322 SIC     Milano, Italy
Dallas, TX 75275 - 0122, USA
                                 Louis Pouzin, CNET-PAA, France
or

Wolfgang    Zimmer    (Europe,   R.   Rathnasabapathy,   North.
Africa, Asia)                    Tele. Inc., USA
GMD-FIRST, Hardenbergplatz 2
D - 1000  Berlin  -  12,  West   Morris Sloman,  Imperial  Col-
Germany                          lege, UK

For further  information  con-   Chris Sluman, CAP  Group  PLC,
tact                             UK
Hershey Young
NBS, B217  TEC,  Gaithersburg,   Brian  Spratt,  University  of
MD 20899                         Kent, UK
(Tel: (301) 975-3600)
                                 Carl Sunshine, UNISYS, USA

                                 Liba Svobodova, IBM  Research,
                                 Switzerland

                                 Liane  Tarouco,  U.  Fed.  Rio
                                 Grande Sul, Brazil

                                 Keith    Travorrow,    British
                                 Telecom, UK

                                 Steve Wilbur, University  Col-
                                 lege London, UK

                                 Wolfgang  Zimmer,   GMD-FIRST,
                                 West Germany
_______________________________________________________________

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 16:51:39 GMT
From:      ves@MITRE-BEDFORD.ARPA (Sovinsky)
To:        comp.protocols.tcp-ip
Subject:   draft ulana sw & sec spec

Introductory Note:

The Standard System Center is preparing an Air Force-wide acquisition
of LAN interface software (ULANA compatible) and PC security
hardware/software.

The equipment performance specification which follows this
introductory note is provided for comments and suggestions.  This is
an informal medium, and the Standard Systems Center will not be held
accountable for the disposition of the comments received.  This is
provided as a courtesy to the vendor community and provides them a
chance to point out any errors we may have made.  The Standard Systems
Center in no way has to provide any response to the vendor about the
comments received.

The suspense date for comments is April 7, 1988.  Your prompt action
will be appreciated.  You may direct your comments to the following
two points of contact:

     Technical Issues:  Lt Robinson, 205-279-4555

     Contracting Issues:  Dwynell Streeter 205-279-5520


You may also contact the following staff at MITRE:
     
     Stan Ames  617-271-3182

     Vivian Sovinsky 617-271-7780



We apologize for attaching to this message the complete draft
specification which is about ten pages in length.

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



HQ SSC/SSMC                                                      EPS-88-001
Gunter AFS, AL 36114                                           08 Mar 1988


                 DRAFT EQUIPMENT PERFORMANCE SPECIFICATION
                                    FOR
                 LAN SOFTWARE AND SECURITY MODULE CONTRACT

1.0.  SCOPE.

1.1.  Intent.  This aquisition is for disk operating system (DOS) hosts
with integral ULANA host attachments.  This Equipment Performance
Specification (EPS) defines the requirement to obtain local area network
(LAN) software and a microcomputer security module through an indefinite
delivery, indefinite quantity requirements contract.  This shall be a
procurement of commercial off-the-shelf (COTS) products.  In order to be
considered COTS, not more than 10 percent of the original code may be
changed or added.  (For example, if the original program consisted of
10,000 lines of code, not more than 1,000 lines can be changed or added.)

1.2.  Documents.  Supporting documentation for the operation of the
packages shall be delivered in accordance with paragraph 3.3.

2.0.  APPLICABLE DOCUMENTS.

2.1.  Government Documents.  The following documents of the exact issue
shown (or successors where indicated) form a part of this specification to
the extent specified elsewhere in this specification.  In the event of a
conflict between the documents referenced below and the contents of this
specification, the information in this document shall be considered
superseding requirements.

      2.1.1.  Military Standards.

      MIL-STD-1777, 12 Aug 83, Internet Protocol (IP).
      MIL-STD-1778, 12 Aug 83, Transmission Control Protocol (TCP).
      MIL-STD-1780, 10 May 84, File Transfer Protocol (FTP).
      MIL-STD-1781, 10 May 84, Simple Mail Transfer Protocol (SMTP).
      MIL-STD-1782, 10 May 84, TELNET Protocol.
      MIL-STD-129J, 25 Nov 86, Marking for Shipment and Storage.

      2.1.2.  Requests for Comment (RFC).

      RFC 904 (or successor), Apr 87, Exterior Gateway Protocols.
      RFC 1001, 1002, Feb 87, NETBIOS.
      RFC 960 (or successor), Dec 85, Assigned Numbers.
      RFC 768, Aug 80, User Datagram Protocol.
      RFC 792, Sep 81, Internet Control Message Protocol.
      RFC 821, Aug 82, Simple Mail Transfer Protocol.

      2.1.3.  Government Specifications.

System Specification for the Air Force Unified Local Area Network
Architecture (ULANA I), 17 Apr 87.
                                                                 EPS-88-001
                                                                08 Mar 1988

System Specification for the Standard Multiuser Small Computer
Requirements Contract (SMSCRC), 20 Feb 87.

      2.1.4.  Other Standards.

Institute of Electrical and Electronics Engineers Standard 802.3 (IEEE
802.3), 1985.

2.2.  Availability of Applicable Documents.  The specifications,
standards, and other documents cited herein that are not provided as a
part of the solicitation and are not readily obtainable may be examined at
HQ SSC/PKB, Bldg 1011, Gunter AFS AL  36114.

3.0.  REQUIREMENTS.

3.1.  General.  The LAN software shall allow users in various locations to
communicate with one another, share data and executable files, and share
peripherals via the ULANA network.  The security module shall prevent
unauthorized  access to workstations.  The government shall have the right
to make working backup copies of each software package purchased for its
use.  Copy protected software is not acceptable.  The backup copies must
execute in the same manner as the originally shipped disks.

3.2. Operational Concept.  The contractor(s)  shall provide software and
documentation as described in the following paragraphs for use at
worldwide government locations.  The software shall be orderable on both 3
1/2-inch and 5 1/4-inch media.

      3.2.1. Overall Operational  Criteria - LAN Software.  The contractor
provided LAN software shall fully support the following functionally
described minimum characteristics and requirements:

              3.2.1.1.  The required software shall operate and be
completely compatible with the Zenith Z-150, Zenith Z-200T, Zenith Z-248,
Sperry PC, and IBM PC XT/AT or compatibles running MS-DOS 3.1 and later
with ULANA host attachments.  The LAN software shall not interfere with,
degrade the performance of, or prevent the proper operation of the ULANA
host attachments.

              3.2.1.2.  The software shall provide the functions necessary
to support the following client-server architectures:

              3.2.1.2.1  Non-dedicated LAN server - the software shall
allow two or more PCs to function as servers in a non-dedicated mode.  The
software shall not use more than 256 KB of base memory.  The software
running in a client machine may use but  not require  extended memory
which is
available from Zenith Data Systems for the Zenith microcomputers.  The
available extended memory on the Zenith microcomputers is between 512 KB
and 2.5 MB.  The software shall be limited to the use of 256 KB of
extended memory for server and slave operation.  A PC shall have the
capability to act as a server and a client on the network at the same time.
                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.1.2.2. Dedicated LAN server - the software shall allow
two or more PCs to function as servers in a dedicated mode.  If the
dedicated server requires a different operating system (other than DOS 3.1
and later) it must be included with the LAN software.

             3.2.1.2.3.  Client workstation - The software shall not use
more than 128 KB of base memory when installed and configured as a client.
The software running in the client machine may use but does not require
extended memory  which is available from Zenith Data Systems for the
Zenith microcomputers.  The available extended memory on the Zenith
microcomputers is between 512 KB and 2.5 MB.  The software shall be
limited to the use of 256 KB of extended memory for server and slave
operation.  A PC shall have the capability to act as a server and a client
on the network at the same time.

             3.2.1.2.4.  SMB Server Interoperability - The software shall
interoperate with an SMB server that conforms with NETBIOS as per RFCs
1001 and 1002.

              3.2.1.3. Each micro-computer listed in 3.2.1.1 that must run
the local area network application software provided under this contract
will be provided with an installed ULANA host attachment.  A NETBIOS
service level interface that conforms to RFCs 1001-1002 will be provided
as part of this host attachment.  The LAN Application software shall
utilize this service level interface to communicate with other
micro-computers across the LAN.  While running the local area network
software it shall be possible to execute TELNET, FTP,  and other DOS-based
applications provided under the ULANA contract.

              3.2.1.4.  The software shall be icon-driven, menu driven and
command driven at the users option (2 out of the 3 options).

              3.2.1.5.  The software shall provide the capability of
switching between the network and the operating system.  It shall
accomplish this through use of options available in 3.2.1.4..

              3.2.1.6. For  all  machines  listed in 3.2.1.1., the
software shall support a minimum of 16 concurrent users per server.

              3.2.1.6.1  For all machines listed in 3.2.1.1., the software
shall support a minimum of 100 users per server.

              3.2.1.7.  The software shall support the following input
devices:

       Device                               Zenith Data Systems Part No
       ------                               ---------------------------
Z-150/200
Keyboard                                              181-6894
TEMPEST Kurta Tablet                                  AFP-11-T
                                                                 EPS-88-001
                                                                08 Mar 1988

Z-248
Keyboard                                              HE-163-24
Summagraphics Summasketch Input Device                SI-1201
Logitech Mouse                                        LG-7
Tempest Kurta Tablet                                  AFP-11-T

              3.2.1.8  The software shall allow the sharing of output
devices, to include as a minimum:

       Device                               Zenith Data Systems Part No
       ------                               ---------------------------
Z-150/200
Z-150 CGA Color Monitor                               ZVM-133-T
Z-150 Monochrome Monitor                              ZVM-122-T
Dataproducts DP55Q Letter Quality Printer             TT-5155
Dataproducts TCG200 Dot Matrix Color Printer          AFP-4-T
DMP-29T Plotter                                       DMP-29-TM

Z-248
Monochrome Monitor                                    ZMM-1470-G
EGA Color Monitor                                     ZVM-1380
ALPS P2000G Dot Matrix                                AL-2000
Diablo TC150 Ink Jet Printer                          AFP-8-T
Western Graphtec MP 2300 Plotter, 8 Pen Self Capping  WG-2300
CTS 2424 Dial Up Modem                                ZM-2424
Zenith Modem (Hayes 2400 baud)                        ZM-2401
Xerox 4020 Ink Jet Printer                            DS-200
Asynchronous 9600 Baud Voice/Data Modem               ZM-192
MPI Printmate 350 Dot Matrix Printer                  MPI-350-B1
Primage 90 Letter Quality Daisy Wheel Printer         PP-252
Genicom 3184 Dot Matrix Printer                       AFP-6-TG
Diablo 630 Daisy Wheel Printer
Okidata 83A Dot Matrix Printer
MPI Printmate 180 FT Dot Matrix Printer
Diablo Advantage 80 Daisy Wheel Printer
DMP-29 Plotter, 8 Pens
HP HGL Output Devices
Postscript Output Devices

              3.2.1.9  The software shall provide a backup capability for
shared network files utilizing the users choice of the following:

Irwin 20 MB Tape Backup System                  Z-427-20
Interdyne 20 MB Tape Backup System              ID-6025
Scorpion 60 MB Internal Tape Backup Drive       ZD-60

Shall back up 20 MB in less than 20 minutes and have unlimited capacity.

              3.2.1.10  The software shall allow the user to run the
following application programs when stored on the server from the standard
small computer requirements contracts and their NETBIOS compatible LAN
versions when they become available:
                                                                 EPS-88-001
                                                                08 Mar 1988

     Package                     Version                   Contract
     -------                     -------                   --------

Wordstar Professional         3.31 and later       Z-248 (F19630-86-D-0002)
Multimate                     3.3 and later        Z-248 (F19630-86-D-0002)
dBASE II                      2.43 and later       Z-248 (F19630-86-D-0002)
dBASE III                     1.1 and later        Z-248 (F19630-86-D-0002)
Condor III                    2.11 and later       Z-248 (F19639-86-D-0002)
Microstat                     4.0 and later        Z-248 (F19630-86-D-0002)
Supercalc 3                   2.1 and later        Z-248 (F19630-86-D-0002)
Graftalk                      3.27 and later       Z-248 (F19630-86-D-0002)
4-Point Composition Graphics  1.57 and later       Z-248 (F19630-84-D-0009)
Cad Key                       2.0 and later        Z-248 (F19630-86-D-0002)
Timeline                      2.0 and later        Z-248 (F19630-86-D-0002)
Enable                        1.15 and later       Z-248 (F19630-86-D-0002)
Microsoft Windows             1.01 and later       Z-248 (F19630-86-D-0002)

              3.2.1.11.  The software shall provide windowing and
multitasking capability.  It shall allow the capability to create a
minimum of eight windows allowing the concurrent viewing of eight tasks.
One application selected by the user will execute, and the others will be
suspended until selected.  The tasks may consist of eight different
applications or eight separate executions of a single application.

              3.2.1.12.  The software shall provide network administration
functions to allow for installation and maintenance of the network
software.  These functions shall include adding users, deleting users,
changing passwords, adding shared peripherals, and diagnostics and
statistics tools to identify network load and problems.  The information
provided by the diagnostics and statistics tools shall be more than raw
data--it shall help the user to interpret the data.  This shall not be a
separate software package.

              3.2.1.13.  The software shall allow a password for each user
identification with different levels of access (i.e.:  read only, read
write, etc).  Passwords shall be initially assigned by the network
administrator.  User shall have the ability to change their password.

              3.2.1.14.  The software shall provide full file sharing
capabilities that allow the user to:

              3.2.1.14.1.  Grant, remove, and change access to their files
on the LAN.

              3.2.1.14.2.  Grant file access to a single user, multiple
users, and all users on the LAN using options available in 3.2.1.4.

              3.2.1.14.3.  Specify type of access granted to other users
to include: none, read only, write only, execute, and read-write.

              3.2.1.14.4.  Grant access to a single file, a group of
files, an entire subdirectory, and an entire drive.
                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.1.14.5.  Place a password on files to which the user has
granted access to others so that the other user must use that password to
access the files.

              3.2.1.14.6.  Display a listing of all files to which the
user has granted access to other users and the type of access they have.

              3.2.1.14.7.  Display a listing of all the files to which
others have granted the user access and the type of access they have.

              3.2.1.15.  While running the LAN software, the user shall be
able to invoke all DOS application programs.

              3.2.1.16.  The software shall provide options available in
3.2.1.4 for the installation procedure.

              3.2.1.17.  The software shall allow workstations to link to
any shared peripheral on the network.

              3.2.1.18.  The software shall provide print spooling with
the capability to reorder print queues, delete print files and queues, and
move print files and queues to other printers.

              3.2.1.19.  The software shall provide context sensitive help
facility accessible from all workstations.

              3.2.1.20.  The software shall provide error messages that
correctly identify the error and explain how to correct it.

              3.2.1.21.  The software shall provide remote dial-in
capability that allows access to all network resources and capabilities.
It shall support user selectable data transmission speeds ranging from 300
BPS to 19.2K BPS (300, 1200, 2400, 9600, 19,200).

              3.2.1.22.  As a late deliverable, the contractor shall
provide a version of the software that will run with the SMSCRC operating
system that is functionally conformable with the System V Interface
Definition (SVID).  This version shall provide a user interface as similar
to that of the PC version as possible.

               3.2.1.23.  Additional consideration shall be given to those
contractors who offer a version of the software to be installed and
configured on the Zenith Z-100 computer to enable it to operate as a
client node on a network.  This version of the software must operate the
same as and provide a user interface identical to that of the software for
the machines cited in 3.2.1.1.

              3.2.1.24.  The software shall provide electronic mail
facilities.  It shall support a minimum of 100 mailboxes, which shall be
established by the network administrator.  It shall support both text and
non-text (8-bit ASCII).  The maximum size of electronic mail messages
shall be limited only by the amount of storage space the user has
available.




                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.1.24.1.  The capabilities shall include:

                  3.2.1.24.1.1.  Choose and read a message.

                  3.2.1.24.1.2.  Create a message with an editor supplied
by the vendor.

                  3.2.1.24.1.3.  Send a message.  Retain a copy of the
message if desired.

                  3.2.1.24.1.4.  Reply to a message.

                  3.2.1.24.1.5.  Forward a message and/or series of
messages.

                  3.2.1.24.1.6.  Delete a message and/or series of
messages.

                  3.2.1.24.1.7.  Send a courtesy copy (cc) of a message to
addresses upon transmission.  Shall allow for the creation, storage, and
use of distribution lists.

                  3.2.1.24.1.8.  Copy a message and/or series of messages
into a file.

                  3.2.1.24.1.9.  Insert files into the body of a message
and include as attachments to a message. (minimum of 10 files)

                  3.2.1.24.1.10.  Display headers including:  Date,
Subject, Return address, Read and unread, Answered and Unanswered, Flagged
and Unflagged.

                  3.2.1.24.1.11.  The user should be able to send and
receive electronic mail using this electronic mail facility to and from
other hosts on the network that only utilize the SMTP protocol for
electronic mail exchange from a host supported by ULANA using SMTP
protocol.

                  3.2.1.24.1.12.  Shall provide positive confirmation of
addressee receipt of message.

                  3.2.1.24.1.13.  Notify user upon log-in that he has new
mail.

                  3.2.1.24.1.14.  Save mail to a file of user's choice.

              3.2.1.24.2.  The message shall include the following fields
in data area:

                  3.2.1.24.2.1.  Subject.
                                                                 EPS-88-001
                                                                08 Mar 1988

                  3.2.1.24.2.2.  Comments (on forwarded or resent
messages).

                  3.2.1.24.2.3.  Return path (explicit series of
forwarding hosts/gateways).

                  3.2.1.24.2.4.  Return address.

                  3.2.1.24.2.5.  Date.

              3.2.1.25.  The software shall have a network calendaring
capability with the following functions:

              3.2.1.25.1.  It shall allow creation and use of a minimum of
100  calendars per server.

              3.2.1.25.2.  It shall provide for public and private
calendars that shall cover a minimum of 12 previous months and 12
subsequent months to the current month.

              3.2.1.25.3.  It shall display a planning calendar by day,
week, or month at the users option.  As a minimum, the daily calendar
shall allow 80 characters per entry; the weekly calendar 40 characters per
entry; and the monthly calendar 20 characters per entry.

              3.2.1.25.4.  It shall allow the user to print a hard copy of
daily, weekly, and monthly calendars.

              3.2.1.25.5.  It shall allow the user the capability to
designate other users who will have access to view and modify his calendar.

              3.2.1.25.6.  It shall allow the user to input information to
his own calendar and to calendars to which he has access.

              3.2.1.25.7.  It shall have appointment scheduling
capabilities such that a user may specify individuals whose calendars
should be checked for open time (during a specified day or week).  When a
common time is found, it shall reserve the time slot on each attendees
calendar.  It shall also check the availability of meeting rooms and
equipment for the meeting and schedule them as well.  In case of multiple
openings, the utility shall query the user scheduling the appointment as
to the desired time.

              3.2.1.25.8.  It shall allow the user to delete a scheduled
event from multiple calendars with a single action.

              3.2.1.25.9  It shall provide a calendar "scratch pad"
function which allows any user to propose calendar updates to any other
users' "scratch pad", plus a calendar update utility which allows each
user to review his scratch entries off-net and accept or reject proposed
updates to their actual calendar file.
                                                                 EPS-88-001
                                                                08 Mar 1988

              3.2.2.  Operational Concept - Security Module.  The
contractor-provided security module shall, through the use of a  software
and hardware combination and without affecting the normal operation of the
PC, fully support the following functionally described minimum
characteristics and requirements:

         3.2.2.1.  Shall be completely compatible with the Zenith Z-248
model computers manufactured by Zenith Data Systems running MS-DOS 3.1 or
later.

         3.2.2.2.  Shall have a password for each user identification with
different types  of access (disk, directory, and files).  This password
shall be user modifiable.

         3.2.2.3.  Shall keep an audit trail of user accesses both
successful and unsuccessful.  After a given number of unsuccessful log-on
attempts (as determined by the network administrator), shall record the
access attempts and the time in the audit trail and shall lock out the
unauthorized user by disabling the keyboard or CPU.

         3.2.2.4.  When a successful access is completed, shall provide an
audit trail report showing all access attempts made and what functions
were done during each access.  This report shall cover the previous 24,
48, or 72 hours at the users option.  At the end of the user specified
period, the audit trail data will be deleted. (For example, if the user
specifies a 24 hour audit trail, at the end of the 24th hour, the data for
hour 1 is deleted to make room for the data for hour 25.)

         3.2.2.5.  Shall prevent unauthorized users from booting system
(including booting from the floppy drive).

         3.2.2.6.  Additional consideration shall be given to those
contractors who offer a security module package to be installed and
configured on the Zenith Z-100 computer.  This version of the security
module must operate the same as and provide a user interface identical to
that of the software for the Z-248.

Note:  If meeting these requirements requires the use of an internal
board, that board shall fit into an available PC slot in the Z-248 and an
available slot in the Z-100 (if offered).  Different boards will be
permitted for each model of computer.  This board, if offered, shall not
interfere with the normal operation of the system in which it is installed.

3.3.  Documentation.

              3.3.1.  Contractor(s) shall provide comprehensive
documentation to accompany each software package.  Proposals should be
made for documentation as a separately orderable item and as bundled with
the software.  When bundled with the software, the price of the
documentation will be included in the price of the software.  This
documentation shall contain
                                                                 EPS-88-001
                                                                08 Mar 1988

explanations of each capability and how to perform it, an error message
key to provide further explanations of error messages described in
3.2.1.19., and a glossary of applicable terms.  It shall be aimed at the
novice user so that even a beginner can use the software with minimal
assistance.

              3.3.2.  The contractor(s) shall furnish the government any
changes to documentation within 60 days after notification of errors in
the original documentation or of discrepancies in the software that render
the documentation incorrect.

              3.3.3.  The contractor(s) shall furnish an installation
manual with each file server package.  This volume shall describe, in
detail, the software installation process and procedures, and how to set
up the network.

3.4.  Delivery of Orders.

      3.4.1.  The first delivery of each CLIN/SLIN shall be delivered to
Gunter AFS Alabama 6 work days after receipt by contractor of a delivery
order.  Subsequent deliveries shall be made to the "ship to" address
indicated on each delivery order.

      3.4.2.  The contractor(s) shall ship orders within 21 days of
arrival of the delivery order at the contractor's location.

3.5.  Warranties.

      3.5.1.  All software and hardware components purchased through this
contract shall be warranted against all defects and failures for a period
of 1 year.  All defective items that fail during the warranty period will
be returned to the contractor via a common carrier at government expense.
Replacements of defective items shall be made free of charge within 4
working days of contractor's receipt of the returned defective item.
Contractor shall pay the cost of shipping the replacement items.

     3.5.2.  For CONUS deliveries, the warranty period for a given
delivery order shall not begin until delivery of the items to the
specified destination or 15 days after government acceptance of the
delivery, whichever occurs first.

    3.5.3.  For OCONUS deliveries, the warranty period for a given
delivery order shall not begin until delivery of the order to the
specified location or 30 days after government acceptance of the delivery,
whichever occurs first.

3.6.  Updates and Upgrades.

    3.6.1.  Updates.

             3.6.1.1.  An update shall be defined as:  Corrections and/or
additions to existing versions of a product that cause the product to
operate as specified in this solicitation.
                                                                 EPS-88-001
                                                                08 Mar 1988

             3.6.1.2.  Free updates and corrected documentation shall be
made available to Air Force users not more than 60 days after the
contractor(s) receives official notification by the government of a
problem, or within 30 days after commercial availability of the update.
When an update is necessary, users will send the contractor a letter
stating the serial numbers from their originally purchased packages and
the address to which the update should be mailed.  The contractor shall
send updates on diskette and corrections to documentation in hardcopy
form.  These items must be mailed to the user within 7 work days after
contractor received the letter from the user.

    3.6.2.  Upgrades.

             3.6.2.1.  An upgrade shall be defined as: A new version of
the product with corrections and enhancements not available in previous
versions.

             3.6.2.2.  If, after the contract is awarded, the
contractor(s) markets a new commercial version of the product, the added
features and enhancements of the new commercial version and updated
documentation shall be proposed to the government in the form of an
upgrade to the government version of the package.  This proposal shall be
made within 30 days of the availability of the new commercial version.
The government may elect to modify the contract and, at its option, may
have the new version delivered in lieu of the originally specified
package.  Upgrades shall be listed as a separate contract line item.

              3.6.2.3.  Method of distribution is negotiable prior to
contract award.  Suggested method is to notify government users of the
update and have them send their original diskettes to the contractor who
in turn will return the upgraded version to the user.  The user shall
receive the upgraded versions within 7 working days of contractor receipt
of the original diskettes.

              3.6.2.4.  The price of the upgrade will be proportional to
the price of the originally offered package.  For instance, if the
original package was offered to the Air Force at 50 percent of its
commercial price, then the upgrade must also be offered to the Air Force
at 50 percent of its commercial price.

3.7.  Support.

    3.7.1.  The contractor(s) shall furnish a point of contact for
questions/problems.  This individual or individuals must be identified by
name, address, and toll-free telephone number.  The toll-free number shall
be manned between 0800 and 1700 Central Time, Monday through Friday
(except Federal Holidays) for the life of the contract.

    3.7.2.  The contractor(s) shall be required to maintain a data base
providing the following information on one screen:

             3.7.2.1.  order acceptance date (date order received by
contractor)

             3.7.2.2.  ship date (expected and actual)


                                                                 EPS-88-001
                                                                08 Mar 1988

             3.7.2.3.  ship-to address

             3.7.2.4.  list of items on order

Note:  The government shall have access to this data base at any time
through the use of the contractor-supplied toll-free phone line described
in 3.7.1. above and a standard asynchronous telecommunications package
(such as HyperAccess or Enable).  The data base shall be accessible by
delivery order number or by ship-to address at the users option.

3.8.  Monthly Reports.

    3.8.1.  The contractor(s) shall provide monthly production and
delivery reports on the fifth work day of each month.  These reports shall
contain the ordering status for the previous month (number ordered, number
delivered, number returned with defects) and the dollar amount associated
with these orders.  In addition, the ordering status and dollar figures
for the total period of the contract up to the end of the previous month
are also required (number ordered-to-date, number delivered-to-date,
number returned-to-date, explanation of backorders).

    3.8.2.  The contractor(s) shall also furnish the Small Computer Office
Automation/Service Organization (SCOASO) at Gunter AFS a monthly report
synopsizing the calls received over the toll-free line described in 3.7.1.
above.  This report shall specify the problem calls received and the
solutions given.

3.9.  Training.  The offered packages shall provide a computer aided
instruction module and interactive tutorial to provide an overview of the
products and aid the user in learning the capabilities of the products.

3.10.  Preparation for Delivery.

    3.10.1.  Packaging.

            3.10.1.1.  The contractor(s) is responsible for the
preservation, packaging, and packing of all items to be delivered under
the terms of this contract in such a manner that adequate protection is
provided against corrosion, deterioration, and physical damage during
shipment and handling from source of supply to final destination.  The
contractor's commercial packaging practice is acceptable in the event
these practices provide the required protection.  The contractor(s) is
fully liable for any damage, deterioration, and losses incurred during
shipment and handling unless the damage, deterioration, and losses are the
fault or negligence of the government.  Marking shall be in accordance
with MIL-STD-129J,  25 Sep 84, Marking for Shipment and Storage.

             3.10.1.2.  The government shall be responsible for the
preservation, packaging, and packing to the above standards of all items
returned to the contractor(s) for warranty service.





                                                                 EPS-88-001
                                                           08 Mar 1988

    3.10.2.  Delivery.  For deliveries to CONUS, Alaska and Hawaii
locations, deliverable items shall be F.O.B. destination.  For overseas
deliveries, deliverable items shall be F.O.B. point of exportation (POE).
Examples of initial delivery points for POE shipments are as follows:

    McChord AFB, WA (Japan and Korea)
    Travis AFB, CA (Philippines and Guam)
    Dover AFB, DE (Europe)
    Charleston AFB, SC (Panama)
    Patrick AFB, FL (Puerto Rico)


                    

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 16:52:00 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip
Subject:   Re: European interest in TCP

Summary: Listening to what you want to hear, eh ?
	 I think it's time to look a bit more at the ambitiousness
	 of the project and the FACT that they have come to fruition.


The comments shown below seem to be somewhat self-serving.
Might you gentlemen, consider that there are OSI-based
applications out there already, that the DoD is moving to 
a (connectionless) form of OSI protocols and that your 
talents (and mine) are being wasted by the endless exchanges
in what should now be called the "Propaganda Wars".

The simple facts are that a wide variety of companies have
implemmented OSI protocols and more are being added.
Now that the 1988 versions of the statndards documents are
out in final draft form for ballot, the growth of interest
has exploded.  

Please don't tell me how many more implementations of 
the DoD protocols are already out there.  That is well 
known and expected given the 10 year jump in their lifecycle.

Why not spend the energy in cooperating in the evolution of
these protocols to suite that will work for all of us?
Frankly I'm tired of the bickering from "educated"
individuals.



Thanks,
            J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office)     201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)



The rest of this article is an excerpt from a pair of comments
that are of the type referenced above.





References: <8803261505.AA04812@wb6rqn.UUCP> <2902@korppi.tut.fi>

In article <2902@korppi.tut.fi>, jh@tut.fi (Juha Hein{nen) writes:
> In article <8803261505.AA04812@wb6rqn.UUCP> brian@wb6rqn.UUCP (Brian Lloyd) writes:
> >European attendees.  The consensus was that OSI really wasn't happening
> >and that they were all planning to go the TCP/IP route.  I guess that
> >the ISO/OSI hard-sell has created a market that only TCP can currently
> >fill.
> 
> Pretty much a correct observation.  The POLITICAL plan is to go the
> connection oriented (X.25) OSI route that doesn't care about local
> area networks (it only cares about the profits of PTT monopolies). So
> if you want to build a LAN and connect it to another LAN what else
> have you got except TCP/IP?
> -- 
> 	Juha Heinanen
> 	Tampere Univ. of Technology
> 	Finland
> 	jh@tut.fi (Internet), tut!jh (UUCP)

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 17:06:05 GMT
From:      michel@CCT.BBN.COM (Tony Michel)
To:        comp.protocols.tcp-ip
Subject:   NCSA Telnet

Well, Thanks!  I got a lot of helpful offers about how to get RFCs!  More to
the point, enough people were surprised by the notion of Telnetting from
a Mac, that it's worth a few sentences.

My Mac SE is linked with many other Macs on my floor, and to some LaserPrinters
and to a gateway, by AppleTalk.  The gateway is built by Kinetics.  It is co
connected in turn to the BBN Ethernet segment in my building, which somehow
is gateway'ed into the INternet.  On my Mac i run a program created by
the National Center for Supercomputing Applications (NCSA), which implements
a terminal emulator, user Telnet, TCP and IP, and knows how to package the
IP datagrams up in AppleTalk to send them across to the Kinetics gateway.
My Mac is a real host on the Internet!  

This system works very well, and is shockingly cheap.

Having said something nice, now let me grumble.  The correct solution to
my previous query would be to have the NCSA software support  User FTP, and
I'm not sure why it does not.  Perhaps they have plans?  Anyway, for
something FREE, it's great.

While waiting for User FTP, I have to log into your system, however.
The problem is not confined to RFCs.  This approach means that I cannot
access any of the anonymous ftp services anywhere.  Naturally it is possible
to use a third party that has User FTP, but I really believe in this desk-top
computing stuff!  I don't want to log into my klunkey old UNIX system, if
I can avoid it.

Hmm, while I'm grumbling...it would be nice if the terminal emulator did
a better job of emulating the VT100.  How about installing tn3270 as well?
If only it could do tnUNISCOPE as well, I'd be in Seventh Heaven!

Anyway, Thanks, NCSA!  It's a great program just as it stands (V 1.12)

AXM

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 17:06:52 GMT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   SLIP working group?


Hm, perhaps I was wrong about modifying udpcksum enabling it for NFS.

As far as NFS over a serial line I tried it one evening over our 9.6Kb
Cypress line between BU and UCB. It really wasn't bad, NFS is not a
particularly high overhead protocol, the info being exchanged is
fairly similar to what gets exchanged in an FTP session (DIR,GET,PUT
etc.) Of course this disregards transmission problems which I didn't
seem to have that evening, the question was thruput.

It's probably an intuitive confusion that because NFS is so useful and
neat that it must therefore demand massive bandwidth (or perhaps
people are mixing the thought with ND, the diskless protocol?)

Doubtless you'd want your binaries local but as a very easy to use
"ftp" (eg. snooping around directories, copying stuff, file
management) it's really not bad on a relatively slow line in my
experience, perhaps a little slower than FTP but being able to use the
native OS interface to the remote file system can make it worthwhile.

Note that there are various timeout parameters etc that would need to
be tuned (can be set on a per mount basis) for smooth performance, but
the concept is not nearly as wild as seems to be presented here.

	-Barry Shein, Boston University

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 17:19:27 GMT
From:      n2dsy@hou2d.UUCP (G.BEATTIE)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

POINT 1

It has been suggested that the differences between SLIP
and AFT are limited to the "gratuitous" alteration of the
transparency and framing characters.  

This is hardly the case...the additional features of
AFT are three levels of charater transparency, seven-bit
transparency and prefix and suffix characters outside the 
frame to manipulate any intervening devices such as modems,
PADs, etc.  

POINT 2

It has been suggested that these extra features are not
prohibited by SLIP.

We agree, they are not.  Unfortunately, these additional 
features have not been uniformly outlined in SLIP.  This
may cause the evolution of several systems using SLIP which
will each have different way of handing the variations of
transparency found in asynchronous environments.  AFT DOES
standardize these conditions and I suggest that maybe SLIP
should be altered to handle them too.

POINT 3

It has been suggested that this is a divisive issue wrought
by the ISO folks to further separate the DoD Internet
and OSI commmunities.

On this point I wholehartedly disagree.  In fact, the problem
is identical for both groups and should help unite them.
The OSI model is not an issue here, the aysnchronous interface
and transparency through that interface is.

POINT 4

It has been suggested that the number of errors encountered
on an Asynchronous Link is minimal, therefore some error
checking is not required on the link and that error recovery
can be accomplished on an end-to-end basis.  

If I was experiencing a low residual error rate, then I would
agree.  The fact is I am not.  Every dial-up link I have
outside of my local area, but within my LATA is noisy.
If your requirements are less, so be it, but I would like the
have the local loop tend to it's own housekeeping and not
send errored frames on through the network and force end-to-end
recovery.

POINT 5

Anyone want to work on the convergence of these protocols into
a common solution ?  Please let me know and we can get
started. 


Thanks,
            J. Gordon Beattie, Jr.
E-mail:    ihnp4!hou2d!n2dsy (Unix)  n2dsy@kd6th.a3100201.ampr
Telephone: 201-615-4168 (Office)     201-615-4669 (Office FAX)
Telephone: 201-387-8896 (Home)

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 17:42:09 GMT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?


	
	Modular programmers and people who program generically will realize this
	is a Rube Goldberg mentality and will barf.
	

Modular programers will someday give us the full OSI protocol suite
(whenever they finish it). They also don't care about backwards
compatibility.  (I'd also say that they probably program in PASCAL, but
that would be name calling.)

"Real" programmers have to solve today's problems today. They
try to avoid screwing up existing systems when it is possible.
They try to avoid violating layers, but if there is no other way to
make it work, they do so.

--rick
(Formally trained as a modular "computer scientist", but corrupted into
a practical "engineer" by working in the real world.)

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 18:08:00 GMT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP working group?


    Date: Thu, 31 Mar 88 12:42:09 EST
    From: rick@seismo.CSS.GOV (Rick Adams)

    --rick
    (Formally trained as a modular "computer scientist", but corrupted into
    a practical "engineer" by working in the real world.)

I've also been "corrupted" into being a "practical" engineer too, by the
School of Hard Knocks.  What I've found are that quick and dirty
expedient bit-saving hacks (a) last much longer than you expect them to,
and (b) turn into massive, MASSIVE maintenance headaches, especially
when some other bright engineer decides an extension is needed.

If you still disagree, I guess it's a religious argument and we might as
well stop.

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 18:46:28 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   RFCs by E-Mail

Tony:

Please note that you can get RFCs by return electronic mail.  The following
information has been included in recent RFC announcements.

The NIC provides an automatic mail service for those sites which
cannot use FTP.  Address the request to SERVICE@SRI-NIC.ARPA and in
the subject field of the message indicate the RFC number, as in
"Subject: RFC nnnn".

--jon.

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 18:47:57 GMT
From:      pritch@tut.cis.ohio-state.edu (Norm Pritchett)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

In article <1016@thumper.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes:
>The framing technique you describe is EXACTLY the same as SLIP, with one
>important difference -- the specific values of the "escape" and "frame
>end" characters are different. Why? Is gratuitous incompatibility with
>de-facto standards a prerequisite for ISO approval?

For some time I've observed that phenomena and wondered the same
thing.  Then I attended A DECUS symposium session where DEC's
representative to ANSI and ISO touched upon the subject and confirmed
it is in fact true.  He said the purpose of these committees is to
produce a solution that makes technical sense AND places all parties
involved at equal DISadvantage, this concept making more sense in a
commercial environment.  As a possible scenario, suppose a major
vendor comes up with a neat solution to something.  They development
it and afterwords everyone (or if the vendor is big enough, they
themselves) think it is great and submit it to a standards committee.
Now, the standards committee thinks its great but some of the
representatives are concerned because if the committee just puts the
big rubber stamp on it then the submitting vendor is way ahead of the
game because he already has the product making use of the standard
developed or maybe even on the market.  That vendor is now has a
greater advantage over everyone else and some might consider it
unfair.  Making little "cosmetic" changes to the standard works
towards evening out the work involved for everybody to implement the
standard.  In place of vendors, the standards organizations of a
nation might be substituted in the case where a standard from one of
them is being submitted to an internation standards organization.

-- 
Norm Pritchett, The Ohio State University College of Engineering
ARPA: pritchett@eng.ohio-state.edu	BITNET: TS1703 at OHSTVMA
UUCP: cbosgd!tut.cis.ohio-state.edu!pritch

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Apr 88 01:19
From:      John Laws (on UK.MOD.RSRE) <LAWS%rsre.mod.uk@relay.MOD.UK>
To:        Sharan Kalwani <@nss:ulysses!gamma!mibte!mcf!shan@ucbvax.berkeley.edu>
Cc:        tcp-ip <@relay.MOD.UK:tcp-ip@sri-nic.arpa>
Subject:   Re: LAN Hardware/Software advice needed
Sharan,
 
Mid last year there was much critical comment of the Wollongong
TCP/IP etc implementation for VAX VMS. Since then there has been
significant people change (David Crocker and Marshall Rose in) and
release of V3.1 (I think there is a newre release but not aware that
it has made it to the UK yet).
 
I have been much impressed with the product, it is very comprehensive
and we are slowly learning how to use its extensive facilities. In the
last two weeks we have moved into using the EGP Gateway features and
are now supporting two other European sites, over X25, into the
Internet.
 
Future work is to explore the name server functions. I think I may have
heard that Van J's TCP flow control is in the new release.
 
John Laws
Distributed Information Systems Division
RSRE Malvern
-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 1988 02:22-EST
From:      CERF@A.ISI.EDU
To:        ves@MITRE-BEDFORD.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, sra@MITRE-BEDFORD.ARPA
Subject:   Re: draft ulana sw & sec spec
Ves and Stan,

Two thoughts after a first pass scan of the performance specs:

1. Will the windows lawsuits between Apple and HP/Microsoft create
problems for vendors trying to respond to the ULANA specs?

2. Should the electronic mail requirements include anything about
interoperability with Internet Mail (perhaps it does so by inclusion of
reference to SMTP ?), with any public mail service?, with name server
capabilities?

Vint
-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 22:13:38 GMT
From:      egisin@watmath.waterloo.edu (Eric Gisin)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: SLIP working group?

In article <1016@thumper.bellcore.com>, karn@thumper.bellcore.com (Phil R. Karn) writes:
[]
> the IP and TCP layers.  The error rate of a typical dialup link (if it
> works at all) is low enough that the extra software processing required
> to recompute a checksum over an entire packet at each hop is hard to
> justify. I keep a nailed-up 9600 bps V.32 modem link between work and
> home. In the 6 days since it was last rebooted, my machine at home has
> received 13,186 packets over the serial link. Of these, however, only 6
> had IP header checksum errors and 8 contained TCP header checksum

The overhead of a asyncronous link level checksum or CRC is very small.
On an 8MHz 68000, Fletcher's checksum takes about 3 usec per byte,
and CRC-16 takes about 8 usec per byte. This amounts to less than 1% overhead
at 9600 baud, which is less than overhead of the asyncronous device driver
(much less in the case of dumb asyncronous devices).

Both of these are better than the 16 bit ones-complement checksum TCP/IP uses.
Your example error rate is 1/1000 (high relative to LAN technologies),
and I wouldn't trust only TCP/IP checksum to detect errors.

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 23:01:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: OSI does not mean X.25


Not to put too fine a point on it, how many different vendors have
implementations which are either known to interoperate or have been
through COS certification? I'm glad to know the specs are finished.
I will be even more happy to know that there are implementations for
many operating system and hardware bases which can work together and
which you can buy off the shelf. 

Vint

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Apr 88 07:34:43 -0500
From:      haverty@CCV.BBN.COM
To:        postel@VENERA.ISI.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, michel@CCT.BBN.COM, haverty@CCV.BBN.COM
Subject:   Re: RFCs by E-Mail
Hi Jon,

The electronic mail channel is nice, but note that Tony's Mac doesn't
have an electronic mail server either.  Even if it did, given the nature
of personal computers (not always powered up, may be doing other things, etc.)
I'm not sure it would help if it did.  Perhaps if there was a pervasive
use of the PC-Mail (is that the right name) service that would meet the needs.

Like Tony, I have a MAC on my desk, and happen to have a PC-clone as well,
on the Internet.  We also tend to occasionally carry a laptop on trips.  There
is more computing power and memory on my desk than there was in an entire
computation center building not too many years ago.  I do 99% of my work
on those machines, and the frequency with which I interact with the network
to check mail, etc., is on a consistent downward trend.  What we're reacting to
I think is the situation where it's still necessary to establish a virtual
terminal link to a machine on the net, and login, type/send small packets,
etc., like I'm doing now.

I've been using Lotus Express, Desktop Express, and Compuserve Navigator,
which are all Personal-machine-oriented programs to utilize the services
of public networks (Compuserve and MCIMail).   It's an entirely different
style of network usage, where the fact that the network is involved becomes
almost invisible.

Anybody have ideas (or software...) that would make such usage exist
on the Internet?

Jack
-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 88 23:15:47 GMT
From:      NJG@CornellA (Nick Gimbrone)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for IBM's MVS

Has anyone compared the alternatives for TCP/IP implementations for the
IBM MVS operating system (e.g. KNET, ACC, etc). A full function
alternative, preferably with nice gateway capability to&from SNA
networks would be ideal (dream on :-).

END OF DOCUMENT