The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Sep-87 11:00:16 EDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Help with broken TCP

What follows is a TCP scenario observed on our local ethernet.  The ftp
application (A) has just pushed out the last data block to (B) and is
closing the connection.  The first FIN from (A) is lost.  An ACK from (B)
for the last data block arrives. Then there begins a conversation of FIN(A)
then ACK(B) with longer and longer time intervals between each set of
FIN(A)/ACK(B) as if the ACK is being dropped and a retransmit timer is
backing off, firing and a FIN being sent.  Notice that the sequence number
set in the retransmitted FIN packets is one less than that set in the lost
FIN packet.  Are both peers broken or just the sender of the FINs?

This is a tcpdump.  I added an * to indicate the lost packet.  (In case
your curious, the packet is lost because of an inability to handle back
to back packets on the part of B)

15:31:36.86  A > B: S -1063845887:-1063845887(0) win 4096 <mss 1024>
15:31:36.86  B > A: S 253698321:253698321(0) ack -1063845886 win 384 <mss 1024>
15:31:36.86  A > B: . ack 1 win 4096
15:31:37.12  A > B: P 1:146(145) ack 1 win 4096
15:31:37.12  A >* B: F 146:146(0) ack 1 win 4096
15:31:37.38  B > A: . ack 146 win 384
15:31:39.12  A > B: F 145:145(0) ack 1 win 4096
15:31:39.14  B > A: . ack 146 win 384
15:31:41.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
15:31:41.14  B > A: . ack 146 win 384
15:31:45.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
15:31:45.14  B > A: . ack 146 win 384
15:31:53.12  A > B: F 145:145(0) ack 1 win 4096 urg 1
 
and so on...

Phil Wood  (cpw@lanl.gov)

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Sep-87 16:19:32 EDT
From:      ccruss@ucdavis.UUCP (Russ Hobby)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I find SLIP server for 4.2/3?

Here  at UC Davis this summer we have been working on a project to allow 
PCs  to make dialup  SLIP connections to  the campus IP  network. We are 
also  working on abbreviated serial line  IP (ASLIP) packeting that will 
make dialup IP networks more efficient. 

Here  is how  the system  works. The  user logs  on to  the host that is 
acting  as the gateway, a  4.3 bsd system. He  then types in the command 
"slip"  and he becomes  a host on  the network. He  can then use all the 
programs that come with the CMU/MIT PC/IP or Phil Karn's system. To make 
connecting  to the network  a little easier,  we have written  a program 
that  will do the complete  login automatically. The program  has a user 
configurable  script file that  specifies a sequence  of strings to send 
out  the serial line and responses to wait  for comming back. It has its 
own  simple language with branching depending on if the correct response 
came  back. The net result is that after the script has been set up, the 
user types in one command on the PC to connect to the network. 

Unlike  some PC/IPs, our system  assumes that each PC  (or actually each 
user)  has its own, permanent IP address.  Security is provided by logon 
security  on the gateway  host. The IP  address of the  PC is associated 
with  the usercode on the gateway host.  The network connection for that 
PC's  IP address  can only  be started  from a  user logged  in with the 
correct  usercode. The system also makes sure that the IP address is not 
already connected before making a new connection. 

The  way we have  set up IP  address for the  PCs is to  have a separate 
subnet  that contains all the PCs. This  way the gateway host needs only 
to  advertise that  it is  a route  to that  subnet and  all the PCs are 
covered.  In  essence  the  gateway  host  is  the  network for all SLIP 
connections on that subnet. 

The  abbreviated  packets  work  on  the  assumption that the connecting 
computer is an end-node and will not be  doing any routing. In this case 
many  of the  fields in  the IP  packet are  unnecessary. ASLIP uses the 
minimum header size based on this assumption. With ASLIP the header size 
is  either 8 or  4 bytes, much  smaller than the  standard 40 bytes. The 
host  that is acting as the ASLIP  gateway rebuilds the outgoing packets 
to  legal IP packets before sending them out the network and abbreviates 
the incoming packets from the network. 

The login capabilities are currently working. I frequently connect my
PC at home via dialup modems( one command "netcon") and use telnet,
ftp, whois and smtp. Code for ASLIP is now being written and hopefully
will be done by the end of September. At that point we will package up
everything necessary to make it work and it will be available to anyone
that is interested.

Also  there have  been some  terminal server  vendors interested in this 
project.  It should not be  much work to turn  a terminal server into an 
ASLIP  or SLIP server and that would make it cheaper than using a VAX as 
the  gateway. Plus there would not be  as much maintainance and downtime 
with a simple server box. 

This  Fall's project is to take the best  of CMU's PC/IP, Phil Karn's IP 
and  Stanford's PC/IP  and make  a PC  package that  has the  networking 
interface  and services(SMTP,FTP...)  running in  the background. Client 
software  will run in foreground but  will use the background interfaces 
for connection to the network. 

                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services       BITNET:    RDHOBBY@UCDAVIS 
     Davis Ca 95616           UUCP:      ...!ucbvax!ucdavis!rdhobby 
     (916) 752-0236           INTERNET:  rdhobby@ucdavis.ucdavis.edu

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Sep-87 16:28:54 EDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: Help with broken TCP

4.3BSD network bug (#9, tcp_output) had a fix for an undetected data
loss during connection closing.  This may well have fixed the data loss
due to lost data segments, but, apparently it will cause the symptom
I reported if the data segment with FIN is lost.  If the test:

	if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0)
	
succeeds the #9 code decremented tp->sndnxt by one.  Instead, I set
tp->snd_nxt = tp->snd_una, and the symptom went away.   I'm not saying
this is a fix, but it may point more to the problem.

Phil Wood  (cpw@lanl.gov)

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Sep-87 18:04:13 EDT
From:      andrew@mitisft.UUCP
To:        comp.protocols.tcp-ip
Subject:   Dialup SLIP (was Re: Where can I find SLIP server for 4.2/3?)

in article <8708311459.AA25432@oswego>, beadel@oswego.UUCP (Edward F. Beadel, Jr.) says:
> 	Does anybody know of a 4.3( or 4.2)bsd version that has been hacked
> to allow dialup use? We are having "campus political problems" getting a 

	We have had such a system running internally here at Convergent
Technologies for about a year.  In that time, it has run under both 4.2
and 4.3 based CTIX (Convergent's UNIX), and will soon be released with
our System V.3.1 Streams / 4.3 BSD (with RFS & NFS) product.

	If you cannot find a non-commercial source, I can put you in touch
with someone here and maybe we can get you one of the earlier mbuf-based
versions.  However its possible you'd have to buy it, either with hardware
from us (or one of our customers) or possibly from Lachman Associates.

	I intend to post some more detailed experiences/queries regarding
address selection and routing in this environment sometime in the near
future, when I have more time to work on this project...

Andrew Knutsen
(408) 435-3623

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Sep-87 18:33:38 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Help with broken TCP

Right you are!  I knew that we had such a problem at one time, but didn't
think it had made it out of Berkeley.  Your fix is fine; our current version
does:
	if (flags & TH_FIN && tp->t_flags & TF_SENTFIN &&
	    tp->snd_nxt == tp->snd_max)
		tp->snd_nxt--;

which should be equivalent.

		Mike

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 1-Sep-87 18:55:39 EDT
From:      ron@celerity.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: SUN 3.4 problems

In article <8708290110.AA13873@ucbvax.Berkeley.EDU> "Jerry Scott" <jerry@twg.arpa> writes:
>I think your problem has to do with ICMP Mask Requests from your Sun 3.4.
>In release 3.3 and 3.4, diskless suns starting asking the net for
>network masks.  This is all well and good, but when you have hosts
>on your net giving you the wrong answer...
				.
				.
				.
>
>Hope this helps, I think this was discussed earlier but your message
>shows the symptom from the sun's point of view.  I hope Sun support
>is taking note of this.
>
>Jerry Scott
>
>------


Not really Sun's problem. The M68000 family uses net order already.


R. L. (Ron) McDaniels

CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 87 19:45:13 GMT
From:      barnett@im4u.utexas.edu  (Lewis Barnett @ home on the range)
To:        tcp-ip@sri-nic.arpa
Subject:   Need 3Com 3C300 UE interface

I have a somewhat unusual and rather urgent request to make.
I need to find a 3Com 3C300 UE (Unibus Ethernet) interface.
This was, I believe, 3Com's first Ethernet interface, and has
the unusual feature of handling the collision backoff in 
software.  This made it something of a CPU hog, but it is
also uniquely suited for experimenting with data link level
protocols -- which is what I'm doing.  I work with a testbed
of four machines with these interfaces, but I have recently
discovered that one of our interfaces is a pre-release version
with slightly different firmware.  The difference causes the
older board to dominate the ether at high loads when it
resides on a network with the newer boards.  This skews
performance results.  Therefore, I need to replace this board
with one matching the hardware revision level of the other
three boards.  

The details:  the pre-release board is revision PCB 267-01 Rev. E 21.4;
I need a board of revision level PWA 268-01 Rev. A or later.
I understand that pre-release revision PCB 267-01 Rev. E 21.7
is identical to this revision, so I'd settle for that.

I would need to board for a maximum of six months.  I am willing
to trade the early revision board in the meantime.  It works fine
under normal network loads (anything under about 150% offered load)
and does significantly better than a "normal" board in higher
loads.

The firmware change:  Ethernet spec says that when attempting to
transmit, an interface checks carrier sense, and if it is clear,
waits 9.6 usec. then transmits, regardless of the state of 
carrier sense.  The earlier board checks carrier sense *again*
after waiting and before initiating transmission.  This means
that when it is stuck in an environment with boards that follow
spec., it avoids a lot of collisions that the other don't.

If you have any of these boards and would be willing to do a
temporary trade, or know of anyone who might, please contact
me by email or phone [(512) 471-9708] as quickly as possible.

Lewis Barnett,CS Dept, Taylor Hall 2.124, Univ. of Texas, Austin, TX 78712

-- barnett@im4u.UTEXAS.EDU, barnett@im4u.UUCP,
      {ihnp4,harvard,seismo,gatech,ctvax}!im4u!barnett
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 00:56:51 EDT
From:      enger@sccgate.scc.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   RE Need old 3Com unibus/ethernet adapter

If the firmware on the board is the only difference, why not pull the
prom from a "good" board, and burn a copy.  Perhaps 3Com would be
willing to help?  At least they should be able to tell you for sure
that firmware IS or IS NOT the only difference.  (and maybe they'll
be willing to mail you a couple of the old proms, or cut some new ones
for you, if you lend them one of the "good" boards.

This may be some what idealistic, but it should be good business for the
manufacturers to support their customers; perhaps especially researchers.
I hope 3Com (or a competitor perhaps) comes forward to help you out.
Sorry I can't,
Bob

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 10:09:14 EDT
From:      bdale@winfree.UUCP (Bdale Garbee)
To:        rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip
Subject:   New release of KA9Q Internet Package

Announcing an update to the KA9Q TCP/IP software package release of 870526.0, 
bringing the current release date up to 870829.0.  This update adds fixes bugs,
and adds some minor functionality.  A new release will occur in a couple of
weeks with support for 4bsd and sysV unix machines, this version still supports
only the PC and PC clone class of machines.

The changes:
	- Improved KISS bits for the TNC1 from Gerard, PA0GRI.

	- the ASCII text at the top of one of the TNC2 hex files is gone now.

	- Minor tweaks to BM from Gerard, PA0GRI, Phil KA9Q, and yours truly.
	  Biggest noticeable differences are that BM no longer looks at the
	  hosts.net file at all, but instead passes symbolic hostnames to
	  the smtp client in net... and we once again changed the text entry
	  code.  It's more like bsd Mail now.  Default is a silly text entry
	  routine, a "~e" gets you into your favorite editor, and a "~p"
	  shows what you've typed so far.

	- NET.EXE understanding of symbolic hostnames ala the hosts.net file
	  has been extended.  You now need to wrap numeric IP addresses in
	  square brackets, as in "[44.32.0.16]", as you can use symbolic names
	  anywhere you need to use an IP address (including in the autoexec.net
	  file!)

	- Since BM no longer deals with IP addresses, a "gateway" command has
	  been added to NET.EXE, so that it knows where to send mail that
	  fails the lookup in hosts.net.

	- Internal changes and a fix to the ftp server so that it now handles
	  NLST command properly, all from Phil, KA9Q.  Bugs that were in the
	  870526.5 interim release that was only distributed in a limited
	  fashion apparently disappeared with the latest tweaks...

	- documentation has (as usual) been updated somewhat.  

	- some other random tweaks I'm sure I've forgotten...

What to do once you have software, aka "getting an IP address":

	Users of this software package become part of the "global IP
	internet", and as such need to obtain unique IP address assignments
	for each host they plan to put on the air, or "on the wire".  Major
	metropolitan areas in the US, and countries with active TCP-using
	groups probably already have blocks of addresses in amateur radio
	44.X.X.X block assigned to them.  Ask around locally before you go
	any further.

	If there is no local address block in your area, and/or noone is
	coordinating address assignments for your local net, contact Wally
	Linstruth WA6JPR.  Wally is the global top-level address administrator
	for the ham radio 44.X.X.X subnet.  Wally may be reached by email at

		wally%net1.ucsd.edu@sdcsvax.ucsd.edu
	or	wally@net1.ucsd.edu
	or	...!sdcsvax!net1!wally

	or via the new forwarding mechanism I have set up for those sites who
	know how to reply via mail to this message, but can't reach Wally's
	machine directly:

		winfree!wally   -or-   wally@winfree.uucp
	or	wally%winfree.uucp@flash.bellcore.com

How to obtain the KA9Q Internet software:

-	Via uucp, the files are on winfree in tar archives as:
	    
	  /usr/spool/uucppublic/pub/ka9q_all.tar.Z	16 bit Compress 4.0
	  /usr/spool/uucppublic/pub/ka9q_all.t12.Z	12 bit Compress 4.0

	For Anonymous UUCP login, use phone number 303/593-0696, at 2400
	baud (it will do 1200 if you send a return to rotate it down),
	"standard Unix login sequence", username of "Uanon", password of
	"notFTP".  An example L.sys entry ala winfree's uucp would be:

		winfree Any ACU 2400 13035930696 ogin: Uanon word: notFTP

	I've never run an anonymous login for uucp before, so let me know
	if I got it wrong!

	A reasonable command to issue to pick up the 12-bit distribution 
	would be 

		uucp winfree!~/pub/ka9q_all.t12.Z /usr/spool/uucppublic


-	***** My BBS is currently down with a dead hard drive.  If anyone
	***** has a spare drive they would be willing to donate to the cause,
	***** *please* get in touch with me ASAP!  Cashflow around here is
	***** a joke... :-(   Normally,

	Via Opus, log in to my BBS and download from the appropriate files 
	area.  There are several .ARC files for the full distribution, one 
	for each of the directories.  SeaDog file requests are ok.

	I have configured my BBS to allow first time users ample resources to
	download the full distribtuion at 1200 baud.  The phone number is 
	303/593-0766.

	If you have any trouble downloading from the BBS, please let me know.
	Speeds that are supported include 300, 1200, and 2400.

-	Via US Snail, Andy Freeborn N0CCZ has agreed to make floppy copies.
	To get a copy from him, send $5 AND a completed return address mailing
	label (orders without a mailing label will be considered 
	contributions to the BBS hard drive fund, see above... :-) to:

		Andy Freeborn, N0CCZ
		5222 Borrego Drive
		Colorado Springs, CO  80918
		USA

	What you get for the $5:  5 floppies, including two of RFC's and IEN's
	that relate to the code, two that include the actual release, and one
	that is intended to be a sort of "plug and play" disk for getting on
	the air immediately...

	For those who just want the RFC/IEN disks, Andy will send you just
	those two disks for $2 and a mailing label.  If you want any particular
	RFC or IEN, contact Andy to find out what archive it is in (we have
	them all packed up, one ARC per 360k pc disk), and he will send you
	that RFC or IEN, along with many others, on a floppy for $1/disk.  You
	can't mix and match, you get the block of documents that are in a
	given archive.

	DO NOT SEND floppies, mailers, postage, etc... but DO send the mailing
	label!

	Andy is also reachable as 
		winfree!andy or andy%winfree.uucp@bellcore.com
	if you need more information (?).  Andy is within an on-air FTP of
	me, so we should be able to keep his bits up to date!

-	on the ARPAnet, or attached portions of the Internet, look on
		louie.udel.edu
	via anonymous FTP for the files in the directory
		pub/ka9q

-	Within a day or two of a new release, the code should also be available
	from the following additional secondary distribution points:

		from Doug KD4NC in Atlanta, GA
			uucp: winfree!kd4nc!dug
		from Bob Hoffman N3CVL in Pittsburgh, PA
			arpa: rbh@cadre.dsl.pittsburgh.edu
			uucp: pitt!hoffman
		from Wally Linstrugh WA6JPR in Santa Barbara, CA
			arpa: wally@net1.ucsd.edu
		from Brian Kantor at UCSD.  (via anonymous FTP?)
			arpa: tcp-group-request@sdcsvax.ucsd.edu
			uucp: sdcsvax!tcp-group-request

	Unreleased (read: under development) versions are often available
	on louie.udel.edu, generally alongside official releases...
	caveat emptor... 

If anyone has any trouble getting hold of a copy of the code, please let me
know!

How to contact me:

	Bdale Garbee, N3EUA
	1433 Territory Trail
	Colorado Springs, CO  80919
	303/590-2868w, 303/593-9828h

    *** go easy on the phone calls please, I'm not getting much sleep! ***

uucp: {bellcore,crash,hp-lsd,ncc,pitt,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@flash.bellcore.com
      bdale@net1.ucsd.edu
fido: Bdale Garbee at 128/19, 303/593-0766, 300/1200/2400 baud, 24hrs (*DOWN*)
packet: n3eua @ k0hoa
-- 
Bdale Garbee, N3EUA		phone: 303/593-9828 h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@bellcore.com
fido: sysop of 128/19		packet: n3eua @ k0hoa, Colorado Springs

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 11:39:47 EDT
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Are simultaneous TCP opens useful?

Eric,
	Whether "simultaneous" opens will always succeed or randomly
fail depends on how the underlying TCP service is implemented.  If
the user code needs to look like this:
	{
	    if (connect() == FAIL) {
		listen();
	    }
	}
	then there is a race condition in which both sides may hang
in listen().  Side A fails to connect, but before A issues listen, side
B tries to connect and fails.

	However, if the underlying TCP service allows this:
	{
	    connect_or_listen();
	}
	as a primitive, then the simultaneous case seems to me to be
guaranteed to win.  Note that I don't know of any underlying services
that allow the second form.

Greg Minshall

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 12:31:28 EDT
From:      asjoshi@phoenix.PRINCETON.EDU (Amit S. Joshi)
To:        comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc
Subject:   Wanted: TCP/IP for an IBM PC/AT

Hi,

As a part of a simulator being built here I have to connect up an Iris
(running UNIX) and  an IBM PC/AT running DOS 3.2. I thought of using a serial
link but it turns out to be too slow. The Iris does not have a parallel port
(and to get an optional one costs around $4k I'm told). The IBM PC/AT has got 
a 3-Com board and has the MIT TCP/IP package. The Iris also has a complete 
TCP/IP package. I want to use this to hook up the Iris and the AT. Now the 
Iris has Socket libraries which simplify opening ports from programs. I was 
looking for something similar at the AT end of the business.

I DON'T have the source to the MIT package but the binaries definitely do 
not come with a socket library (or its equivalent).

Anybody know of anything out there? Preferably Public Domain, if not at a 
reasonable cost. Also preference is for sources. There is a restriction :
I have only Lattice C v3 and Turbo C v1 compilers so binary libraries should 
be compatible with these compilers.

Thanks.



-- 
Amit Joshi         |  BITNET :  Q3696@PUCC.BITNET
                   |  USENET :  ...seismo!princeton!phoenix!asjoshi
"There's a pleasure in being mad ...which none but madmen know!" St.Dryden

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1987 1628-PDT (Wednesday)
From:      Glenn Trewitt <trewitt@miasma.Stanford.EDU>
To:        tcp-ip@sri-nic.arpa
Cc:        Glenn Trewitt <trewitt@miasma.Stanford.EDU>
Subject:   Research on large packet-switched network behavior
I am trying to find out about people who are doing or have done
research related to my own.  Read on if you think you might have some
pointers...

When not working in the various network management activities, I am
supposed to be writing a thesis describing the results of my studies of
the Stanford Ethernet's behavior and performance.  The particular areas
that I am interested in are:
	micro-level behavior of networks/links
		interarrival times
		packet size distribution
		traffic volume
		
	behavior of routers (gateways)
		packet delay
		congestion

	macro-level behavior of the whole internetwork
		traffic matrices

	conclusions from this data
		suitablility of the topology for the presented load
		saturation point for routers
		performance as load increases
		performance as size/complexity increases

Yes, I realize that this is a lot of stuff, and I don't expect to
actually cover it all, but it's a starting point.

What I am interested in finding out from the people on this list is to
see if there has been published research on these topics based upon
Internet experience.  I realize that many of these parameters (such as
saturation point:-) have been determined by actual experiment in the
Arpanet, but has anyone actually written about it.  [I suspect that
people may be too busy fending off the aligators to actually write
reports, but I can hope.]

Thanks in advance,
	Glenn Trewitt

If you can't reply to miasma.Stanford.EDU, try amadeus.Stanford.EDU or
shasta.Stanford.EDU.
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 87 10:56:21 GMT
From:      bpa!sjuvax!bbanerje@burdvax.prc.unisys.com  (B. Banerjee)
To:        tcp-ip@sri-nic.arpa
Subject:   Replies to "Rarp under 4.3 BSD"

Hi,

Some  time  ago,  I  posted   an  article  enquiring  as  to  the
availability of  RARP under  4.3 BSD  to this  newsgroup. Several
people were  kind enough to respond.  In the event that  you were
waiting with bated breath (unlikely!), here's what I learned.

a. 	4.3 BSD doesn't support RARP, in any way shape or form.
b. 	Sun Unix 3.x ( Lim x->4) does support RARP.  In order to
	turn this on, you have  to fiddle with  /etc/ethers, reconfigure
	the  kernel to include the NIT code , and start an rarpd from
	rc.local.
c. 	Rarp can be added to 4.3 BSD.

Now, as the prospect of writing  a rarp daemon doesn't excite me,
I'm going to  go with the path of least  resistance -- running it
on the Sun.

If,  on the  other hand,  you are  in a  similar dilemna  without
recourse to a Sun;  all is not lost. You can  write a rarp daemon
with the aid  of the 'enet' ethernet packet  filter software that
was part of the ``user contributed software '' that came with 4.3
BSD. This essentially  gives you access to  ethernet packets that
haven't been snarfed up by IP or ICMP in the kernel. You can then
handle the 'rarp' packets yourself.

I personally  believe that it makes  the most sense to  place the
rarp handling  stuff along with  the 'arp' handling stuff  in the
kernel (netinet/if_ether.c). Consider the following facts:

	i)  The  internet-address  to  ethernet-address  mappings
	already exist in the kernel.
	ii) Proxy arp is supported.

Now suppose that a RARP packet  is received. The code could check
it's tables to see if it  was a 'published' entry, performing the
rarp service if  it was. The table could be  updated via 'arp -s'
as with proxy arp.

If  you want  to write  a RARP  daemon, but  don't know  where to
start; I  recommend Doug Comer's excellent  book "Internetworking
with Xinu". He has some code in there that you could almost steal
verbatim.

I would like to thank the following people for taking the time to
respond  to  my  query;  and answering  questions  or  giving  me
pointers on where to look.

bzs@bu-cs.bu.edu (Barry Shein)
karels%okeeffe@berkeley.edu (Mike Karels)
raj@purdue.edu  (Raju Yavatkar)
sun!guy  (Guy  Harris)
milazzo@rice.edu   (Paul Milazzo)
emory!tony  (Tony Vincent)
matt@oddjob.uchicago.edu   (Matt Crawford)
narten@purdue.edu (Thomas Narten)
sdcsvax!brian (Brian Kantor)

If you sent me mail and I haven't mentioned your name -- my apologies.
The first few letters were read, replied to and then deleted
before I realized that I would receive so many replies.  Thanks again
to anyone who helped with this one.

Regards,

		Binayak Banerjee
	{allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje
		bbanerje%sjuvax.sju.edu@relay.cs.net
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 17:06:05 EDT
From:      grandi@NOAO.ARIZONA.EDU (Steve Grandi)
To:        comp.protocols.tcp-ip
Subject:   A routing mystery

I have a mystery I don't understand; perhaps someone out there with more
knowledge can enlighten me.

My building Ethernet is network 192.31.165 (noao-tucson).  One VAX 11/750, 
noao.arizona.edu, running 4.3BSD serves as gateway between my net and the 
University of Arizona net (univ-ariz, 128.196).  A gateway machine on
univ-ariz, jvax.ccit.arizona.edu is linked to the Princeton Supercomputer
center (jvnc-net, 128.121.0) where a gateway machine, fuzz.csc.org,
connects to the NSFnet.  Hosts on noao-tucson have default routes to
noao.arizona.edu which has a default route to jvax.ccit.arizona.edu which
has a default route to fuzz.csc.org.

noao.arizona.edu serves as a central TCP/IP mail machine for our facility;
thus I spend a lot of time watching mail queues.  What I see is an almost
total inability to communicate to wiscvm.wisc.edu, the Bitnet mail gateway
(at least for a couple more months).  Since the other astronomers here beat
on me to get the Bitnet mail flowing, I've been poking around and have
discovered the mystery.

From noao.arizona.edu (128.196.4.1 and 192.31.165.2), pings and telnet
attempts to wiscvm.wisc.edu fail.  Yet, simultaneously, pings and telnet 
connections from aquila.noao.arizona.edu (192.31.165.6) to wiscvm work
fine, even though the packets from aquila have to go through
noao.arizona.edu to reach wiscvm!  Similar attempts from
jvax.ccit.arizona.edu to contact wiscvm also fail.

The only explanation I can come up with is that there is bad routing
information somewhere in the Internet for net 128.196, but good routing
information for net 192.31.165.  How can I investigate this possibility?
Or am I missing something obvious?

Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228
UUCP: {arizona,decvax,hao,ihnp4}!noao!grandi  or  uunet!noao.arizona.edu!grandi 
Internet: grandi@noao.arizona.edu    SPAN/HEPNET: 5356::GRANDI or DRACO::GRANDI

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 17:10:44 EDT
From:      kzm@ACC-SB-UNIX.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Are simultaneous TCP opens useful?

As Art Berggreen said in an earlier message, ACC has a product called
SIMON which provides a TCP-based service for peer subscribers (as
opposed to the more common Client/Server model).  

Several years ago when we were implementing this, we needed a scheme 
which avoided the race condition which Greg Minshall pointed out.  So, 
we asked Jon Postel about the validity of using the primitive which 
Greg calls "connect_or_listen", which we call a "symmetric" (as opposed 
to passive or active) open.  Jon said if we wanted to enhance our ULP 
interface like this, then fine.  This single primitive requests an
active open with an "automatic" fallback to passive if the active fails.
When both subscribers use this primitive, the ability to fallback
immediately eliminates the race condition.

Keith.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 19:28:00 EDT
From:      trewitt@MIASMA.STANFORD.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Research on large packet-switched network behavior

I am trying to find out about people who are doing or have done
research related to my own.  Read on if you think you might have some
pointers...

When not working in the various network management activities, I am
supposed to be writing a thesis describing the results of my studies of
the Stanford Ethernet's behavior and performance.  The particular areas
that I am interested in are:
	micro-level behavior of networks/links
		interarrival times
		packet size distribution
		traffic volume
		
	behavior of routers (gateways)
		packet delay
		congestion

	macro-level behavior of the whole internetwork
		traffic matrices

	conclusions from this data
		suitablility of the topology for the presented load
		saturation point for routers
		performance as load increases
		performance as size/complexity increases

Yes, I realize that this is a lot of stuff, and I don't expect to
actually cover it all, but it's a starting point.

What I am interested in finding out from the people on this list is to
see if there has been published research on these topics based upon
Internet experience.  I realize that many of these parameters (such as
saturation point:-) have been determined by actual experiment in the
Arpanet, but has anyone actually written about it.  [I suspect that
people may be too busy fending off the aligators to actually write
reports, but I can hope.]

Thanks in advance,
	Glenn Trewitt

If you can't reply to miasma.Stanford.EDU, try amadeus.Stanford.EDU or
shasta.Stanford.EDU.

-------

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Wed, 2-Sep-87 22:01:19 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  IP assigned protocol numbers

Kurt,

GGP is used only by the LSI-11 core gateways, who would be sore vexed,
indeed, if some host tried to horn in that protocol. Don't worry about
the number (it really is 3), just destroy all references to it, wherever
found.

Dave

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 87 01:00:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "grandi" <grandi@[128.196.4.1]>
Cc:        tcp-ip@sri-nic.arpa,enger
Subject:   RE A routing mystery -- some small input
Being curious, I did some pinging from my direct net-10 host, SCCGATE.SCC.COM
(10.11.0.20).  It has its DEFAULT route set to PURDUE-CS-GW.ARPA.

I ping successfully off of FUZZ.CSC.ORG (128.121.50.20)
JVAX.CCIT.ARIZONA.EDU (128.121.50.100)
JVAX.CCIT.ARIZONA.EDU (128.196.1.1)
NOAO.ARIZONA.EDU (128.196.4.1)

I could not raise a response from NOAO.ARIZONA.EDU (192.31.165.2) for quite
some time.  I made a number of attempts over a 10-15 minute period.
I found this curious, as this is simply the address on the 192.31.165 network
for the machine I had just heard from using the 128.196 network.
Further, I had initially been unable to raise any hosts on 192.31.165, and
after I started to hear from the 192.31.165 side of NOAO.ARIZONA.EDU, I 
also found that I could reach those back hosts, but the ping echo times
were much longer than those obtained from the 128 addressed gateways/hosts.

I checked my routing table.  Here is what I found.

destination net  	gateway

128.121.0		psc.psc.edu

128.196.0		psc.psc.edu

192.31.165		DCEC-MILNET-GW.ARPA

It appears that I'm routing through a MILNET gateway to reach
net 192.31.165.

Hope this info can be of some help to you,
Bob
------
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Sep-87 02:00:00 EDT
From:      enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To:        comp.protocols.tcp-ip
Subject:   RE A routing mystery -- some small input

Being curious, I did some pinging from my direct net-10 host, SCCGATE.SCC.COM
(10.11.0.20).  It has its DEFAULT route set to PURDUE-CS-GW.ARPA.

I ping successfully off of FUZZ.CSC.ORG (128.121.50.20)
JVAX.CCIT.ARIZONA.EDU (128.121.50.100)
JVAX.CCIT.ARIZONA.EDU (128.196.1.1)
NOAO.ARIZONA.EDU (128.196.4.1)

I could not raise a response from NOAO.ARIZONA.EDU (192.31.165.2) for quite
some time.  I made a number of attempts over a 10-15 minute period.
I found this curious, as this is simply the address on the 192.31.165 network
for the machine I had just heard from using the 128.196 network.
Further, I had initially been unable to raise any hosts on 192.31.165, and
after I started to hear from the 192.31.165 side of NOAO.ARIZONA.EDU, I 
also found that I could reach those back hosts, but the ping echo times
were much longer than those obtained from the 128 addressed gateways/hosts.

I checked my routing table.  Here is what I found.

destination net  	gateway

128.121.0		psc.psc.edu

128.196.0		psc.psc.edu

192.31.165		DCEC-MILNET-GW.ARPA

It appears that I'm routing through a MILNET gateway to reach
net 192.31.165.

Hope this info can be of some help to you,
Bob
------

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 87 23:28:54 GMT
From:      gatech!mcdchg!usenet@hplabs.hp.com  (Yvonne Sun)
To:        tcp-ip@sri-nic.arpa
Subject:   "select" problem
Systems: 4.3 BSD UNIX, ULTRIX 1.2, Sun UNIX 4.2
Machines: VAX 750, VAX 8600, Sun 2

I have a problem in my program. In one of the routines, I use "select" on
several opened sockets inside a for loop.
One of the sockets(call it S) is a passive one, i.e. it
is there to accept connections from other sockets. If S is selected,
an "accept" will be executed, trying to accept the connection. Since
"select" is used, S should be selected only when there is a pending
connection request. My problem is that, after the program is executed
for a while, socket S is always selected and the accept call will
return unsuccessfully with the error code being 60( i.e. ETIMEOUT).
After that, S will be selected again and again and accept will fail
every time it is called. What troubles me is that S is selected even
I haven't tried to connect to it.
I am sure that I reset the input mask used in the select everytime
right before select is called.
Have you seen something like that before? Or do you have any idea
about what causes this phenomenon?
I would appreciate any opinion and suggestions.

Yvonne Sun
at UC Davis
address: sun@iris.ucdavis.edu
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Sep-87 13:18:21 EDT
From:      moore@UTKCS2.CS.UTK.EDU (Keith Moore)
To:        comp.protocols.tcp-ip
Subject:   request for mailer information

[Apologies if this isn't strictly within the scope of this group]

I'm looking for a better mailer!  I'm tired of using the mail programs
supplied with VMS and Berkeley Unix (Ultrix 1.2).  I'd like something that
can keep track of large numbers of old messages, with database-like
searching and query capabilities.  It would also be nice if it would
keep messages in order, remember which messages have been replied to, 
follow message chains, etc.  And I'm sure a sophisticated mailer would
have other useful features I haven't dreamed about.

So I'm soliciting information on alternative mail management programs
for both VMS and Unix systems.  I'm especially interested in anything
that's cheap or free, and easily available.

Please respond by mailing directly to me.  If someone wants the results,
send me mail and I'll send a summary.

Keith Moore			Internet: moore@utkcs2.cs.utk.edu
UT Computer Science Dept.	CSnet: moore@tennessee
Knoxville Tennessee		BITNET: moore@utkcs1

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Sep-87 17:03:48 EDT
From:      cam@columbia-pdn (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Multiple 331 password responses in FTP protocol

Folks,

ACC distributes an MVS implementation of the Internet protocol suite called
ACCES/MVS.

We are in the process of adding support to interface ACCES to various 
MVS security packages using the MVS-provided SAF (Security Authorization
Facility) interface. SAF allows an application subsystem to use a common
interface to the access control facility, be that RACF, ACF2, Top Secret or
Alert/MVS (and possibly others).

One problem has emerged that I want to present to this group for comments 
and/or suggestions.

Systems like RACF will expire a user's password after a certain period of
time; this is quite commonly used at the average MVS site. We coded the
changes in the FTP server to detect this (after USER and PASS FTP commands
have been issued) and if the password is expired to prompt the Client FTP
for a new (second) password. If the Client is 4.3 BSD, it assumes that the
second password prompt (331 response) is really a 332 response, prompts
the user for an account, and sends an ACCT FTP command in response to our
331 password prompt. It looks something like this:

	ACCES/MVS				UNIX

	220 service ready	--->			

				<---		USER chris

	331 ok; need password	--->

				<---		PASS chris_pswd (obtained
						with Client FTP password
						prompt)

	331 expired; need new
	password		--->

At this point, 4.3 BSD prompts the Unix FTP user for an account and if
one is entered in, sends it in an FTP ACCT command. Obviously the 4.3
FTP client is not vigorously checking the reply code; the "need acct"
reply code is 332 not 331.

By the way, if you send the USER, PASS, and 2nd PASS with the QUOTE 
command, everything works properly.

Now before you tell me to look at the state diagrams in the FTP spec (which
show a transition to the ACCT state after receipt of a 3xx response to the 
PASS command) let me point out that the spec section with state diagrams
states:

	"Here we present state diagrams for a VERY SIMPLE MINDED FTP
	implementation. Only the FIRST DIGIT of the reply codes is used"
	(Capitalization is mine)

This suggests to me that the spec does not say "implement your FTP using 
these simple-minded state diagrams" but "here are SAMPLE state diagrams
to help you understand the FTP protocol".

So --- a couple of questions for you folks to ponder (and hopefully to 
respond to):

1) Our position is that if the FTP server sends more than one 331 response
in a row, this is legitimate and Client FTP implementations should properly
handle this. Do you wise folks agree?

2) If you don't agree, what brilliant ideas can you give us on how to do this?
(Please don't say that we should accept the ACCT info following the 1st PASS
as the 2nd PASS!?!)

Please respond to me or to this group; I will summarize at the end.

Thanks in advance for your advice in this matter.


Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100


PS - Do not try to respond to me at acc-md-unix.arpa; use acc-sb-unix.arpa
which will forward to me at acc-md-unix

PS - I know this isn't very exciting stuff but it is a real problem that
will affect real users at real sites.

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Sep-87 17:17:18 EDT
From:      jmr@philabs.Philips.Com (Joanne Mannarino)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   There is a solution to my SUN 3.4 problem



Thanks for all your responses to my 3.4 problem.  We have finally found a
solution.

The 3.4 release introduced subnetting.  The way the networking software for
3.4 works is that the diskless client comes up and requests a subnet mask.
It waits for a response from the server.  The TCP/IP software (we're running
XLAN but problems have occured with Wollongong also) responds with a subnet
mask that is invalid.  The diskless client is supposed to check it, determine
that it is invalid, disregard it, and wait for the server to respond with the
correct subnet mask.  BUT with the 3.4 release, the client wasn't ignoring
the invalid subnet mask so thus it would hang.  SUN has provided a patch to
the kernel software to take care of this.

If anyone else is still having this problem, you should call SUN support and
ask for the fix to bug id 1006127.  This solution was sent to me by Bill
Nowicki, Network Software Developer at SUN.  According to him, they have a
guard against this in the 3.5 release.

-Joanne Mannarino



-- 
joanne mannarino				    uunet!philabs!jmr   
philips laboratories 				           or
(914)945-6008					 jmr@philabs.philips.com

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Sep-87 17:21:19 EDT
From:      jmr@philabs.Philips.Com (Joanne Mannarino)
To:        comp.protocols.tcp-ip
Subject:   There is a solution to my SUN 3.4 problem



Thanks for all your responses to my 3.4 problem.  We have finally found a
solution.

The 3.4 release introduced subnetting.  The way the networking software for
3.4 works is that the diskless client comes up and requests a subnet mask.
It waits for a response from the server.  The TCP/IP software (we're running
XLAN but problems have occured with Wollongong also) responds with a subnet
mask that is invalid.  The diskless client is supposed to check it, determine
that it is invalid, disregard it, and wait for the server to respond with the
correct subnet mask.  BUT with the 3.4 release, the client wasn't ignoring
the invalid subnet mask so thus it would hang.  SUN has provided a patch to
the kernel software to take care of this.

If anyone else is still having this problem, you should call SUN support and
ask for the fix to bug id 1006127.  This solution was sent to me by Bill
Nowicki, Network Software Developer at SUN.  According to him, there will be a
guard against this in the 3.5 release.

-Joanne Mannarino


-- 
joanne mannarino				    uunet!philabs!jmr   
philips laboratories 				           or
(914)945-6008					 jmr@philabs.philips.com

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Thu, 3-Sep-87 17:50:25 EDT
From:      SATZ@MATHOM.CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: Replies to "Rarp under 4.3 BSD"

A rarp daemon exists for 4.3BSD using the enet packet filter. It was
developed and used extensively at Stanford. The enet device code should
just "drop in" to the distributed 4.3BSD system. The only major change
would be to the ethernet driver to insert the hooks to pass the packet
off to the enet code instead of just pitching it.

If you are interested in the daemon, drop me a note and I will give
you the name of people within Stanford who may be able to help. Note
that I cannot provide code since I am not affiliated with Stanford.
-------

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 1987 07:38:48 CDT
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Unisys 5000, Unix, and TCP/IP
   Just a request for any information out there.  Does anybody have any
experience with internetting Unisys 5000s?  These beasts run some flavor
of Unix.  The words filtering through the grapevine are that Unisys
wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few
problems with it.  Any comments are welcome.
Darrel Beach
-------
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 08:38:48 EDT
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Unisys 5000, Unix, and TCP/IP


   Just a request for any information out there.  Does anybody have any
experience with internetting Unisys 5000s?  These beasts run some flavor
of Unix.  The words filtering through the grapevine are that Unisys
wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few
problems with it.  Any comments are welcome.
Darrel Beach
-------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 09:54:00 EDT
From:      ejc@SPAM.ISTC.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   Re: request for mailer information

Keith-

We have been using MH and Gueuemacs as a mail handler on UNIX systems
(Vaxen and Suns).  The combination has most of the general features
you mentioned, although I think there are still holes, especailly when
dealing with large volumes of mail.  Since both programs originated
elsewhere, I am sure you will receive ample descriptions from others.

I am interested in the results of your survey, so please send me a summary.

Earl Craighill
SRI International

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 12:21:00 EDT
From:      NS-DDN@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple 311 password responses in FTP protocol



Chris, you err in not carefully reading section 5.4 of RFC959. The table
of replies to the PASS command (which must be "strictly adhered to") does
NOT include 331. I would suggest you avoid the trap of trying to support
the password change function through FTP and generate an appropriate 5xy
reply to the PASS command with text from the security package.
 
Best regards,
 
Dave Craig
Network Solutions, Inc.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 87 12:21 EDT
From:      NS-DDN @ DDN3.arpa
To:        cam @ acc-sb-unix.arpa
Cc:        tcp-ip @ sri-nic.arpa
Subject:   Re: Multiple 311 password responses in FTP protocol


Chris, you err in not carefully reading section 5.4 of RFC959. The table
of replies to the PASS command (which must be "strictly adhered to") does
NOT include 331. I would suggest you avoid the trap of trying to support
the password change function through FTP and generate an appropriate 5xy
reply to the PASS command with text from the security package.
 
Best regards,
 
Dave Craig
Network Solutions, Inc.


-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 12:34:21 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple 331 password responses in FTP protocol

UNIX uses the simple minded approach.  Only the first digit is
checked.  (This is for infomration).

I think ACCESS/MVS is doing the wrong thing.  The reply strings
are supposed to be informative only, the client is supposed to
be able to make it's decisions based on the numbers alone.  The
only defined acceptable replies in the spec are 3XX meaning
send account, 2XX Success, and 5XX error.  Doing anything else
is just asking for trouble.  The last two digits are there to
provide a finer differentiation of the error, but not to change
the flow of control.

Beyond that conceptual problem, if I understand what is going on here,
you're second password string actually changes the password?  This is
a horrendous security problem and really ought not to be done in FTP.
Better to just return an error (EXPIRED PASSWORD) and leave the user
to correct the situation through other channels.

-Ron

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 12:39:22 EDT
From:      mo@maximo.UUCP (Mike O'Dell)
To:        comp.protocols.tcp-ip
Subject:   Unisys 5000

I think that is the Arete box remarketed by
Unisys.  If so, they use an Excelan 201 board
for the TCP-IP support.  This code is
derived from the 4.1a TCP code, but has had
some bugs fixed and some features added.
As to which ones, however, ask Unisys,
Arete, and possibly Excelan.

	-Mike

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 1987 18:01-PDT
From:      STJOHNS@SRI-NIC.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Multiple 331 passwd responses in FTP protocol
No, no, no!!!

DO  NOT extend the meaning of the USER command or for that matter
that of the PASS command.   They  have  very  specific  meanings.
Instead,  create  your  own extension commands "XCPW" and "XGRP".
These can be specified via the "quote" command that  is  supposed
to  be part of all FTP implementations.  This is within the scope
of the standard.  Please, be sensible - standards are there for a
reason, interoperability.

Mike
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 87 12:51:32 GMT
From:      mtune!codas!ablnc!gil@RUTGERS.EDU  (Gil Widdowson)
To:        tcp-ip@sri-nic.arpa
Subject:   HELP: select() under sockets

I am trying to modify an application to use select(3w) to manage 
incoming data.  I am working on 3B2s, 3B20s, and UTS using sockets 
under Wollongong's/AT&T's TCP/IP over Ethernet. 3Bs are running
TCP release 1.1. Anyway, it does not seem to work at all. So I set 
up a little client/server model where the server uses select() to 
determine when the client has sent it data on an established virtual circuit.
When I use block mode, it pends forever, though if I break out using sbd(1), 
data is there.  If I use timed polling mode, it always returns
zero forever. Is it me or our sockets service??

code fragment
...
set up connection on file descriptor nfd

/*
***********************************************
** Select test code
** if timed_select FALSE
**   pend until our fd is ready for readying
** else
**   do polling once a second 
**	until our fd is ready for readying
***********************************************
*/
readfds = (1<<nfd); writefds = 0; eventfds = 0; numfds = 1;

if (timed_select == 0) {
	numfds = select(numfds, &readfds, &writefds, &eventfds, 0);
	if (numfds == -1) {
		perror("select() error");
		exit(1);
		}
	fprintf(stderr, "numfds = %d and readfds = %X\n",numfds, readfds);
	}
else {
	int sav_readfds; int sav_numfds;

	sav_readfds = readfds;
	sav_numfds = numfds;
	nodata = 1;
	while (nodata) {
		readfds = sav_readfds;
		numfds = sav_numfds;
		numfds=select(numfds, &readfds, &writefds, &eventfds, &timeout);
		if (numfds == -1) {
			perror("select() error");
			exit(1);
			}
		else {
			if (numfds == 0) { continue; }
			else { nodata = 0; }
			}
		}
	}
Do recv() of data.
...

Please send any/all humiliating/enlightening responses via email.
thanks,

Gil Widdowson  AT&T DP&CT Maitland FL
{allegra,amdahl,clyde,codas,cuae2,garage,houxm,ihnp4,mtune,research}!abfli!gil
(305) 660-6123  (8-754)
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 16:59:07 EDT
From:      cam@columbia-pdn (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple 331 passwd responses in FTP protocol

Folks,

A number of people have quickly pointed out to me that section 5.4 
"Sequencing of Commands and Replies" in RFC 959 specifically states the
responses that are valid after a PASS command, and guess what, 331 is 
not one of them.

So, if the password specified on the PASS command has expired we will do the
following:

1) send a "530 passwd expired; retry with passwd/newpasswd"

2) extend the syntax for the PASS text to allow specification of a new passwd

	PASS passwd[/newpasswd] [GROUP(xxx)]

   (GROUP is another piece of user id the user may want to specify in a usual
    MVS security environment)

3) while we're at it, extend the syntax of the USER command also

	USER userid[/passwd[/newpasswd]] [GROUP(xxx)]

This will screw up 4.x users who use .netrc files to allow auto-login
when 4.x client FTP connects to a remote host, in the case where the passwd
has expired, but that's life in the big (BLUE) city!

Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 20:14:22 EDT
From:      bdale@winfree.UUCP (Bdale Garbee)
To:        rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip
Subject:   winfree anonymous uucp fixed

To those who have unsuccessfully tried to uucp the KA9Q Internet Package
from uucp host winfree as per the information in the release posting...

I have fixed the problem that caused requests from unknown hosts to fail.
Two sites have gotten the bits this afternoon, so I think it's fixed.  If
you tried before and it bombed, try again now with the same login info!
-- 
Bdale Garbee, N3EUA		phone: 303/593-9828 h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@bellcore.com
fido: sysop of 128/19		packet: n3eua @ k0hoa, Colorado Springs

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 20:54:54 EDT
From:      ROODE@BIONET-20.ARPA (David Roode)
To:        comp.protocols.tcp-ip
Subject:   Re: request for mailer information

I think you are refering to a mail user agent rather than a mailer.
A mailer is usually the delivery agent and the interface to the
transports used.

I too would like to see a better mail program.   However,
perhaps you would find the MM program available for Unix and VMS
which is derived on the version for TOPS-20 to be superior
to what you are using.  I suggest contacting Kashtan@IU.AI.SRI.COM
for more information.  
-------

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Fri, 4-Sep-87 21:01:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple 331 passwd responses in FTP protocol

No, no, no!!!

DO  NOT extend the meaning of the USER command or for that matter
that of the PASS command.   They  have  very  specific  meanings.
Instead,  create  your  own extension commands "XCPW" and "XGRP".
These can be specified via the "quote" command that  is  supposed
to  be part of all FTP implementations.  This is within the scope
of the standard.  Please, be sensible - standards are there for a
reason, interoperability.

Mike

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5-Sep-87 00:27:52 EDT
From:      mkhaw@teknowledge-vaxc.ARPA (Mike Khaw)
To:        comp.protocols.tcp-ip
Subject:   Re: request for mailer information

> perhaps you would find the MM program available for Unix and VMS
> which is derived on the version for TOPS-20 to be superior
> to what you are using.  I suggest contacting Kashtan@IU.AI.SRI.COM
> for more information.  

TOPS20 MM is a fine program in its environment.  Unix MM doesn't feel
like Unix:  it feels like a little TOPS20 island plopped into the midst
of Unix.  You may consider that a plus.  I don't.

It uses its own format for mail files, different from what Unix mail
uses, so I haven't found a way to make it read Unix mail files.  (It reads
incoming mail into ~/mail.txt, making alterations to suit its format in
the process.)  MM also seems to think that "/" is a TOPS20 switch
metacharacter or some such, so it doesn't understand Unix pathnames.  The
built-in help uses TOPS20 terminology to the extent of referring to
documentation files in TOPS20 syntax (e.g., DOC:<FOO>BAR.DOC;1).

Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Sat, 5-Sep-87 15:36:46 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple 331 password responses in FTP protocol

From my reading of this topic I could not tel if the password was being changed
on a high frequency basis (like hourly) or on a low frequency basis
(like monthly).  If monthly, then returning an error is probably fine,
but if it is hourly (or less) then something has to change so the user
does not get completely frustrated.

What are the facts?

Dan
-------

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 1987 15:36:46 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
Cc:        tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re:  Multiple 331 password responses in FTP protocol
From my reading of this topic I could not tel if the password was being changed
on a high frequency basis (like hourly) or on a low frequency basis
(like monthly).  If monthly, then returning an error is probably fine,
but if it is hourly (or less) then something has to change so the user
does not get completely frustrated.

What are the facts?

Dan
-------
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6-Sep-87 00:02:46 EDT
From:      sun%iris@ucdavis.UUCP (Yvonne Sun)
To:        comp.protocols.tcp-ip
Subject:   problem on "select()"

Systems: 4.3 BSD UNIX, ULTRIX 1.2, Sun UNIX 4.2
Machines: VAX 750, VAX 8600, Sun 2

I have a problem in my program. In one of the routines, I use "select" on
several opened(including tcp and upd sockets) sockets and a pseudo-
terminal device inside a for loop.
One of the sockets(call it S) is a passive one, i.e. it
is there to accept connections from other tcp sockets. If S is selected,
an "accept" will be executed, trying to accept the connection. Since
"select" is used, S should be selected only when there is a pending
connection request. My problem is that, after the program is executed
for a while, socket S is always selected and the accept call will
return unsuccessfully with the error code being 60( i.e. ETIMEOUT).
After that, S will be selected again and again and accept will fail
every time it is called. What troubles me is that S is selected even
I haven't tried to connect to it.
I am sure that I reset the input mask used in the select everytime
right before select is called.
Have you seen something like that before? Or do you have any idea
about what causes this phenomenon?
I would appreciate any opinion and suggestions.

Yvonne Sun
at UC Davis
address: sun@iris.ucdavis.edu

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Sun, 6-Sep-87 12:18:54 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  HELP: select() under sockets

The definition of the first argument to the socket is the maximum file
descriptor that can be specified in any of the other fields.  You set
it to one (presumably because you are assuming the value was supposed to
be the number of things selecting on).  Setting this value to one means
that you can only select on file descriptor 0.  Set the value to something
larger like the maximum number of file descriptors (NFILE).

-ROn

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Sep-87 07:38:07 EDT
From:      murayama@CS.UCL.AC.UK (Yuko Murayama)
To:        comp.protocols.tcp-ip
Subject:   ISO8473 vs. IP

Could anyone let me know about the difference between ISO 8473
(protocol for providing the connectionless-mode network service)
and the DARPA IP?

Yuko Murayama
a Ph.D. student
Dept of Computer Science
University College London

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Sep-87 08:54:00 EDT
From:      NS-DDN@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: ACC's FTP Protocol Modification Proposal


Mike, by "quote", don't you mean a command at the topmost UI layer, not the
PI layer which the RFC lays down the law for? The RFC provides the "SITE"
command for local vagarities. Since I see nothing in the RFC which would
preclude the SITE command before the USER command, I should think that would
be the way for ACC to go with this interoperable difficulty. However, I am
in total agreement with your strong statement on the bending of command
syntax.
 
Chris, I would think again about supporting this type of service. Although
the FTP protocol is intentionally designed for interactive use by the owner
of the password, the world is obviously moving toward unattended file
transfer (and other traditionally interactive tasks). The better approach is
to insist that the security system merely request the user to change his
password and continue to accept the existing password until the human being
explicitly changes it. Note that if several batch FTPs are queued and the
first one changes the password, the remaining FTPs will fail...

Best regards,

Dave Craig
Network Solutions, Inc.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 87 08:54 EDT
From:      NS-DDN @ DDN3.arpa
To:        STJOHNS @ SRI-NIC.ARPA, cam @ ACC-SB-UNIX.ARPA
Cc:        tcp-ip @ SRI-NIC.ARPA
Subject:   Re: ACC's FTP Protocol Modification Proposal

Mike, by "quote", don't you mean a command at the topmost UI layer, not the
PI layer which the RFC lays down the law for? The RFC provides the "SITE"
command for local vagarities. Since I see nothing in the RFC which would
preclude the SITE command before the USER command, I should think that would
be the way for ACC to go with this interoperable difficulty. However, I am
in total agreement with your strong statement on the bending of command
syntax.
 
Chris, I would think again about supporting this type of service. Although
the FTP protocol is intentionally designed for interactive use by the owner
of the password, the world is obviously moving toward unattended file
transfer (and other traditionally interactive tasks). The better approach is
to insist that the security system merely request the user to change his
password and continue to accept the existing password until the human being
explicitly changes it. Note that if several batch FTPs are queued and the
first one changes the password, the remaining FTPs will fail...

Best regards,

Dave Craig
Network Solutions, Inc.

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Sep-87 14:44:56 EDT
From:      ks@a.cs.okstate.edu (Kurt F. Sauer)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple 331 password responses in FTP protocol

In article <8709041634.AA11908@topaz.rutgers.edu>, Ron Natalie writes:
>Beyond that conceptual problem, if I understand what is going on here,
>you're second password string actually changes the password?  This is
>a horrendous security problem and really ought not to be done in FTP.
>Better to just return an error (EXPIRED PASSWORD) and leave the user
>to correct the situation through other channels.

I absolutely concur.  Implementations of FTP were designed to perform file
transfers, not the changing of authenticators used in login situations.
This leaves one with a situation where subversion of local software (not
normally regarded as a trusted implementation) would render distant-end
protection useless.  I suggest you think this design issue out with a
security engineer, and I suspect that the median solution will probably
be something like Ron's suggestion above.  We would never allow user
programs to control foreign host access; this is somewhat akin to doing
just that.

A couple of guidelines which might be helpful from a more generic stand-
point: [PassMgtGuide85]

	4.2.2.3 [Password] Change Procedure
	     ...If the change is necesary due to an expired password,
	     the user should be so informed.  The user should be pre-
	     sented with a brief summary of the major steps in
	     changing a password, including a caution that the user
	     should ensure that no one else is watching what the user
	     is doing. ... The user should then enter the new password
	     twice so the procedure can verify that the user can con-
	     sistently enter the password correctly.  The new password
	     should be obliterated by techniques such as overprinting
	     or terminal screen erasing. ...

While it is true that many (tho not all!) UNIX implementations include a
passwd program that gives instructions, some do.  The more important con-
sideration is immediate:  Few FTP implementations here (none?) keep the
value supplied for ACCT from being displayed.  Further, it's true that several
implementations of FTP don't even protect the PASS value when it's entered
(unlike 4.3bsd UNIX implementations)!

	4.3.2 [Password] Entry
	     ... It is recommended that the system not echo pass-
	     words that users type in.  When the system cannot pre-
	     vent a password from being echoed ..., it is recommen-
	     ded that a random overprint mask be printed before or
	     after the password is entered, as appropriate, to con-
	     ceal the typed password.

	     The complete password as entered by the user should be
	     an exact match, character for character, with the user's
	     current password.

And, of course, using the ACCT feature won't allow for retyping the password
for correctness, which is a big "lose."

Think this out again and let us know what you decide.

Kurt F. Sauer
Tulsa, OK

----------
References:
[PassMgtGuide85]  National Computer Security Center, _ D_ e_ p_ a_ r_ t_ m_ e_ n_ t_  _ o_ f_  _ D_ e_ f_ e_ n_ s_ e
	_ P_ a_ s_ s_ w_ o_ r_ d_  _ M_ a_ n_ a_ g_ e_ m_ e_ n_ t_  _ G_ u_ i_ d_ e_ l_ i_ n_ e, Report CSC-STD-002-85 (Fort George G.
	Meade, MD: NCSC), April 1985.

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7-Sep-87 15:17:18 EDT
From:      hubcap@hubcap.UUCP (Mike S Marshall)
To:        comp.protocols.tcp-ip
Subject:   CMU/tektronix  tcp/ip software...

greetings...

The answer to my question has been posted before, but alas, I 
didn't care then :-).

Who can I contact to get the CMU/tek tcp/ip sofware...
Can I run it in shared deqna mode on a microvax?
Is it really a good, well documented product?

thanks

-Mike Marshall      hubcap@hubcap.clemson.edu        ...!hubcap!hubcap

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Mon, 7 Sep 87 12:21:51 GMT-0:00
From:      Yuko Murayama <murayama@Cs.Ucl.AC.UK>
To:        iso@nrtc.northrop.com, tcp-ip@sri-nic.arpa
Cc:        murayama@Cs.Ucl.AC.UK
Subject:   ISO8473 vs. IP
Could anyone let me know about the difference between ISO 8473
(protocol for providing the connectionless-mode network service)
and the DARPA IP?

Yuko Murayama
a Ph.D. student
Dept of Computer Science
University College London
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 05:05:00 EDT
From:      GBELING@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   unbix or rmx


hello, 
can anyone help me answer the following questions: 
a) how small can an unix-system be made which should run on an 80286 
    processor ( from intel) ? 
b) when using rmx (from intel) as operating system instead 
  are ther the protocols telnet/tcp/ip available somewhere ? 
thanks gerd beling west-germany 

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 09:06:22 EDT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

The simple reply is that they are very similar functionally, but
different in terms of header format and all that.

I would be hard pressed to say what the important differences were
since that depends on ones priorities.  However, the ISO8473 address
is much bigger (up to 20 bytes vs. 4 for DoD IP).  I like the
partial source routing of ISO8473 because I am involved in routing.
However, that feature can bite you if you are not careful, and I
wouldn't be surprized if it never gets widely implemented.

If one consideres ICMP to part and parcel of DoD IP, then there are
a couple more differences.  ICMP has the Echo function, which ISO8473 does
not, and has the Redirect.  However, ISO9542 (the ES-IS routing protocol
for use with ISO8473) has the redirect function, so its tit for tat.

I will be interested to see what others perceive as the major
differences between the two.  I have never sat down and made a
blow by blow comparison.


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

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 10:01:00 EDT
From:      jim@b-mrda
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and Unix file servers

does anyone know of a unix file server for pc's that uses the intelligent 
ethernet cards, as intelligent cards, with TCP/IP protocols and msnet support ?

Or am I asking for to much ???



		jim sadler
		206-575-7125
		hpubvwa!b-mrda!jim
		P.O. Box 3707 ms 9C-38
		Seattle, Wa. USA 98124

	Any opinions expressed are mine and mine only and not that of my
	employer.  Also add in whatever else should be said at this point.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 11:49:00 EDT
From:      berger@datacube.UUCP
To:        comp.protocols.tcp-ip
Subject:   Terminal Server Questions?


Looking for recommendations  and suggestions  on a  Ethernet - TCP/IP
Serial port sever.  These are the gadets that concentrate and connect
several  RS-232  ports  to  a  TCP/IP ethernet  backbone.   We have a
network of  Sun's, Pyramid,  generic 68020  Unix and  OS-9 systems as
well as PC's on our network.  We have run out of  genric serial ports
and are looking  at this  as a  mechanism to  distribute serial ports
around the company.  

We have an immediate need for additional  ports, but  we are thinking
that for the mondo growth we are experiencing that we will
standardize on using these concentrators for  connecting serial ports
to various Unix boxes.  Is this a good idea?  The serial port traffic
is  primairly  terminals  but a  chunk of  the traffic  is high speed
binary download modules.  

We  are  looking at  the Encore  Annex, the  Cisco ASM Communications
Server and the Micom Ethernet Terminal Server.  Are  there others out
there worth looking at?   Are there  known good/bad  things about the
above devices?  I'm looking for tips, hints and  experiences.  Please
send via E-Mail and I will synopsize to the net.  

				Bob Berger 

Datacube Inc. Systems / Software Group	4 Dearborn Rd. Peabody, Ma 01960
VOICE:	617-535-6644;	FAX: (617) 535-5643;  TWX: (710) 347-0125
UUCP:	berger@datacube.COM,  ihnp4!datacube!berger
	{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 12:02:20 EDT
From:      bhanji@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP


   Date:     Mon, 7 Sep 87 12:21:51 GMT-0:00
   From: Yuko Murayama <murayama@Cs.Ucl.AC.UK>

   Could anyone let me know about the difference between ISO 8473
   (protocol for providing the connectionless-mode network service)
   and the DARPA IP?

   Yuko Murayama
   a Ph.D. student
   Dept of Computer Science
   University College London

A document put out by the National Research Council in 1985 briefly
describes the differences between the DoD IP and ISO IP pp 18-24.
The report is mostly dedicated to the comparison between TCP and
TP4 but has a small section on the two IP comparison.
"Transport Protocols for Department of Defense Data Networks",
Report to the Department of Defense and the Bureau of Standards.
Committee on Computer-Computer Communication Protocols,
Board on Telecommunications and Computer Applications,
Commission on Engineering and Technical Systems, National Research
Council.
NATIONAL ACADEMY PRESS, Washington, D.C. February 1985.

Hope this is helpful.

Shiraz Bhanji.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 12:04:45 EDT
From:      zeeff@b-tech.UUCP (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re:  Where can I find SLIP server for 4.2/3?

In article <8708300436.AA03739@beno.CSS.GOV> rick@SEISMO.CSS.GOV (Rick Adams) writes:
>
>Note: SLIP is ONLY a device driver. You have to come up with
>your own IP, TCP, ICMP, ETC
>

So it seems that to use 4.xbsd machine as a slip server (ie. I want a 4.x
machine to talk to a PC via slip, giving a PC network access), there
would be some simple software needed to pass packets from the slip driver to
the regular ip driver.  Has anyone written such software?

>To answer the other popular question, no there is no RFC describing the
>"protocol" (I hesitate to call it a protocol. Its a simple framing
>scheme.)

Perhaps there is some other documentation of the framing scheme?



-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 12:37:55 EDT
From:      hagens@JANEB.WISC.EDU (Robert Hagens)
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

Comparison of DoD IP and ISO IP:

As Paul pointed out, functionally the same. Here are some other differences:

- No upper layer protocol ID in ISO8473.
- Headers in ISO8473 can be 255 octets (vs. 60 for DoD IP). 
- Support of header parameters is optional in ISO8473, mandatory in DoD IP.
- Time to live in ISO8473 is 1/2 sec as opposed to 1 sec for DoD IP.
	(It will still end up being used as a hop count.) 
- No timestamp parameter in ISO8473. 
- Fixed part of ISO8473 header has odd byte aligned, 2 byte fields.
- DoD IP fragmentation is called segmentation in ISO. Identical function,
	however all ISO8473 optional parameters  are carried with fragment. 
	(Called a derived PDU).

Only in ISO8473:
- Error Report PDU. Sent when a data PDU is discarded. Almost identical to 
	data pdu except it contains the reason for discard. Data of error 
	report PDU is header of discarded PDU. Error report contains 
	ICMP functionality of destination unreachable, ttl expired and
	parameter problem.
- 'congestion experienced'. Set by a router, when a router 
	experiences congestion.

The two biggest differences I see are the address part and lack of 
upper layer proto id.

Rob Hagens
UW Madison Computer Science

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 12:38:45 EDT
From:      jgh@root.co.uk (Jeremy G Harris)
To:        comp.protocols.tcp-ip,comp.unix.wizards,comp.bugs.4bsd
Subject:   IP options

Are there any known problems in the 4.3 code dealing with IP options?
I can't understand it....

Specifically, in routine ip_dooptoptions, file ip_input.c:

1) Strict source route with record
    appears to record an address for the receiving
    interface rather than the transmitting one.
2) Record route
    appears to route the datagram based on a garbage address,
    bouncing an ICMP "source route failed" if this fails   or
    recording an address for the bogus transmitting interface
    if it succeeds.


Are these bugs or have I missed something?
Has anybody fixed them?
Does anybody use IP options anyway?
Do I have an out-of-date RFC?


Thanks in antici... . .  . pation,
Jeremy


Reference: RFC 791: IP protocol spec.  Sept '81   pp. 20,21
		"... address as known in the environment into which
		     this datagram is being forwarded"

                   (identical wording in two places)

-- 
Jeremy Harris			jgh@root.co.uk

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 13:02:44 EDT
From:      geof@apolling.UUCP (Geof Cooper)
To:        comp.protocols.tcp-ip
Subject:   Re: Re:  HELP: select() under sockets


 > The definition of the first argument to the socket is the maximum file
 > descriptor that can be specified in any of the other fields.  You set
 > it to one (presumably because you are assuming the value was supposed to
 > be the number of things selecting on).  Setting this value to one means
 > that you can only select on file descriptor 0.  Set the value to something
 > larger like the maximum number of file descriptors (NFILE).

Umm, I just looked into /usr/include/stdio.h on our apollo system:

    Changelog entry:
        10/01/82 jrw  increased _NFILE from 20 to 128.....

So using NFILE is probably NOT the way to go, unless you declare
readfds, et al as arrays (this leads one to wonder, of course, why
the existing apollo software works at all -- since I know of no code
that actually uses arrays with select.  Probably because no one actually
opens more than 32 file descriptors and only THEN creates a socket...).

In a separate note to Mr. Widdowson, I suggested:

        min( 8 * (sizeof readfds), NFILE )

so that the argument really does reflect the size of the data
being passed to it.  Actually,

        8 * (sizeof readfds)

is probably sufficient, since you will never actually turn on
a bit that is beyond NFILE (hmmm... maybe little-endian vs
big-endian affects things... comments?).

Unfortunately, this is non-portable, since the size of a char is
not necessarily 8 bits.  But I suspect that all network software
would break if char != octet.

- Geof

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 14:02:13 EDT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

> 
> Comparison of DoD IP and ISO IP:
> 
> As Paul pointed out, functionally the same. Here are some other differences:
> 
> - No upper layer protocol ID in ISO8473...................
> 
> The two biggest differences I see are the address part and lack of 
> upper layer proto id.
> 
> Rob Hagens
> UW Madison Computer Science
> 

This is not to say that ISO8473 cannot distinguish between upper layer
protocols.  The address in ISO8473 is used to do the distinguishing
(the address is called the Network Service Access Point Address, which
defines the boundary between the transport thing and the network thing.
I don't want to get into what "thing" is).

Practically speaking, one reserves a byte (sorry, octet) in the NSAP
address, usually called the NSAP selector, to do the job of the
protocol id field in DoD IP.  Boils down to the same thing as far as
I can tell.

(I'm wondering if it is kosher to use the NSAP selector byte to
distinguish between different transport classes (TP0, TP1, ...., TP4).
Something tells me it isn't, but I don't see how someone could stop you.
I'll have to bring that up at the next 3.3 meeting).


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

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 14:38:21 EDT
From:      tsuchiya@gateway.mitre.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

> From: "Marty Schoffstall" <schoff@nic.nyser.net>
> Status: R
> 
> 
>     - 'congestion experienced'. Set by a router, when a router 
>     	experiences congestion.
> 
> The infamous "DEC Bit", which reports to the recipient of the packet
> that there is congestion.  This bit has debatable merit, would the
> two camps like to expound?
> 
> Marty

Ok, I'll bite.

The DEC bit is used, at least in DECNET (phase 4 or 5, I don't know)
to control the transport window such that the network doesn't get
congested.  It is a "congestion avoidance" mechanism.  As far as I
know, the algorithm assumes it knows the round trip time.  I don't
know if DEC measures this or assumes a value.  (I understand the
problems associated with trying to measure it.)  The algorithm
seems to be a good one, and works as long as all of the parts are
there and everyone participates.  (Please, someone from DEC correct
me if I have this screwed up).

DEC has released there algorithm for doing this (until recently, it
was proprietary).  In their IS-IS routing proposal, they have said
when to set the bit.  I am not sure how or if they intend to standardize
the part that tells the transport machine what to do.  I suppose this
could be done right in ISO, or in one of the profile organizations like
COS.

Tsuchiya

PS.  We may be in two camps, but lets face it:  if it rains, all of
our campfires are going to go out.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 14:42:52 EDT
From:      schoff@NIC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP


    - 'congestion experienced'. Set by a router, when a router 
    	experiences congestion.

The infamous "DEC Bit", which reports to the recipient of the packet
that there is congestion.  This bit has debatable merit, would the
two camps like to expound?

Marty

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 14:57:55 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  unbix or rmx

I know of no RMX TCP/IP implemenations.  However, the XENIX (UNIX) for the
286 doesn't really have TCP/IP either.  You can buy inteligent protocol cards
from a company like CMC (they have the software for XENIX) to talk to the
Ethernet with TCP/IP.  You ought to be able to write a RMX interface for this
if you know enough about RMX.

As for how small XENIX can get?  I'm not sure.  I only had a single memory
card in my 310 but I have no idea how much was on it (a meg?).  As for disk
space, a minimal system comes on a single floppy disk so that you can load
in the rest of the baseline system which comes on around 20 360K floppies.
This means that the baseline system takes up less than 7 MEG, but you could
probably reduce that even smaller by throwing away things like /usr/dict/words
and other large systems that aren't used.  UNIX also needs somewhere to swap
but you can probably get by with a few meg for this.

-Ron

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 15:45:26 EDT
From:      zben@umd5.umd.edu (Ben Cranston)
To:        comp.protocols.tcp-ip
Subject:   Re:  HELP: select() under sockets

In article <8709061618.AA14584@topaz.rutgers.edu> ron@TOPAZ.RUTGERS.EDU (Ron Natalie) writes:
> The definition of the first argument to the socket is the maximum file
> descriptor that can be specified in any of the other fields.  You set
> it to one ... Set the value to something
> larger like the maximum number of file descriptors (NFILE).

(Hiya Ron!) People have been talking about setting NFILE bigger than 32,
so I think it is worth mentioning that the first argument to select is used
to tell it the width of the bitmaps in the succeeding arguments.  So if they
are INTs you probably want to set it to 32.  Of course, if your system DOES
have NFILE set bigger than 32 and you happen to get a FD with a higher number,
that (1<<nfd) suddenly turns into a zero and the code no longer does what
one thought it would...  So waddya want to do?

	if (nfd>31)
		diehorribly("fix this mess")
	else {
		num = select( 32 , (1<<nfd) , ...)
	}

or what?  Idunno...
-- 
Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can).
       umd5.UUCP    <=      {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
zben @ umd2.UMD.EDU         Kingdom of Merryland UniSys 1100/92
       umd2.BITNET          "via HASP with RSCS"

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 17:16:40 EDT
From:      rcallon@PARK-STREET.BBN.COM (Ross Callon)
To:        comp.protocols.tcp-ip
Subject:   re: ISO8473 versus (DARPA) IP

Yuko;

I think we need more experience in actually using the ISO IP before we say
which differences are the most important, but here are a few that come to mind.
I hope this is a useful start.

If you are doing a study of the differences between the DARPA IP and the ISO
IP, or looking at implementation issues with the ISO IP, I would be very
interested in seeing any result which you may come up with.

(1) As Paul mentioned, the ISO uses variable length addresses up to 
    20 octets, while the DOD uses fixed length 4 octet addresses.  The
    ISO addresses are much more flexible.  For example, they may be used
    to explicitly encode something like an "autonomous system" number, 
    and/or the IEEE 802 link address.  
    
    I think that the difference in addresses make the ISO IP more appropriate
    for worldwide use with potentially hundreds of thousands of networks, but
    make it more costly to run (bigger headers and more processing).  

(2) The IPs use different checksums.  The ISO checksum is computationally
    more costly, but has a higher probability of detecting errors in which 
    only a small number of bits are changed (i.e., random bit errors as
    opposed to burst errors).  In addition, the ISO checksum can be "turned
    off" by using all zeroes in the checksum field.  

(3) The ISO IP doesn't have a source quench.  This is because at the time 
    no one who went to the meetings where it was defined believed that 
    source quench was useful.

(4) The ISO IP has a small difference in the way that source routing is 
    implemented.  The "destination address" field in the ISO IP always 
    contains the true final destination address, rather than the "next
    hop" source routing address.  This means that all of the gateways need
    to implement source routing for it to work (rather than only those
    gateways which are actually mentioned in the source route).  Since 
    implementation of source routing is optional in the ISO IP, it is 
    unlikely that all gateway vendors will actually implement it.

(5) The ISO IP doesn't have an echo packet.  The idea was that you could 
    get the same effect by source routing a packet to another gateway and 
    then back to yourself.  Unfortunately, as mentioned in (4), this is not 
    likely to work since implementation of source routing is optional.  
    People in ANSI are aware of this problem and thus it is likely to be 
    fixed eventually (I hope).

(6) The encoding of many of the fields are different.  For example, the 
    fields needed for reassembly (fragment offset, etc..) are only present 
    in the ISO IP if fragmentation is permitted.  Similarly, the "security"
    option had to take into account the fact that the ISO IP is standardized
    for worldwide use, and therefore needs greater flexibility.  Generally, 
    the ISO IP has opted for greater flexibility, and the cost of larger 
    packets and possibly greater cost in parsing the headers.


Ross

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8 Sep 87 17:16:40 EDT
From:      Ross Callon <rcallon@PARK-STREET.BBN.COM>
To:        murayama@CS.UCL.AC.UK
Cc:        iso@NRTC.NORTHROP.COM, tcp-ip@SRI-NIC.ARPA
Subject:   re: ISO8473 versus (DARPA) IP
Yuko;

I think we need more experience in actually using the ISO IP before we say
which differences are the most important, but here are a few that come to mind.
I hope this is a useful start.

If you are doing a study of the differences between the DARPA IP and the ISO
IP, or looking at implementation issues with the ISO IP, I would be very
interested in seeing any result which you may come up with.

(1) As Paul mentioned, the ISO uses variable length addresses up to 
    20 octets, while the DOD uses fixed length 4 octet addresses.  The
    ISO addresses are much more flexible.  For example, they may be used
    to explicitly encode something like an "autonomous system" number, 
    and/or the IEEE 802 link address.  
    
    I think that the difference in addresses make the ISO IP more appropriate
    for worldwide use with potentially hundreds of thousands of networks, but
    make it more costly to run (bigger headers and more processing).  

(2) The IPs use different checksums.  The ISO checksum is computationally
    more costly, but has a higher probability of detecting errors in which 
    only a small number of bits are changed (i.e., random bit errors as
    opposed to burst errors).  In addition, the ISO checksum can be "turned
    off" by using all zeroes in the checksum field.  

(3) The ISO IP doesn't have a source quench.  This is because at the time 
    no one who went to the meetings where it was defined believed that 
    source quench was useful.

(4) The ISO IP has a small difference in the way that source routing is 
    implemented.  The "destination address" field in the ISO IP always 
    contains the true final destination address, rather than the "next
    hop" source routing address.  This means that all of the gateways need
    to implement source routing for it to work (rather than only those
    gateways which are actually mentioned in the source route).  Since 
    implementation of source routing is optional in the ISO IP, it is 
    unlikely that all gateway vendors will actually implement it.

(5) The ISO IP doesn't have an echo packet.  The idea was that you could 
    get the same effect by source routing a packet to another gateway and 
    then back to yourself.  Unfortunately, as mentioned in (4), this is not 
    likely to work since implementation of source routing is optional.  
    People in ANSI are aware of this problem and thus it is likely to be 
    fixed eventually (I hope).

(6) The encoding of many of the fields are different.  For example, the 
    fields needed for reassembly (fragment offset, etc..) are only present 
    in the ISO IP if fragmentation is permitted.  Similarly, the "security"
    option had to take into account the fact that the ISO IP is standardized
    for worldwide use, and therefore needs greater flexibility.  Generally, 
    the ISO IP has opted for greater flexibility, and the cost of larger 
    packets and possibly greater cost in parsing the headers.


Ross
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 18:14:35 EDT
From:      carrs@TROUT.NOSC.MIL (Stephen M. Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

-------
Ref:  (a) National Research Council, "Transport Protocols for
          Department of Defense Data Networks", RFC942, National
          Academy Press, Washington, D.C., February 1985

Yuko,

1.  Reference (a) document which Shiraz Bhanji referred to is
online at sri-nic.arpa.  The path name is <RFC>RFC942.TXT.  So if
you have FTP capability, you can download it.  It is in excess of
217,000 bytes.

2.  I am assuming that you don't have FTP capability from your
host into the ARPANET/MILNET.  Therefore, if you would like, I or
one of your colleagues could try to forward it to you via SMTP.

3.  Here is a list of other recent RFCs which might interest you
on related subjects.  All of these documents are online in the
same directory.


                             RFC INDEX
(RFC1008)
                   Jun 87    (McCoy)       Implementation Guide for the ISO
   Transport Protocol
(RFC1007)          Jun 87    (McCoy)       Military Supplement to the ISO
   Transport Protocol
(RFC1006)
                   May 87    (Rose)        ISO Transport Services on top
   of the TCP  Version:3  (Obsoletes RFC 983)
(RFC995)
                   Jan 87    (ANSIx353.3)  End System to Intermediate System
   Routing Exchange Protocol for use in conjunction with ISO 8473
(RFC994)
                   Jan 87    (ANSIx353.3)  Final Text of DIS 8473, Protocol
   for Providing the Connectionless Mode Network Service (Obsoletes RFC 926)
(RFC962)
   ...             Nov 85    (Padlipsky)   TCP-4 Prime
(RFC945)
   ...             Apr 85    (Postel)      DOD Statement on NRC Report
(RFC942)
   ...             Mar 85    (NRC)         Transport Protocols for Department
   of Defense Data Networks
(RFC939)
   ...             Feb 85    (NRC)         Executive Summary of the NRC Report
   on Transport Protocols for Department of Defense Data Networks
(RFC905)
   ...             Apr 84    (ISO)         ISO Transport Protocol Specification
   (ISO DP 8073) (Obsoletes RFC 892)

4.  I hope this is of some help.

                           Steve Carr
                          LCDR, SC, USN

Navy Management Systems Support Office (Code 33C)
Naval Air Station
Norfolk, Virginia 23511-6694

DDN:  carrs@trout.nosc.mil
DDN:  navmasso30tc@nardacva.arpa
-------

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 18:40:17 EDT
From:      cam@columbia-pdn (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   Once More on FTP Password Expiration, Etc.

Folks,

I thought I could lay this subject to rest after my last response but
people still seem confused by what we're talking about here.

The average security package for MVS implements facilities to age passwords
and to not allow the user access to the system after his password has 
expired UNLESS a new password is also provided; note that the expired password
must still be provided WITH a new password in order to login. These packages
also allow the user to change his/her password for whatever reason. In 
addition, a user may exist in multiple "groups", each of which permits the
user different access privileges. These features are part of the security 
package and are not a creation of ACC or ACCES/MVS (our software).

Now, given this, all well-behaved IBM subsystems that gather a userid/password
and validate that against the security system, provide a way for the user
to specify an optional new password and group at signon. The new password can
be specified to change your existing password at any time, or to change your
password if the old one has expired. The group can be specified to select a
group from the set of groups in which that user is a member. This list of 
well-behaved subsystems is large and includes CICS, IMS, TSO, and NCCF. 

In other words, the standard MVS environment supports the sort of thing 
we're talking about here; we at ACC are merely trying to integrate our product 
into that environment.

Regarding the notion that ACC has proposed an "FTP protocol modification":

1) The current FTP specs suggest that the USER/PASS command arguments are
"that which is required by the SERVER for access to its file system".
The specs do not say that the USER or PASS arguments take any particular
form. In fact, the USER argument is specified as a string of any of the
128 ASCII characters except CR and LF; ditto for the PASS argument. In my 
opinion, the argument "oldpass/newpass GROUP(xxx)" does not violate or modify
the FTP spec. I am suggesting (strongly) that this is valid syntax for
a PASS argument, per the spec; whether or not this fits your notion of what a 
userid or password "looks like" depends on whether you regularly work on 
an MVS system or not.

Regarding the notion that we are creating a Server FTP that will not 
interoperate with other Client FTP implementations:

1) Assuming that you are the average user who is only in one group and whose
password is not expired, all you will need to send our server is 
"USER chris" and "PASS chris-pswd", just as is done now. Even if you are in 
multiple groups, there is a default group associated with each user that 
will be in effect if no group is specified. I see no interoperability problem
here.

Regarding specification of new passwords and groups via the SITE command, I
see two problems:

1) Not all FTP Client implementations provide a SITE command, which is 
understandable, but worse, not all those non-SITE providers provide a 
"quote" facility either. 

2) The use of the SITE command to provide new password group information
creates a second, unrelated place where this information must be specified;
the logical, intuitive place is in the USER/PASS command text.

Regarding the notion that people could access the MVS system via Telnet to 
change their password if it expired:

1) This doesn't address the need to optionally specify a group name together
with a userid.

2) A site may allow a user to use the MVS system through FTP but not allow the
user access to any subsystem (eg. TSO, CICS, IMS) which would allow him to
change his password.  Clearly this sort of user would have limited capabilites,
but it is not hard to envision this sort of environment.

Regarding ignoring the expired password condition and allowing the user to 
login anyway:

1) This would not be popular with MVS customers that want to mandate the use
of aged passwords. MVS security auditors are not very keen on making exceptions
for certain security situations.

In conclusion, all ACC is trying to do is to integrate ACCES/MVS into the
MVS environment as a well-behaved software product (from the MVS perspective).
So long as we do this without violating the FTP spec (which I contend we 
haven't) and without affecting interoperability with other implementations
(which I contend we don't) we should be free to make our product fit as 
nicely and logically into MVS as possible.

Chris Markle - cam@acc-sb-unix.arpa - (301)290-8100

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 18:43:00 EDT
From:      CDC-DDN@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   Sendmail message delays and timeout


  
We are having a problem using UNIX 4.3 sendmail.  It will send messages 
to our CYBER quickly (1 sec) for a while, and then will gradually take
longer and longer to send a message until finally it takes so long (7
minutes) to send the message that some UNIX timer kicks in and aborts
the connection.  When this happens, all subsequent messages time out in
this manner, and we cannot send messages to the CYBER until we re-boot
the VAX.
  
We have looked at this with both an Ethernet analyzer and using the debug
facility within sendmail.  In the slow transactions, there is a delay of 
several minutes between the time that UNIX TCP receives the 354 reply to
the DATA command, and the time that UNIX TCP sends the message text.
The delay is always at this one point, and there is no other difference
between slow and fast transactions.  Even in sessions that time out, the 
sendmail debug output indicates that sendmail believes it has sent the
message text, but it never appears on the Ethernet.  There are no
retransmission packets or ICMP messages to indicate some lower-level
problem.
  
Does anyone know what might be causing this problem?  Any pointers will
be appreciated.
  
Mike Sanders
CDC-DDN@DDN3

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 87 18:43 EDT
From:      CDC-DDN @ DDN3.arpa
To:        tcp-ip @ sri-nic.arpa
Cc:        cdc-ddn @ ddn3
Subject:   Sendmail message delays and timeout

  
We are having a problem using UNIX 4.3 sendmail.  It will send messages 
to our CYBER quickly (1 sec) for a while, and then will gradually take
longer and longer to send a message until finally it takes so long (7
minutes) to send the message that some UNIX timer kicks in and aborts
the connection.  When this happens, all subsequent messages time out in
this manner, and we cannot send messages to the CYBER until we re-boot
the VAX.
  
We have looked at this with both an Ethernet analyzer and using the debug
facility within sendmail.  In the slow transactions, there is a delay of 
several minutes between the time that UNIX TCP receives the 354 reply to
the DATA command, and the time that UNIX TCP sends the message text.
The delay is always at this one point, and there is no other difference
between slow and fast transactions.  Even in sessions that time out, the 
sendmail debug output indicates that sendmail believes it has sent the
message text, but it never appears on the Ethernet.  There are no
retransmission packets or ICMP messages to indicate some lower-level
problem.
  
Does anyone know what might be causing this problem?  Any pointers will
be appreciated.
  
Mike Sanders
CDC-DDN@DDN3


-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 21:00:15 EDT
From:      mts@EMPTYS.CC.UMICH.EDU (Michael T. Stolarchuk)
To:        comp.protocols.tcp-ip
Subject:   Re: HELP: select() under sockets


	Umm, I just looked into /usr/include/stdio.h on our apollo system:
	 
	    Changelog entry:
		10/01/82 jrw  increased _NFILE from 20 to 128.....
	 
	So using NFILE is probably NOT the way to go, unless you declare
	readfds, et al as arrays (this leads one to wonder, of course, why
	the existing apollo software works at all -- since I know of no code
	that actually uses arrays with select.  Probably because no one actually
	opens more than 32 file descriptors and only THEN creates a socket...).
 
 How about 4.3? Where select is:
 
	nfound = select(nfds, readfds, writefds, exceptfds, timeout)
	        int nfound, nfds;
	   	fd_set *readfds, *writefds, *exceptfds;
		struct timeval *timeout;
	
 And you have:
	FD_SET(fd, &fdset)
	FD_CLR(fd, &fdset)
	FD_ISSET(fd, &fdset)
	FD_ZERO(&fdset)

 And fd_set is:
	typedef struct fd_set {
		fd_mask fds_bits[howmany(FD_SETSIZE, NFDBITS)];
		} fd_set;

 And FD_SETSIZE is 256.


mts. the snail.  imagine him at 100 mhp.

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 8-Sep-87 21:59:00 EDT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   More on RARP under 4.x BSD

>	From: bbanerje@sjuvax.UUCP (B. Banerjee)
 ...	
>	c. 	Rarp can be added to 4.3 BSD.
 ...	
>	You can  write a rarp daemon
>	with the aid  of the 'enet' ethernet packet  filter software that
>	was part of the ``user contributed software '' that came with 4.3
>	BSD.

Yes, probably.  I doubt that the "enet" code distributed on the 4.3 tapes
will actually work without modification (actually, the modification
required is to the interface driver code for whatever interface you are
using).  As Greg Satz said in a recent message, you can probably get
the working code from someone at Stanford ... but I don't know who (it
is NOT either Greg or myself, so don't bother asking).

People at Stanford (different people, probably) also have a "rarpd" that
uses the packet filter.  You could try to get that, although it really
is a fairly simple program to write.

>	I personally  believe that it makes  the most sense to  place the
>	rarp handling  stuff along with  the 'arp' handling stuff  in the
>	kernel (netinet/if_ether.c).

Unfortunately, this is infeasible in a large campus, since the ARP tables
in the kernel are meant to be small and, when the overflow, it is
normally safe to throw away old entries (they will be restored if they
are used again).  At a site like Stanford, where there may be hundreds
or even thousands of diskless workstations eventually, the current
kernel ARP table is clearly not going to work.

RARP is not a performance-critical protocol; a user-mode server is
the right way to go.  It's sad that 4.xBSD has no mechanism to write
such servers (i.e., no link-level access mechanism); that's what the
packet filter or NIT is meant to provide.  With such a mechanism, it's
trivial to put the RARP server in the right place.  Maybe 4.4BSD will
do something about this.

-Jeff Mogul
(co-author of the packet filter code and of the RARP RFC)

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 02:49:24 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

Marty,

The "congestion experienced" bit has to be a good idea, since it has been
suggested repeatedly by Jack Haverty (name one) and several others at BBN
for darn near ten years. So, let's do it. We need to swipe a bit from the
IP header. Any suggestions on which one? That bit decided, give me ten
seconds and the fuzzballs will concur in the madness...

Dave

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 06:13:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

RE: DEC Bit (Congestion Experienced)

When I talked with Tony Lauck about this notion, the idea was
that you could tell the receiving party "sooner" than the sending party
about this congestion problem and that the receiving party might use
the window mechanism to reduce the sender's ambition level until the
congestion had died away. The sender probably needs to know about
the congestion explicitly, too, if there is any option for re-routing
the traffic from the origin via an alternate path which is less
congested.

It would be helpful to hear from Digital about their experiences with
the dynamics of their DECNET with and without the use of this signal.

Vint

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1987 06:13-EDT
From:      CERF@A.ISI.EDU
To:        schoff@NIC.NYSER.NET
Cc:        hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK tcp-ip@SRI-NIC.ARPA, tsuchiya@GATEWAY.MITRE.ORG
Subject:   Re: ISO8473 vs. IP
RE: DEC Bit (Congestion Experienced)

When I talked with Tony Lauck about this notion, the idea was
that you could tell the receiving party "sooner" than the sending party
about this congestion problem and that the receiving party might use
the window mechanism to reduce the sender's ambition level until the
congestion had died away. The sender probably needs to know about
the congestion explicitly, too, if there is any option for re-routing
the traffic from the origin via an alternate path which is less
congested.

It would be helpful to hear from Digital about their experiences with
the dynamics of their DECNET with and without the use of this signal.

Vint
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 07:11:28 EDT
From:      schoff@NIC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP


    The "congestion experienced" bit has to be a good idea, since it has been
    suggested repeatedly by Jack Haverty (name one) and several others at BBN
    for darn near ten years. So, let's do it. We need to swipe a bit from the
    IP header. Any suggestions on which one? That bit decided, give me ten
    seconds and the fuzzballs will concur in the madness...

Dave, I don't know how to take the above message.  I don't believe I have
a fully-formed opinion on this due to the fact that I have
not seen the DEC "paper" however
I have some philosophical questions about this in the ISO stack:

	Isn't this mechanism  a bit indirect?  Does anyone have some
		thoughts about latency in a live ISO INTERNET?.
		Your transmitter is hosing the net, Mr. Gateway
		(whoops IS), 4 PDN's away determines there is
		congestion toggles the bit and we arrive at
		the receiver.  The receiver then takes this
		Layer3 information exports it to the Layer4
		machine who does something bright with it
		like communicating with the transmitter Layer4.
		[ My recollection of this is that Layer4 had
			to be TP4, ie this wasn't going to
			be effective for other transports.]

This mechanism seems right for at least experimental use in the DOD INTERNET,
a small alteration of a mature operational protocol.   However, it looks
like a hack in the ISO stack if the ISO stack is supposed to have been
an improvement on what we've learned in the last 10 years....

Dave, how do you feel this should affect the TCP if implemented in the
DOD stack?

Marty

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Sep 87 07:38:39 EDT
From:      tsuchiya@gateway.mitre.org (Paul Tsuchiya)
To:        Mills@udel.edu, schoff@nic.nyser.net
Cc:        <schoff@nic.nyser.net>, Schoffstall@nic.nyser.net, iso@nrtc.northrop.com, murayama@cs.ucl.ac.uk, tcp-ip@sri-nic.arpa
Subject:   Re: ISO8473 vs. IP
> From: "Marty Schoffstall" <schoff@nic.nyser.net>
> Status: R
> 
> 	Isn't this mechanism  a bit indirect?  Does anyone have some
> 		thoughts about latency in a live ISO INTERNET?.
> 		Your transmitter is hosing the net, Mr. Gateway
> 		(whoops IS), 4 PDN's away determines there is
> 		congestion toggles the bit and we arrive at
> 		the receiver.  The receiver then takes this
> 		Layer3 information exports it to the Layer4
> 		machine who does something bright with it
> 		like communicating with the transmitter Layer4.
> 		[ My recollection of this is that Layer4 had
> 			to be TP4, ie this wasn't going to
> 			be effective for other transports.]
> 
> Marty

The algorithm doesn't work quite like that.  In fact, the bit is
set roughly half the time, and all it takes is one packet in the
queue to set the bit.  Setting it half the time has the result of getting
the most information out of it (information theory).  So it is not
like there is a problem and then the bit is set to relieve the problem.
Instead, the bit is continuously set to achieve a smooth and appropriate
flow of data into the net.  I.e., we neven (hopefully) reach the point
where a transmitter is hosing the net in the first place.

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

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 08:04:48 EDT
From:      schoff@NIC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP


This paragraph isn't clear to me....

    The algorithm doesn't work quite like that.  In fact, the bit is
    set roughly half the time, and all it takes is one packet in the
    queue to set the bit.  Setting it half the time has the result of getting

whose queue?

    the most information out of it (information theory).  So it is not
    like there is a problem and then the bit is set to relieve the problem.

What is the algorithm for setting the bit then?  When everything is fine?

    Instead, the bit is continuously set to achieve a smooth and appropriate
    flow of data into the net.  I.e., we neven (hopefully) reach the point
    where a transmitter is hosing the net in the first place.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 08:26:21 EDT
From:      chris@GYRE.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  HELP: select() under sockets

Please read the select(2) manual entry on your 4.3BSD machine to
see how 4.3BSD defines select() (it is backwards compatible with
4.2BSD's definition through an implementation trick only).

(You might mentally substitute `properly cast NULL' for `zero pointer'
while you are reading...)

Chris

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 08:33:35 EDT
From:      tsuchiya@gateway.mitre.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

After all of this talking about the DEC scheme, I bloody well hope that
DEC gives me a good job offer.

I didn't want to get into details over the air.  I have the breifing
slides from a presentation given at the IETF in Boston last (I think
it was) April.  They are fairly self explanatory.

Mainly, I wanted to dispel this notion that congestion control should
occur when there is congestion.  It should actually occur before there
is congestion, and that is what the DEC algorithm does.

The bit is set by gateways, and they set it whenever they have one
packet in the queue.  I believe this does not mean one packet per
source/destination pair or anything like that, simply one packet.
The bit is set in the queued packet, which means that the host
receiving the set bit is not the one that sent the packet, but the
one on the other end.  However, that one tells the sending one to
shrink its window via the normal method, and this is how the
congestion information gets back to the sending host.

Of course, the hosts have an algorithm they use to know how to
adjust the flow.  Basically, the window is increased additively
and decreased multiplicatively.  Also, the hosts filter by considering
x number of previous bits.

Again, an appeal to DEC people:  please correct me if I have
over-simplified, misrepresented, or in any other way screwed
this up.

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

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 08:51:48 EDT
From:      tsuchiya@gateway.mitre.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   errata (DECBIT)


This from Charles Hedrick, who was kind enough to not broadcast it:


> Are you sure?  As I recall, the DEC bit is set by any router when the
> queue has more than one item in it.  I didn't think the RTT was involved.
> It's main disadvantage seemed to be that its resolution wasn't very good,
> so a large number of simultaneous connections could confuse it.


Right you are.  I don't know how the idea of RTT got into my head.
(Actually I do, but I don't want to say).

So much for my spiffy job offer from DEC.  How about a lawsuit instead.


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

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 09:36:00 EDT
From:      NS-DDN@DDN3.ARPA
To:        comp.protocols.tcp-ip
Subject:   MVS FTP Server Access



Chris, I apologize to you and this conference for terming your proposal an
FTP protocol modification. I was wrong, and you were right regarding the
syntax of the USER and PASS command arguments. Your syntax does make more
sense than using a SITE command, but you may find some user FTPs that are
unable to support it. That's life in the big (Internet) city. I would propose
that ALL MVS software use a consistent access methodology as hammered out
through appropriate facilities, in the spirit of interoperability. Perhaps
an RFC is called for. What do people think?

Best regards,

Dave Craig
Network Solutions, Inc.

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 87 09:36 EDT
From:      NS-DDN @ DDN3.arpa
To:        cam @ ACC-SB-UNIX.ARPA
Cc:        tcp-ip @ SRI-NIC.ARPA
Subject:   MVS FTP Server Access


Chris, I apologize to you and this conference for terming your proposal an
FTP protocol modification. I was wrong, and you were right regarding the
syntax of the USER and PASS command arguments. Your syntax does make more
sense than using a SITE command, but you may find some user FTPs that are
unable to support it. That's life in the big (Internet) city. I would propose
that ALL MVS software use a consistent access methodology as hammered out
through appropriate facilities, in the spirit of interoperability. Perhaps
an RFC is called for. What do people think?

Best regards,

Dave Craig
Network Solutions, Inc.

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 09 Sep 87 12:30:57 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        CERF@A.ISI.EDU, tsuchiya@GATEWAY.MITRE.ORG
Cc:        schoff@NIC.NYSER.NET, hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: ISO8473 vs. IP
Paul, Vint, or whoever else can help,

Is there a reference available for a description of this DECNET
congestion control mechanism, now that it is no longer proprietary?

Thanks,
Andy
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 10:26:44 EDT
From:      PERSHNG@IBM.COM (John Pershing)
To:        comp.protocols.tcp-ip
Subject:   (none)

I don't understand why one should trust "subverted local software" to
handle your *current* password, yet not trust it to set a *new* password.
(Note that the current password has to be provided before the new one can
be set.)

The scheme the Chris Markle proposes for setting new passwords makes
perfect sense to someone who is familiar with the normal IBM access
control procedures.  (Actually, the *original* scheme makes *more* sense,
except that the perpetrators of FTP don't seem to understand the
necessity of periodic password changes.)  However, the GROUP() parameter
on the PASS command seems a bit strange -- wouldn't it "look better" on
the USER command, without echo-suppression?

      John A. Pershing Jr.
      IBM T. J. Watson Research Center
      Yorktown Heights, NY  10598

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 11:22:00 EDT
From:      hsw@TYCHO.ARPA (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   ACC Customer Service

Someone from ACC once posted a customer service address for themselves.
Could I that address re-posted - I thought it was customer.service at
acc-sb-unix.arpa, but mail that I send to that address gets returned
to me by acc-sb-unix.arpa.

Thanks,

Howard Weiss
-------

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1987 1122-EDT
From:      hsw@TYCHO.ARPA  (Howard Weiss)
To:        tcp-ip at sri-nic.arpa
Subject:   ACC Customer Service
Someone from ACC once posted a customer service address for themselves.
Could I that address re-posted - I thought it was customer.service at
acc-sb-unix.arpa, but mail that I send to that address gets returned
to me by acc-sb-unix.arpa.

Thanks,

Howard Weiss
-------

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 12:49:11 EDT
From:      ron@topaz.rutgers.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Once More on FTP Password Expiration, Etc.

Weell, sorry, but the proper approach is not to allow the user to log
in when the password is expired.  Having passwords that don't really
expire (just require the user to change them when they log in) are of
no use whatsoever.  Regardless of what the normal session login does,
this cruft does not belong in FTP.  As one of your customers, I suggest
that you take this under advice.

-Ron

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 12:53:51 EDT
From:      ron@topaz.rutgers.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  HELP: select() under sockets

The other arguments to select are pointers to bit fields so assumably

char	buf[10];

	select(80, buf, (char *) 0, (char *) 0, (char *) 0, (time_t) 0)

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 12:59:26 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

Paul, Vint, or whoever else can help,

Is there a reference available for a description of this DECNET
congestion control mechanism, now that it is no longer proprietary?

Thanks,
Andy

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 13:03:53 EDT
From:      NIC@SRI-NIC.ARPA (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   DDN MGT Bulletin #34

********************************************************************** 
DDN MGT Bulletin 34              DCA DDN Defense Communications System   
9 Sep 87                         Published by: DDN Network Info Center
                                    (NIC@SRI-NIC.ARPA)  (800) 235-3155


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

                     
                     ANNOUNCEMENT OF PSN UPGRADE


To all ARPANET users, Node Site Coordinators, and Host Administrators:

New versions of software are being released to the ARPANET backbone
network over the next six weeks.  This will cause minimal disruption
to the user community, but will require reloading of all Packet
Switching Nodes (PSN) on the ARPANET.  The software is referred to as
PSN 7.0 and contains the implementation of the new End to End
protocols.  A mailbox has been set up at BBNCC for questions and
comments regarding this software upgrade.  The E-mail address is
arpaupgrade@bbn.com.  The standard procedure to call the BBNCC Hotline
for problems will still be in effect.  The Toll free number is
1-800-492-4992.

The implementation of this software will happen in 2 phases.  The 1st
phase of the PSN 7.0 implementation will require site coordination and
cooperation.  All sites will have to place the new cassettes with boot
programs into their PSN's during their scheduled reboot.  Sites will
be notified by the ARPANET Monitoring Center, Cambridge, MA for details and
specific times for their scheduled upgrade.  New cassette tapes will
be sent to the individual node site coordinators.  This phase of the
transition moves the network from the current version (PSN 6.0) to PSN
7.0 with the new End to End protocol's not configured.  Individual
site upgrades will take approximately 15 minutes.

Phase II of the implementation will be the cutover to the New End to
End protocols.  The initial upgrade to PSN 7.0 and subsequent cutovers
will happen in the order specified in the schedule below.  Please be
aware that during the cutover period to new End to End, that said node
group will be logically segmented for a 2-3 hour test period from the
test of the ARPANET.

Any questions or comments can also be directed to Mark Whitney at
BBNCC (617) 497-2874 or Annette Bauman at DCA (703) 265-5459.


Schedule:			Event:

09/24/87-09/26-87	Node group 1 sites will be upgraded to PSN 7.0.

09/24-87-10/02/87	Resolve any outstanding issues with these sites.

10/01/87-10/03/87	Node groups 2 thru 5 upgraded to PSN 7.0.

10/03/87-10/10/87	Resolve any outstanding issues with these sites.

10/10/87		All ARPANET nodes running PSN 7.0 with new End to
			End protocols NOT configures.

10/10/87-10/17/87	Verify all operational procedures.

10/17/87		Node group 1 turnover to new End to End, operation
			verified and return to the old End to End.

10/17/87-10/24/87	Resolve any outstanding issues with above cutover.

10-24-87		The rest of the node groups cutover to new End to End,
			operation verified and returned to old End to End.

10/24/87-10/31-87	Resolve any outstanding issues with above cutover.

10/31/87		Entire ARPANET cutover to use new End to End protocols,
			operation verified, and return to the old End to End
			mode of operation.

10/31/87-11/07/87	Resolve any outstanding issues with above cutover.

11/07/87		Entire ARPANET cutover to new End to End protocols
			and left running.

11/07/87...		Statistical collection and analysis begins.
			

	     Group 1

	 1.  Node 79  DEC
	 2.  Node 28  ARPA
	 3.  Node 78  BERK
	 4.  Node 38  BRAGG
	 5.  Node 5   BBN5
	 6.  Node 77  MIT77
	 7.  Node 7   RAND
	 8.  Node 2   SRI2
	 9.  Node 6   MIT6
	10.  Node 91  UDEL
	11.  Node 20  DCEC
	12.  Node 14  CMU


	     Group 2

	 1.  Node 1    UCLA
	 2.  Node 22   ISI22
	 3.  Node 27   ISI27
	 4.  Node 52   ISI52
  	 5.  Node 68   LBL2
	 6.  Node 82   BBN82
	 7.  Node 107  SRI107
	 8.  Node 119  ARADC
	 9.  Node 126  NSA2


	     Group 3

	 1.  Node 25   CSS
	 2.  Node 32   XEROX
	 3.  Node 44   MIT44
	 4.  Node 46   COLNS
	 5.  Node 51   SRI51
	 6.  Node 63   BBN63
	 7.  Node 94   WISC
	 8.  Node 121  US121
	 9.  Node 127  N127


	     Group 4

	 1.  Node 9    HARV
	 2.  Node 15   UROCH
	 3.  Node 31   CCA
	 4.  Node 4    UTAH
	 5.  Node 56   SUMEX
	 6.  Node 62   TEXAS


	     Group 5

	 1.  Node 37   PURDUE
	 2.  Node 80   SAC
	 3.  Node 99   BBN99
	 4.  Node 10   LINC
	 5.  Node 89   COLUM
	 6.  Node 96   UDEL
	 7.  Node 11   STAN
	 8.  Node 54   CIT
	 9.  Node 111  MTR2
        10.  Node 13   UCOLORADO
        11.  Node 17   UMARYLAND


             Group 6

         1.  Node 115  CAMBRIDGE*

*NOTE:  This is a temporary node and will cease to exist after the
        end to end cutover has been completed.
-------

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 13:49:42 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

Marty,

My remarks should be interpreted with respect to the DARPA context, where
I have some idea of what TCP and other bangers might do with it (infer
source quench). Yes, is is true that the receiver, not the transmitter,
sees the bit; however, our experience has been that the resources being
starved are usually the buffer pool, which means the bit would probably be
set on either direction at substantially the same frequency. It works
either way, since either or both the transmitter or receiver can crank
back the window size.

I do not want to speculate on the latency of an ISO internet, except to
suggest that it will probably be similar to the DARPA internet, whatever
that evolves to.

Dave

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 15:06:37 EDT
From:      nhall@CS.WISC.EDU
To:        comp.protocols.tcp-ip
Subject:   dec bit


I dug out my notes from the IETF-X3S3.3 meeting at which R. Jain,
K. Ramakrishnan, and D. Chiu presented their "DEC-bit" talk,
and here I find the following references:
	Jain, IEEE JSAC Oct 1986
	Ramakrishnan, Netwroking Symp., Nov 1986
Since I have neither of these references, I don't know if either
one gives a description of the full use of the DEC bit, but
I'll send the authors a copy of this mail and see if they have
published a paper on the subject, for the folks who weren't
at the Boston meeting.
 
	Nancy

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 15:17:04 EDT
From:      rcallon@PARK-STREET.BBN.COM (Ross Callon)
To:        comp.protocols.tcp-ip
Subject:   problems with ISO DEC-bit

In the ISO IP, the DEC bit is located in an options field.  In particular,
the "Quality of Service Maintenance" option contains three possible classes
of encodings, one of which is called "globally unique".  One bit of this
globally unique QOS option is the congestion experience bit.  

The ISO spec explicitly specifies which functions must be implemented, 
and which are optionally implemented.  Support for the QOS option is not
required.  Thus not only is the presence of the DEC bit optional, but even
if it is there gateways are not required to look at it.  In addition,
"Congestion Notification" is also optional.  Even if the source uses
the globally unique QOS option, and the gateways update the DEC bit
appropriately, it is not required (at least by IS 8473) that the
destination will notify the Transport Implementation.

Clearly, optional implementation of the congestion bit is a problem,
especially since if some end systems pay attention to it and others ignore
it the "good guys" will end up suffering.  This may be overcome by requiring 
use of the DEC bit in implementers agreements (such as produced by the COS).

The placement of the bit in an option field means that if you want to use it
for all packets you are requiring the gateways to actually parse the options
fields for every packet.  This increases the processing demand on gateways.
This may be okay for low bandwidth internets, but gets more undesirable for
higher bandwidths (what constitutes higher bandwidths depends upon how much
processing power you are willing to put in your gateways).

I don't think the DEC bit has actually been used in an operational
environment (does anyone out there know differently?).  What we see in the
Arpanet seems to be a relatively large number of short and/or discontinuous
flows such as electronic mail and telnet traffic.  Transport based flow
control methods may be more appropriate for a smaller number of longer term
flows.  The combination of slow start (which is part of the way that the
DEC bit is to be used) plus regulating the growth rate of flows on each
connection, will prevent short term connections from "jumping in" with a
large increment of traffic all at once.  However, for very short lived
connections, this may be nearly equivalent to simply using a fixed very
small window size.  This approach also assumes that all users (or at least
the users associated with the overwhelming majority of network traffic)
will use a window based transport protocol.  All of this suggests that the
DEC bit is more an interesting research approach for use in some common
environments, rather than a proven technique.  

Ross

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9 Sep 87 15:17:04 EDT
From:      Ross Callon <rcallon@PARK-STREET.BBN.COM>
To:        iso@NRTC.NORTHROP.COM, tcp-ip@SRI-NIC.ARPA
Cc:        rcallon@PARK-STREET.BBN.COM
Subject:   problems with ISO DEC-bit
In the ISO IP, the DEC bit is located in an options field.  In particular,
the "Quality of Service Maintenance" option contains three possible classes
of encodings, one of which is called "globally unique".  One bit of this
globally unique QOS option is the congestion experience bit.  

The ISO spec explicitly specifies which functions must be implemented, 
and which are optionally implemented.  Support for the QOS option is not
required.  Thus not only is the presence of the DEC bit optional, but even
if it is there gateways are not required to look at it.  In addition,
"Congestion Notification" is also optional.  Even if the source uses
the globally unique QOS option, and the gateways update the DEC bit
appropriately, it is not required (at least by IS 8473) that the
destination will notify the Transport Implementation.

Clearly, optional implementation of the congestion bit is a problem,
especially since if some end systems pay attention to it and others ignore
it the "good guys" will end up suffering.  This may be overcome by requiring 
use of the DEC bit in implementers agreements (such as produced by the COS).

The placement of the bit in an option field means that if you want to use it
for all packets you are requiring the gateways to actually parse the options
fields for every packet.  This increases the processing demand on gateways.
This may be okay for low bandwidth internets, but gets more undesirable for
higher bandwidths (what constitutes higher bandwidths depends upon how much
processing power you are willing to put in your gateways).

I don't think the DEC bit has actually been used in an operational
environment (does anyone out there know differently?).  What we see in the
Arpanet seems to be a relatively large number of short and/or discontinuous
flows such as electronic mail and telnet traffic.  Transport based flow
control methods may be more appropriate for a smaller number of longer term
flows.  The combination of slow start (which is part of the way that the
DEC bit is to be used) plus regulating the growth rate of flows on each
connection, will prevent short term connections from "jumping in" with a
large increment of traffic all at once.  However, for very short lived
connections, this may be nearly equivalent to simply using a fixed very
small window size.  This approach also assumes that all users (or at least
the users associated with the overwhelming majority of network traffic)
will use a window based transport protocol.  All of this suggests that the
DEC bit is more an interesting research approach for use in some common
environments, rather than a proven technique.  

Ross
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 16:06:30 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options

As a matter of fact, there are a few oddities in the IP options code
in 4.3.  Of the two you mentioned, one is a bug (record route used
a garbage address which coincidentally works on machines with default
routes).  You appear to have misunderstood the code for source route,
though; look for the call to ip_rtaddr, which locates the outgoing
interface address.  The other bug of any interest was in IP timestamp
handling.  Here is a set of diffs to fix the record route bug and
several other minor things.

		Mike

*** /nbsd/usr/src/sys/netinet/ip_input.c	Thu Jun  5 00:28:15 1986
--- ./ip_input.c	Wed Sep  9 11:33:47 1987
***************
*** 5,7 ****
   *
!  *	@(#)ip_input.c	7.1 (Berkeley) 6/5/86
   */
--- 5,7 ----
   *
!  *	@(#)ip_input.c	7.6.1.1 (Berkeley) 9/9/87
   */
***************
*** 302,304 ****
  	if (fp == 0) {
! 		if ((t = m_get(M_WAIT, MT_FTABLE)) == NULL)
  			goto dropfrag;
--- 302,304 ----
  	if (fp == 0) {
! 		if ((t = m_get(M_DONTWAIT, MT_FTABLE)) == NULL)
  			goto dropfrag;
***************
*** 490,491 ****
--- 490,492 ----
  
+ extern struct in_ifaddr *ifptoia();
  struct in_ifaddr *ip_rtaddr();
***************
*** 595,597 ****
  				break;
! 			bcopy((caddr_t)(cp + off), (caddr_t)&ipaddr.sin_addr,
  			    sizeof(ipaddr.sin_addr));
--- 596,598 ----
  				break;
! 			bcopy((caddr_t)(&ip->ip_dst), (caddr_t)&ipaddr.sin_addr,
  			    sizeof(ipaddr.sin_addr));
***************
*** 602,604 ****
  				type = ICMP_UNREACH;
! 				code = ICMP_UNREACH_SRCFAIL;
  				goto bad;
--- 603,605 ----
  				type = ICMP_UNREACH;
! 				code = ICMP_UNREACH_HOST;
  				goto bad;
***************
*** 620,622 ****
  			}
! 			sin = (struct in_addr *)(cp+cp[IPOPT_OFFSET]-1);
  			switch (ipt->ipt_flg) {
--- 621,623 ----
  			}
! 			sin = (struct in_addr *)(cp + ipt->ipt_ptr - 1);
  			switch (ipt->ipt_flg) {
***************
*** 630,636 ****
  					goto bad;
! 				if (in_ifaddr == 0)
! 					goto bad;	/* ??? */
! 				bcopy((caddr_t)&IA_SIN(in_ifaddr)->sin_addr,
  				    (caddr_t)sin, sizeof(struct in_addr));
! 				sin++;
  				break;
--- 631,636 ----
  					goto bad;
! 				ia = ifptoia(ifp);
! 				bcopy((caddr_t)&IA_SIN(ia)->sin_addr,
  				    (caddr_t)sin, sizeof(struct in_addr));
! 				ipt->ipt_ptr += sizeof(struct in_addr);
  				break;
***************
*** 638,639 ****
--- 638,642 ----
  			case IPOPT_TS_PRESPEC:
+ 				if (ipt->ipt_ptr + sizeof(n_time) +
+ 				    sizeof(struct in_addr) > ipt->ipt_len)
+ 					goto bad;
  				bcopy((caddr_t)sin, (caddr_t)&ipaddr.sin_addr,
***************
*** 642,646 ****
  					continue;
- 				if (ipt->ipt_ptr + sizeof(n_time) +
- 				    sizeof(struct in_addr) > ipt->ipt_len)
- 					goto bad;
  				ipt->ipt_ptr += sizeof(struct in_addr);
--- 645,646 ----
***************
*** 652,654 ****
  			ntime = iptime();
! 			bcopy((caddr_t)&ntime, (caddr_t)sin, sizeof(n_time));
  			ipt->ipt_ptr += sizeof(n_time);
--- 652,655 ----
  			ntime = iptime();
! 			bcopy((caddr_t)&ntime, (caddr_t)cp + ipt->ipt_ptr - 1,
! 			    sizeof(n_time));
  			ipt->ipt_ptr += sizeof(n_time);
***************
*** 731,733 ****
  		return ((struct mbuf *)0);
! 	m = m_get(M_WAIT, MT_SOOPTS);
  	m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1;
--- 732,736 ----
  		return ((struct mbuf *)0);
! 	m = m_get(M_DONTWAIT, MT_SOOPTS);
! 	if (m == 0)
! 		return ((struct mbuf *)0);
  	m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1;
***************
*** 841,843 ****
  	}
! 	if (ip->ip_ttl < IPTTLDEC) {
  		type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS;
--- 844,846 ----
  	}
! 	if (ip->ip_ttl <= IPTTLDEC) {
  		type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS;
***************
*** 870,873 ****
--- 873,881 ----
  	 * and if packet was not source routed (or has any options).
+ 	 * Also, don't send redirect if forwarding using a default route
+ 	 * or a route modfied by a redirect.
  	 */
+ #define	satosin(sa)	((struct sockaddr_in *)(sa))
  	if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp &&
+ 	    (ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
+ 	    satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 &&
  	    ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) {
***************
*** 874,876 ****
  		struct in_ifaddr *ia;
- 		extern struct in_ifaddr *ifptoia();
  		u_long src = ntohl(ip->ip_src.s_addr);
--- 882,883 ----

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 17:12:06 EDT
From:      lekash@ORVILLE.ARPA (John Lekashman)
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

One of the two unused bits in the type of service field.  I vote
for the end bit.  This has something to do with the class
of service experienced, rather than desired, but thats ok.  Maybe
the other bit can be set on ack's to indicate congestion
experienced on the packet(s) this is an ack for.  (After all, its
got to get back to the sender somehow.  reduced offered window
is one way, an explicit bit's another.)
					john

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 17:29:38 EDT
From:      GRAVES@MATHOM.CISCO.COM (Bill Graves)
To:        comp.protocols.tcp-ip
Subject:   cisco Systems customer service

Mail from cisco Systems' customers requesting information or reporting
problems may be addressed to customer-service@mathom.cisco.com.  
Alternatively, problems may be reported at (800)-553-24HR and orders
may be placed at (800)-248-NETS.  Note that the latter number may 
eventually mutate to (800)-553-NETS.  Normal business lines on a 
rotary are available at (415)-326-1941.


					Best regards,

					Bill Graves


					graves@mathom.cisco.com
-------

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 19:42:28 EDT
From:      jonab@CAM.UNISYS.COM (Jonathan P. Biggar)
To:        comp.protocols.tcp-ip
Subject:   Question about IP options

I am implementing IP in Ada and have several questions about IP options
that are not clearly answered in either RFC 791 or MIL-SPEC 1777:

1)  Are the record route and timestamp options modified by the source and
    destination systems, or are they only modified by gateways?

2)  When using either loose or strict source routing, does the next hop
    or the final destination go in the destination address field of the
    IP header?  For example, if I want to route from host A through B and
    C to D, is the destination address B with source route C and D, or
    is the destination address D with source route B and C?

3)  Is it legal to have both loose and strict source routing options in the
    same IP packet?  If so, how do you handle this case?

Jon Biggar
jonab@cam.unisys.com

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 19:47:58 EDT
From:      schoff@NIC.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP


    My remarks should be interpreted with respect to the DARPA context, where
    I have some idea of what TCP and other bangers might do with it (infer
    source quench). Yes, is is true that the receiver, not the transmitter,
    sees the bit; however, our experience has been that the resources being
    starved are usually the buffer pool, which means the bit would probably be
    set on either direction at substantially the same frequency. It works
    either way, since either or both the transmitter or receiver can crank
    back the window size.

Are you then suggesting a "future DOD INTERNET gateway" should implement
this as an option and upon determining "congestion" set the bit for
the receiver and source quench the transmitter?

Still in the DOD context do you feel that a single queued datagram
should set the bit?  With our gateways living on the LAN/WAN interface
and the current state of our implementations wouldn't the bit always
end up being set?  (And therefore useless to us as a signpost?)

Marty

PS:  To further the state of the art of Mills'isms: philosophically
	if I'm in the swamp with my loaded double barrel shotgun, I'm
	probably not going to call for help until I see the THIRD
	alligator.  DEC seems to be pushing for the sighting of
	the first alligator.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 22:43:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

What we need is a high capacity, low cost hose to hose  protocol...

Vint

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1987 22:43-EDT
From:      CERF@A.ISI.EDU
To:        schoff@NIC.NYSER.NET
Cc:        Mills@LOUIE.UDEL.EDU, iso@NRTC.NORTHROP.COM murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA
Subject:   Re: ISO8473 vs. IP
What we need is a high capacity, low cost hose to hose  protocol...

Vint
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 22:51:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

Andy,

Tony Lauck, DEC's chief protocol architect, or John Zornig, also at DEC,
could probably point you at anything not proprietary. I believe that
they've entered recommendations into the ISO forum in this area so the
concepts are probably quite open. I don't have John's or Tony's network
mailbox IDs readily handy (oh, for a good white pages!), but perhaps
someone on TCP-IP can help, or Tony or John may be reading these
messages.

Vint

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 1987 22:51-EDT
From:      CERF@A.ISI.EDU
To:        malis@CC5.BBN.COM
Cc:        tsuchiya@GATEWAY.MITRE.ORG, schoff@NIC.NYSER.NET hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK tcp-ip@SRI-NIC.ARPA
Subject:   Re: ISO8473 vs. IP
Andy,

Tony Lauck, DEC's chief protocol architect, or John Zornig, also at DEC,
could probably point you at anything not proprietary. I believe that
they've entered recommendations into the ISO forum in this area so the
concepts are probably quite open. I don't have John's or Tony's network
mailbox IDs readily handy (oh, for a good white pages!), but perhaps
someone on TCP-IP can help, or Tony or John may be reading these
messages.

Vint
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 23:00:40 EDT
From:      pozar@hoptoad.UUCP (Tim Pozar)
To:        comp.protocols.tcp-ip
Subject:   request for addition to mailing list


   I hope I am sending to the right slot.  I would like to be added to 
the mailing list.
              Tim

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 87 19:09:37 GMT
From:      super.upenn.edu!operations.dccs.upenn.edu!shaffer@RUTGERS.EDU  (Earl Shaffer)
To:        tcp-ip@sri-nic.arpa
Subject:   Advanced Computer Communication's Access Product for MVS
Does anyone have any first hand knowledge of the Access product
from ACC?  We are interested in anyone who has looked into using
it on their MVS system, or even better, someone who is now using it!

The following things are very important:

1) overall impressions
2) any special "site coding" done to modify the default env.
3) smtp experiences
4) interoperability problems

Thanks very much,




==============================================================================
Earl Shaffer - University of Pennsylvania - Data Communications Department
"Time was invented so that everything wouldn't happen at once." Steven Wright
==============================================================================
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Wed, 9-Sep-87 23:29:25 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  ISO8473 vs. IP

Marty,

I'm not sure a headlong leap on the DEC bit would be appropriate for
the existing IP gateway munchkins, but something like this has been
proposed to indicate "congestion experienced." The particular
method used to determine when gateway has too much kin to munch may
depend on the gateway queueing discipline, preemption policy and
whether the interfaces are blocking or not, etc. If I understand
the DEC bit, the bit is set on a packet that arrives for a queue
with at least one packet already queued. Now, from queueing theory,
we can compute for each level of traffic the probability that the
queue has n customers for each n. A clever end system can then work
this backwards to estimate (crudely!) the level of traffic when the
bit is set. It's a nice idea and should be tried in an experiment.
However, there are lots of other ideas that should be tried, too.

Dave

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 01:59:48 EDT
From:      bdale@winfree.UUCP (Bdale Garbee)
To:        rec.ham-radio.packet,comp.os.minix,comp.protocols.tcp-ip
Subject:   KA9Q TCP/IP bits via BBS

I am pleased to report that through the generosity of a local PC dealer,
my BBS is back online running a slightly damaged ST-238.  The KA9Q
TCP/IP package distribution of 870829.0 is now available there for those
of you without any other means of obtaining it.

As a reminder, the bbs can be reached at 303/593-0766, 300/1200/2400 baud,
and first time callers have sufficient privs to download the entire release.

Have fun!
-- 
Bdale Garbee, N3EUA		phone: 303/593-9828 h, 303/590-2868 w
uucp: {bellcore,crash,hp-lsd,ncc,pitt,usafa,vixie}!winfree!bdale
arpa: bdale%winfree.uucp@bellcore.com
fido: sysop of 128/19		packet: n3eua @ k0hoa, Colorado Springs

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 06:26:28 EDT
From:      swb@TCGOULD.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

LiXia has said that she believes the DEC congestion bit approach is
too simple for the real world.  Is she available for comment?
						Scott

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Sep 87 09:15:01 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        "Jonathan P. Biggar" <jonab@JOVE.CAM.UNISYS.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: Question about IP options

    ... not clearly answered in either RFC 791 or MIL-SPEC 1777:

     1)  Are the record route and timestamp options modified by the source and
         destination systems, or are they only modified by gateways?

A clear recommendation that hosts implement them would help.  You could make
use of the information provided by the source host such as 'which interface
was used to actually send the packet', and the destination host 'what time was
the packet received'.

     2)  When using either loose or strict source routing, does the next hop
         or the final destination go in the destination address field of the
         IP header?

Next hop.  A rationale for this choice, based on processing power needed, is
that a gateway does not have to look at the options unless the IP destination
address is the gateway.  Then you look for options, and, finding a source
route, send it back out again.

     3)  Is it legal to have both loose and strict source routing options in the
         same IP packet?  If so, how do you handle this case?

Legal?  Since it's not forbidden, I guess so.  What path would a host program
expect such a packet to trace?  How more useful is it than just one option?
Think what the gateway must do if both are present; process the first? do the
second if the first is counted out?  do the first and ignore the second?
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Sep 87 09:18:29 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        CERF@A.ISI.EDU
Cc:        malis@CC5.BBN.COM, tsuchiya@GATEWAY.MITRE.ORG, schoff@NIC.NYSER.NET, hagens%janeb.spool.wisc.edu@GREMLIN.NRTC.NORTHROP.COM, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: ISO8473 vs. IP
Vint,

Thanks much.  I just got hold of "A Timeout-Based Congestion
Control Scheme for Window Flow-Controlled Networks," by Raj Jain
of DEC (IEEE J. on Selected Areas in Communications, Vol. SAC-4,
no. 7, Oct. 86).  It discusses many of these issues, and suggests
an algorithm to adjust window sizes based upon congestion
indications, although it uses retransmission timeouts to provide
the congestion indication rather than a congestion bit in the
packet header.

Andy
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 09:30:12 EDT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about IP options


    ... not clearly answered in either RFC 791 or MIL-SPEC 1777:

     1)  Are the record route and timestamp options modified by the source and
         destination systems, or are they only modified by gateways?

A clear recommendation that hosts implement them would help.  You could make
use of the information provided by the source host such as 'which interface
was used to actually send the packet', and the destination host 'what time was
the packet received'.

     2)  When using either loose or strict source routing, does the next hop
         or the final destination go in the destination address field of the
         IP header?

Next hop.  A rationale for this choice, based on processing power needed, is
that a gateway does not have to look at the options unless the IP destination
address is the gateway.  Then you look for options, and, finding a source
route, send it back out again.

     3)  Is it legal to have both loose and strict source routing options in the
         same IP packet?  If so, how do you handle this case?

Legal?  Since it's not forbidden, I guess so.  What path would a host program
expect such a packet to trace?  How more useful is it than just one option?
Think what the gateway must do if both are present; process the first? do the
second if the first is counted out?  do the first and ignore the second?

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 09:47:36 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

Vint,

Thanks much.  I just got hold of "A Timeout-Based Congestion
Control Scheme for Window Flow-Controlled Networks," by Raj Jain
of DEC (IEEE J. on Selected Areas in Communications, Vol. SAC-4,
no. 7, Oct. 86).  It discusses many of these issues, and suggests
an algorithm to adjust window sizes based upon congestion
indications, although it uses retransmission timeouts to provide
the congestion indication rather than a congestion bit in the
packet header.

Andy

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 10:13:50 EDT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re: Advanced Computer Communication's Access Product for MVS

We have an ACC system running on our MVS system (3081D). It basically works
fine, and is very fast, although some of the speed impression may be caused
by the high speed of the 3081. We use UCLA mail to front-end smtp. That
causes minor problems as UCLA mail does not allow the full smtp address
syntax. Full-screen telnet to a VM system running KNET does not work.
Line-mode telnet works fine. FTP is very powerful in dealing with MVS files,
but requires the user to supply the MVS volume name, which is a pain. FTP
allows file transfer between any 2 computers, neither of which needs to
be the MVS system. This is useful, but requires the user to provide login
info for MVS twice if one of the systems is MVS.

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

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Sep 87 10:13:50 EDT
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Advanced Computer Communication's Access Product for MVS
We have an ACC system running on our MVS system (3081D). It basically works
fine, and is very fast, although some of the speed impression may be caused
by the high speed of the 3081. We use UCLA mail to front-end smtp. That
causes minor problems as UCLA mail does not allow the full smtp address
syntax. Full-screen telnet to a VM system running KNET does not work.
Line-mode telnet works fine. FTP is very powerful in dealing with MVS files,
but requires the user to supply the MVS volume name, which is a pain. FTP
allows file transfer between any 2 computers, neither of which needs to
be the MVS system. This is useful, but requires the user to provide login
info for MVS twice if one of the systems is MVS.

                                         Bob Dixon
                                         Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 10:32:08 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Multiple 331 password responses in FTP protocol

As one of the perpetrators of FTP--and, indeed, one of the primary
perpetrators of the PASS command: cf. RFC 491--it might be appropriate
for me to assure you that I do understand the necessity of periodic
password changes.  I even understood it in 1972/3, when I was perpetrating.
However, I neither understand nor stipulate that the abstract necessity
for accomplishing the action dictates a concrete necessity for so doing
under the explicit cognizance of FTP, to this day.  N.B., I said
"explicit"; that is, if a given Server wants to make the function
available via FTP and can come up with a syntax such that the User FTP
implementations "all" think it's just a normal password being sent
through them (say, use "\\\" as the separator, or some single character
that isn't licit in the Server's passwords, or any trick that avoids
there being a space in the line, since User FTPs shouldn't boggle
at the length of a password but might well be doing next-non-blank
parsing), there doesn't seem to be a (protocol) problem.  Unless, of
course, too many User FTPs don't implement my conviction that they
can't possibly assume they know the length of a password, but that's
a different problem....

Actually, I could side with an argument which held that User FTPs
"should" be sending along everything input to them from whatever
their local indications that a PASS comand is wanted are through to
whatever their local indications that the command/line is ended are,
if anybody wants to raise it.  But I think the issue which should
dominate is that a Server is within its "rights" to play games with
the interpretations of given variables' internal syntax as long as
the variables are sent correctly according to the protocol's gross
syntax, so the above-sketched trick should work regardless--
provided I'm not overlooking any contrary-to-our-design-intent
glitches which might have been introduced into the spec with regard
to limitations on the length of the password string.  If I have to,
I'll dig out the spec from my piling system later; for now, though,
I think I'll settle for casting my metaphorical vote in favor of
having the ACCESS/MVS (or however they spell it) Server FTP simply
treat the outdated password as the incorrect password that it
in essence is and include text in the appropriate error message
explaining what syntax they want used in a subsequent PASS command's
argument field to make things right.  After all, we wanted to make
FTP "usable by automata" at the outset, but we never were so fanatic
about it that we explicitly banned touching by human hands, as I recall.

cheers, map
-------

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1987 10:32:08 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        John Pershing <PERSHNG@IBM.COM>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Multiple 331 password responses in FTP protocol
As one of the perpetrators of FTP--and, indeed, one of the primary
perpetrators of the PASS command: cf. RFC 491--it might be appropriate
for me to assure you that I do understand the necessity of periodic
password changes.  I even understood it in 1972/3, when I was perpetrating.
However, I neither understand nor stipulate that the abstract necessity
for accomplishing the action dictates a concrete necessity for so doing
under the explicit cognizance of FTP, to this day.  N.B., I said
"explicit"; that is, if a given Server wants to make the function
available via FTP and can come up with a syntax such that the User FTP
implementations "all" think it's just a normal password being sent
through them (say, use "\\\" as the separator, or some single character
that isn't licit in the Server's passwords, or any trick that avoids
there being a space in the line, since User FTPs shouldn't boggle
at the length of a password but might well be doing next-non-blank
parsing), there doesn't seem to be a (protocol) problem.  Unless, of
course, too many User FTPs don't implement my conviction that they
can't possibly assume they know the length of a password, but that's
a different problem....

Actually, I could side with an argument which held that User FTPs
"should" be sending along everything input to them from whatever
their local indications that a PASS comand is wanted are through to
whatever their local indications that the command/line is ended are,
if anybody wants to raise it.  But I think the issue which should
dominate is that a Server is within its "rights" to play games with
the interpretations of given variables' internal syntax as long as
the variables are sent correctly according to the protocol's gross
syntax, so the above-sketched trick should work regardless--
provided I'm not overlooking any contrary-to-our-design-intent
glitches which might have been introduced into the spec with regard
to limitations on the length of the password string.  If I have to,
I'll dig out the spec from my piling system later; for now, though,
I think I'll settle for casting my metaphorical vote in favor of
having the ACCESS/MVS (or however they spell it) Server FTP simply
treat the outdated password as the incorrect password that it
in essence is and include text in the appropriate error message
explaining what syntax they want used in a subsequent PASS command's
argument field to make things right.  After all, we wanted to make
FTP "usable by automata" at the outset, but we never were so fanatic
about it that we explicitly banned touching by human hands, as I recall.

cheers, map
-------
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 10:38:37 EDT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Re:  Once More on FTP Password Expiration, Etc.

As another customer, I agree that FTP has no business worrying about expired
passwords. Unless I misunderstand what is going on.

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

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10 Sep 87 10:38:37 EDT
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  Once More on FTP Password Expiration, Etc.
As another customer, I agree that FTP has no business worrying about expired
passwords. Unless I misunderstand what is going on.

                                    Bob Dixon
                                    Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 11:16:29 EDT
From:      sia@canisius.UUCP (Stewart Alpert @ Ingram Software)
To:        comp.dcom.lans,comp.unix.xenix,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Public Domain TCP/IP software

Could anybody who knows of any public domain implementations of tcp/ip
please drop me a line.   thanks.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 11:31:41 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: ISO8473 vs. IP

My initial impulse was to respond to the call for a hose to hose
protocol with a private message saying "Nozzle yourself, Vinton: you
really shouldn't faucet like that."  Then I made the mistake of thinking
a bit about what hose to hose protocols would actually be like, and I
realized that there's a fairly powerful metaphor lurking there.  Think
about it: if you have two garden hoses, all you need is a suitably
threaded (presumably "female-female") adaptor, even if the threads on
each of the hoses "aren't standard".  The worst that would happen is that
you'd discover nobody made appropriate adaptors and it would be cheaper
to buy a longer hose (which, with any luck at all, was thread compatible
with the faucet) than to have someone fabricate the special widget.
(Please recall I've always spoken well of physical standards, b/t/w.)
But if you want to couple a fire hose and a garden hose, you'd need to
call in a fluid dynamicist to calculate how long the taper had to be so
as not to lead to bursting the garden hose and then go in for some
serious metalwork to get the adaptor built.  (Not a job for the
village smithy [they shoe horses, don't they?], I'd imagine.)
And if you wanted to go beyond the conventional Gateway problem,
consider the Translating/Mapping Gateway analogue, where some of
the time what you need is to couple a hose designed for carrying
liquid oxygen with a hose designed for carrying water to your
lawn: by the time you put enough heat into the adaptor so the
garden hose doesn't shatter from the cold, you've probably lost
sight of the fact that your lawn doesn't really need oxygen in
the first place.

Other permutations on the theme are doubtless available, and even
relevant, but can safely be left as an exercise....

cheers, map

P.S.  At the risk of violating tradition and linking this back up
to the question which started it all, one way of viewing the
difference between ISO IP and ARPANET IP is that each is supposed
to be threaded to a different faucet.  But, then, another way of
viewing the difference is to think about the news item I heard
over the weekend, where some builder in one of the cities the Pope
is visiting had donated several of his houses for the lodging
of the papal entourage, since he believed they'd be worth more later
because he had heard that the Pope blessed every house he entered
(not clear that the Pope would enter every house, of course,
but then I've never claimed to be up on ad man logic):
so to change the metaphor from the lawn to the house, they do
have slightly different floor plans, they both serve the same
fundamental purpose of being boxes to stay out of the weather
in, they're in the same neighborhood and all, but this one's
gonna cost ya $25,000 more because It's Been Papally Blessed!

-------

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1987 11:31:41 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        CERF@A.ISI.EDU
Cc:        schoff@NIC.NYSER.NET, Mills@LOUIE.UDEL.EDU, iso@NRTC.NORTHROP.COM, murayama@CS.UCL.AC.UK, tcp-ip@SRI-NIC.ARPA
Subject:   Re: ISO8473 vs. IP
My initial impulse was to respond to the call for a hose to hose
protocol with a private message saying "Nozzle yourself, Vinton: you
really shouldn't faucet like that."  Then I made the mistake of thinking
a bit about what hose to hose protocols would actually be like, and I
realized that there's a fairly powerful metaphor lurking there.  Think
about it: if you have two garden hoses, all you need is a suitably
threaded (presumably "female-female") adaptor, even if the threads on
each of the hoses "aren't standard".  The worst that would happen is that
you'd discover nobody made appropriate adaptors and it would be cheaper
to buy a longer hose (which, with any luck at all, was thread compatible
with the faucet) than to have someone fabricate the special widget.
(Please recall I've always spoken well of physical standards, b/t/w.)
But if you want to couple a fire hose and a garden hose, you'd need to
call in a fluid dynamicist to calculate how long the taper had to be so
as not to lead to bursting the garden hose and then go in for some
serious metalwork to get the adaptor built.  (Not a job for the
village smithy [they shoe horses, don't they?], I'd imagine.)
And if you wanted to go beyond the conventional Gateway problem,
consider the Translating/Mapping Gateway analogue, where some of
the time what you need is to couple a hose designed for carrying
liquid oxygen with a hose designed for carrying water to your
lawn: by the time you put enough heat into the adaptor so the
garden hose doesn't shatter from the cold, you've probably lost
sight of the fact that your lawn doesn't really need oxygen in
the first place.

Other permutations on the theme are doubtless available, and even
relevant, but can safely be left as an exercise....

cheers, map

P.S.  At the risk of violating tradition and linking this back up
to the question which started it all, one way of viewing the
difference between ISO IP and ARPANET IP is that each is supposed
to be threaded to a different faucet.  But, then, another way of
viewing the difference is to think about the news item I heard
over the weekend, where some builder in one of the cities the Pope
is visiting had donated several of his houses for the lodging
of the papal entourage, since he believed they'd be worth more later
because he had heard that the Pope blessed every house he entered
(not clear that the Pope would enter every house, of course,
but then I've never claimed to be up on ad man logic):
so to change the metaphor from the lawn to the house, they do
have slightly different floor plans, they both serve the same
fundamental purpose of being boxes to stay out of the weather
in, they're in the same neighborhood and all, but this one's
gonna cost ya $25,000 more because It's Been Papally Blessed!

-------
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 12:53:06 EDT
From:      gillies@P.CS.UIUC.EDU (Don Gillies)
To:        comp.protocols.tcp-ip
Subject:   DL removal

please take me off your distribution list.  Thanks.  Don
.,

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 87 13:06:28 GMT
From:      caip.rutgers.edu!keilp@RUTGERS.EDU  (Carol Keilp)
To:        tcp-ip@sri-nic.arpa
Subject:   remove from mailing list

	Please remove me from the mailing list.  Thank you.

					Keilp@caip.rutgers.edu
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 17:25:26 EDT
From:      rdt@houxv.UUCP
To:        comp.protocols.tcp-ip
Subject:   need x.25 multibus2 board recommendation


I need a recommendation for selecting a
multibus2 X.25 card with onboard firmware
to do either tcpip and/or x.25 plp processing
(as in BX.25).

Could anyone give me the benifit of their 
experience? Please include the name of the 
manufacturer, model, conformance with standards
and the difficulty of porting client packages.

I am only familiar with the att 3b/isc card 
which is not designed for a multibus2 form factor.

Richard Trauben

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Thu, 10-Sep-87 19:39:48 EDT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   [VWHITE@NSWC-G.ARPA:]

I'm forwarding this to this list because I think most of the answers
can come from it.  These people are building themselves a marvelous
environment and are looking for the superglue.  Of course, not one
brand of superglue exists to solve it all, but I think the components
are present here.  

Each one contribute one idea and we can build them a viable internet.

Thanks,

Dan

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

Return-Path: <@wiscvm.wisc.edu:BIG-LAN@SUVM.BITNET>
Received: FROM WISCVM.WISC.EDU BY USC-ISIA.ARPA WITH TCP ; 10 Sep 87 18:39:54 EDT
Received: from SUVM.BITNET by wiscvm.wisc.edu ; Thu, 10 Sep 87 11:39:07 CDT
Received: by SUVM (Mailer X1.25) id 5087; Thu, 10 Sep 87 11:19:29 LCL
Date:         Thu, 10 Sep 87 09:48:19 edt
Reply-To:     Campus-Size LAN Discussion Group <BIG-LAN%SUVM.BITNET@wiscvm.wisc.edu>
Sender:       Campus-Size LAN Discussion Group <BIG-LAN%SUVM.BITNET@wiscvm.wisc.edu>
Comments:     Resent-Date: Thu, 10 Sep 1987 11:16:00 LCL
Comments:     Resent-From: John M. Wobus <JMWOBUS@SUVM>
X-To:         Campus LAN Discussion Group <BIG-LAN@SUVM>,
              BIG-LAN%SUVM.BITNET@WISCVM.WISC.EDU
From:         VWHITE@NSWC-G.ARPA
To:           "Kevin M. Leahy" <LEAHYKM@A.ISI.EDU>,
              Dan Lynch <LYNCH@A.ISI.EDU>

Request for Information

10 September 1987

We are currently investigating methods of providing networked
services to PC users at a large government
installation and would appreciate any leads anyone could give us.

BACKGROUND:

The user community may eventually number 2000-3000 persons using
IBM compatible PCs primarily for word processing, spreadsheet,
and database applications (WordPerfect, Lotus, and DBASE).  We
must allow these users to share files, printers, and other
resources and to exchange mail with one another and across the
MILNET.  These users are located in multiple buildings at two
geographic sites separated by over 50 miles.

We have a large base of installed
minicomputers (VAXen, CCI Power 6, Pyramid, Sun) which run Unix
(4.1c, 4.2, Ultrix, Pyramid's OSX) and which we want to reuse to
the greatest extent possible as servers for the PCs.  These
minicomputers are connected via an 802.3 baseband network using
the DoD TCP/IP protocols; the two geographic sites are connected
via a T1 microwave link.

Required capabilities include:

     Transparent file service.  The user should be able to access
     the server's disk as if it were a hard drive on on the
     workstation.  Telnet and ftp-type applications are welcome,
     but alone are not sufficient.

     Transparent print service.   At the least, the user should
     be able to send documents from his PC to a shared printer
     with a simple command.  It would be nice if all his
     applications (WordPerfect, DBase) could do the same thing.

     A mail service which receives and stores the user's mail
     even if the PC is not online, allows the user to read his
     mail from his PC, and uses or can interface to smtp mail.

Acceptable solutions must adhere to IEEE 802.3 and must use the
DoD TCP/IP protocols or provide gateway services to a TCP/IP
network.   They don't have to work with Macintoshes, but that
would be an added plus.

We have looked or are now looking at Novell NetWare, the IBM PC
Network, 3Com 3+Share, Sun NFS, Locus PC Interface, Syntax
SMBserver, and several public domain packages (CMU PCTCP, CMU
Repository Mailer, Phil Karn's KA9Q PCTCP).

REQUEST FOR INFO:

Has anybody out there solved a similar problem?  If so, what did
you use and how would you rate your solution?

Does anybody have a lead on a product not in the list above which
would meet all or most of our criteria?

How important is NetBIOS compatibility?  From what we've seen,
nobody as yet is adhering to the RFCs from the NetBIOS over TCP
Working Group.  We are also concerned about the advent of OS/2
and the LAN Manager and what that will mean to NetBIOS.  Is
NetBIOS an emerging/existing standard for PC networking, or will
it go away?

Thanks for any help you can offer.

vwhite@nswc-g.arpa

Vicky White
Code K33
NSWC
Dahlgren, VA  22448
(703) 663-7745

-------

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1987 19:39:48 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        lynch@A.ISI.EDU, vwhite@NSWC-G.ARPA
Subject:   [VWHITE@NSWC-G.ARPA:]
I'm forwarding this to this list because I think most of the answers
can come from it.  These people are building themselves a marvelous
environment and are looking for the superglue.  Of course, not one
brand of superglue exists to solve it all, but I think the components
are present here.  

Each one contribute one idea and we can build them a viable internet.

Thanks,

Dan

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

Return-Path: <@wiscvm.wisc.edu:BIG-LAN@SUVM.BITNET>
Received: FROM WISCVM.WISC.EDU BY USC-ISIA.ARPA WITH TCP ; 10 Sep 87 18:39:54 EDT
Received: from SUVM.BITNET by wiscvm.wisc.edu ; Thu, 10 Sep 87 11:39:07 CDT
Received: by SUVM (Mailer X1.25) id 5087; Thu, 10 Sep 87 11:19:29 LCL
Date:         Thu, 10 Sep 87 09:48:19 edt
Reply-To:     Campus-Size LAN Discussion Group <BIG-LAN%SUVM.BITNET@wiscvm.wisc.edu>
Sender:       Campus-Size LAN Discussion Group <BIG-LAN%SUVM.BITNET@wiscvm.wisc.edu>
Comments:     Resent-Date: Thu, 10 Sep 1987 11:16:00 LCL
Comments:     Resent-From: John M. Wobus <JMWOBUS@SUVM>
X-To:         Campus LAN Discussion Group <BIG-LAN@SUVM>,
              BIG-LAN%SUVM.BITNET@WISCVM.WISC.EDU
From:         VWHITE@NSWC-G.ARPA
To:           "Kevin M. Leahy" <LEAHYKM@A.ISI.EDU>,
              Dan Lynch <LYNCH@A.ISI.EDU>

Request for Information

10 September 1987

We are currently investigating methods of providing networked
services to PC users at a large government
installation and would appreciate any leads anyone could give us.

BACKGROUND:

The user community may eventually number 2000-3000 persons using
IBM compatible PCs primarily for word processing, spreadsheet,
and database applications (WordPerfect, Lotus, and DBASE).  We
must allow these users to share files, printers, and other
resources and to exchange mail with one another and across the
MILNET.  These users are located in multiple buildings at two
geographic sites separated by over 50 miles.

We have a large base of installed
minicomputers (VAXen, CCI Power 6, Pyramid, Sun) which run Unix
(4.1c, 4.2, Ultrix, Pyramid's OSX) and which we want to reuse to
the greatest extent possible as servers for the PCs.  These
minicomputers are connected via an 802.3 baseband network using
the DoD TCP/IP protocols; the two geographic sites are connected
via a T1 microwave link.

Required capabilities include:

     Transparent file service.  The user should be able to access
     the server's disk as if it were a hard drive on on the
     workstation.  Telnet and ftp-type applications are welcome,
     but alone are not sufficient.

     Transparent print service.   At the least, the user should
     be able to send documents from his PC to a shared printer
     with a simple command.  It would be nice if all his
     applications (WordPerfect, DBase) could do the same thing.

     A mail service which receives and stores the user's mail
     even if the PC is not online, allows the user to read his
     mail from his PC, and uses or can interface to smtp mail.

Acceptable solutions must adhere to IEEE 802.3 and must use the
DoD TCP/IP protocols or provide gateway services to a TCP/IP
network.   They don't have to work with Macintoshes, but that
would be an added plus.

We have looked or are now looking at Novell NetWare, the IBM PC
Network, 3Com 3+Share, Sun NFS, Locus PC Interface, Syntax
SMBserver, and several public domain packages (CMU PCTCP, CMU
Repository Mailer, Phil Karn's KA9Q PCTCP).

REQUEST FOR INFO:

Has anybody out there solved a similar problem?  If so, what did
you use and how would you rate your solution?

Does anybody have a lead on a product not in the list above which
would meet all or most of our criteria?

How important is NetBIOS compatibility?  From what we've seen,
nobody as yet is adhering to the RFCs from the NetBIOS over TCP
Working Group.  We are also concerned about the advent of OS/2
and the LAN Manager and what that will mean to NetBIOS.  Is
NetBIOS an emerging/existing standard for PC networking, or will
it go away?

Thanks for any help you can offer.

vwhite@nswc-g.arpa

Vicky White
Code K33
NSWC
Dahlgren, VA  22448
(703) 663-7745

-------
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 87 03:35:48 GMT
From:      nysernic!itsgw!steinmetz!uunet!quick!srg@RUTGERS.EDU  (Spencer Garrett)
To:        tcp-ip@sri-nic.arpa
Subject:   Assigning ethernet numbers
Can anyone tell me where to go to get a block of ethernet hardware addresses
for my company?  We're going to be making terminal servers, so we do need
to assign these numbers to our products.  Thanks.
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Sep-87 10:13:47 EDT
From:      mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  [VWHITE@NSWC-G.ARPA:]

Vicky, Dan, et. al.:

If you can get access to the Request For Proposal (RFP) and the vendor propos-
als for LONS, RAPIDE, UTAIN/MAIS, and ULANA; you may find some of the answers
to the questions that you have raised.  

LONS and its predecessor LONEX (Local Office Network Experiment) are probably
more in line with what you want to do.  LONEX has been operational since the
early 80's at Rome Air Development Center (RADC), Griffiss AFB and has links
to and facilities at Hanscom Field and Wright-Patterson AFB.  This message is
being generated from home on a Tandy 2000 linked to the LONEX development and
maintenance network at EATON IMSD in Westlake Village, CA which is also linked
into RADC-LONEX.ARPA.

LONEX was originally designed for a broadband with dedicated links to Hanscom
and Wright-Patterson; however, the broadband has been replaced with Ethernet
and the dedicated links are being replaced by the MILNET.  The original plan
was to support a large number of users using VT100 or VT100 compatible term-
inals; however, that is also changing with many of the organisations using
LONEX replacing them with PC's.

PC's are not as fully integrated as you would like and generally use terminal
emulation packages to interface with the network.  I, personally, use the
Softronic's SoftermPC package on which I have implemented a seamless disk
capability so that disks on the network look like local hard disks to my PC.
I can tell you from experience it can be painful--applications developed for
MS-DOS choke if you have to use UNIX pathnames to get to your data.  For
some silly reason they attempt to parse switches whenever they see a "/".

Anyway, the LONEX system runs on anything that can run on any processor that
supports 2.9bsd or 4.3bsd.  It goes "boom" on System Vanilla.  It supports
several of the more popular spreadsheet programs and databases and depending
on the size of your spreadsheets moves the processing to more appropriate
machines.  Users in essence always execute from their home processor regard-
less of where they may be and for the most part its transparent to the user.
If you normally work at Hanscom but are temporarily at Wright Patterson, you
may notice some latency. (This feature is probably the biggest reason why
there hasn't been a stronger hue and cry for more fully integrating PCs into
the system.  As long as you can get to a TAC, you can work on your reports
from anywhere in the world.  You don't have to lug the PC along and if you're
forced to fly commercial, you avoid the hassle at customs where they try to
extract the import duties on your PC).

Enough this.  Request a tour and briefing from RADC to determine if it is
useful and to find the pitfalls.

Merton Campbell Crockett		mcc@etn-wlv.eaton.com
AN/GYQ-21(V) Program			mcc%lonex@etn-wlv.eaton.com
EATON Information Management Systems
31717 La Tienda Drive, Box 5009
Westlake Village, CA 91539

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Sep-87 12:50:00 EDT
From:      WANCHO@SIMTEL20.ARPA
To:        comp.protocols.tcp-ip
Subject:   Can of worms...

The following message opens up an extremely touchy subject on this
forum.  I am bringing it up here because I am looking for a relatively
"easy-to-implement" alternate *technical* solution to the problem
which will work in the present TCP/IP environment and in the future
ISO environment.

The Communications Services Industrial Fund (CSIF) of DCA has been
tasked to implement a usage-sensitive chargeback only for hosts
connected to the MILNET backbone in the very near future.  The
problem is that the method chosen is probably the easiest to implement
in that only PSN code is involved and no host code changes are
required.  However, it is the least equitable: simply charge each host
for all the traffic it originates and all traffic in both directions
from a TAC port.  The host is also charged for connect time on dialup
TAC ports.  No such chargeback is being planned for ARPANET hosts.

When this scheme is in place, we will probably have to drop our
popular services, such as hosting large mailing lists, ANONYMOUS FTP
access to our very large public domain collections, and TAC access by
our regular users.  With no reason to remain directly connected to the
MILNET backbone, we will then move our connection to the other side of
our gateway to further reduce costs.  Given the cost figures based on
our current traffic, (heresy follows:) it might even be more
economical to extend our own net using high-speed dialup ala USENET,
BITNET, etc...

However, it might be possible to create a fair, and therefore,
tolerable, chargeback algorithm.  It requires a further extension to
the AHIP-E protocol and possibly only "trivial" changes to certain
host software.  To make things equitable, charge the host for all
traffic it generates in BOTH directions of a connection it originates.
However, (here's the hard part) allow for "collect call" connections
to be made and not accumulate charges until the remote host has
accepted the call.  It seems that part of this mechanism already
exists for MILNET TACs in that all traffic is to be charged to each
connected host on a connection by connection basis.

This alternative would seem to take care of the large mailing list
problem in that those messages would be sent collect.  ANONYMOUS FTP
connections would be charged to the calling host.  That leaves TAC
access.  It would be more economical to open up and add more
direct-dial ports to our systems, or put TACs on the other side of
gateway hosts, than allow TAC dialup access from a MILNET TAC port.

OK, given all that, the only real questions I have for this list are:
is it possible to extend the AHIP-E protocol to allow for a collect
call to be passed to the remote host, and what would it take to get it
implemented and tested in the next year or so?

--Frank

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Sep-87 15:14:00 EDT
From:      jain@erlang.DEC.COM (Raj Jain, LKG 1-2/A19 DTN: 226-7642)
To:        comp.protocols.tcp-ip
Subject:   ISO 8473 vs IP (Congestion experienced bit)

We have a hot-off-the-press  DEC  Technical  Report  DEC-TR-506  which
summarizes our work on congestion avoidance and explains the merits of
the 'congestion experienced' bit in ISO 8473.

Title:    CONGESTION   AVOIDANCE   IN   COMPUTER   NETWORKS   WITH   A
          CONNECTIONLESS NETWORK LAYER
Authors:  Raj Jain, K.  K.  Ramakrishnan, Dah-Ming Chiu
          Digital Equipment Corp.
          Littleton, MA 01460
Date:     August 1987.

If you would  like  a  copy  of the report mailed to you, please send me your
U.S.    Mail   address.    My   network   address   on   ARPAnet    is
Jain%Erlang.dec@decwrl.dec.com

Also, we would presenting the scheme in detail at the next NBS/OSI implementors
workshop in october.

-Raj

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Sep-87 15:27:16 EDT
From:      vik@bobkat.UUCP (Vik Ram Sohal)
To:        comp.dcom.lans,comp.unix.xenix,comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: Public Domain TCP/IP software


	I would appreciate any info on getting TCP/IP source as well!!!

                                   Vik

End Of Line...

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Sep-87 15:40:15 EDT
From:      PERRY@VAX.DARPA.MIL (Dennis G. Perry)
To:        comp.protocols.tcp-ip
Subject:   Re:  [VWHITE@NSWC-G.ARPA:]

My understanding from the folks at RADC is the LONEX is going away, an
no further enhancements are allowed to the system.  I wonder what
they are moving to?

dennis
-------

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 11-Sep-87 22:13:07 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   EGP updates over the top

Folks,

EGP jumbograms observed here have topped out above the ARPANET MTU of 1006+
octets, which means they will be fragmented. I'm sure the many Unix system
wizards will be casting spells on the reassembly buffer size and crank that
up accordingly. For the fuzzball system warlocks, be advised its EGP does
now reassemble updates. Fixes will be distributed over the weekend. The
reason I dropped this message on the full list is an interesting observation
that the LSI-11 core gateways set the don't-fragment bit on updates to
match the same bit on received packets. Thus, if your EGP code sets this bit
in the IP header, the update that comes back will self-destruct while coming
back. Obviously, the don't-fragment bit should not be set.

having flattened head while learning the above nugget today, I would like to
invite our BBN comrades to expand upon the theme.

Dave

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 00:54:04 EDT
From:      rms@columbia-pdn (Ron Stoughton acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   ACC Customer Service

Howard,

ACC Customer Service can be reached at service@acc-sb-unix.arpa.
If that doesn't work, please let me know.

Ron Stoughton
rms@acc-sb-unix.arpa

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 10:19:59 EDT
From:      zwang@CS.UCL.AC.UK (Zheng Wang)
To:        comp.protocols.tcp-ip
Subject:   IP Options

What will happen if a packet with a source route option goes through 
a unix 4.2 gateway ?  Will the gateway strip the option out after
updating ?

Zheng.
zwang@uk.ac.ucl.cc

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 17:46:24 EDT
From:      mcc@ETN-WLV.EATON.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  [VWHITE@NSWC-G.ARPA:]

Dennis:

The operational system to replace the experimental system is LONS and that
is the official line; however, I think there is a great deal of resistance
at the LONEX user level.  I'm not sure what the final configuration of LONS
is going to be; however, one component seems to be a single VAX system that
provides the same user services provided by the array of PDP11/44, PDP11/70,
and VAX systems used ithe LONEX system.

While LONS is the "official" system, I doubt that LONEX will disappear in
the near future.  You have a large group of users that are familiar with the
facilities of LONEX.  Experience at EATON indicates that it is very easy to
move secretaries whose primary use of the system to prepare letters and mem-
orandae from one system to another but it is quite another to move people
that use a system for preparing technical documentation and proposals part-
icularly if these documents are going to be modified and reproduced over a
period of time.  In essence, the "old" system will not be replaced until a
catastrophic event occurs--because no one wants to spend the money to con-
vert all the data from the formats required by the "old" system to that re-
quited by the "new" system.

Merton Campbell Crockett

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 18:01:18 EDT
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  [VWHITE@NSWC-G.ARPA:]

Merton, I had heard the LONEX was going to go away because I had
asked the RADC people to fix lonex so that, at least on there system,
mail send to an individual would include who is on the 'cc' line.  I
wanted to make certain that eveyone involved in the discussion was
being copied.  Lonex apparently cannot do that.  It sends out mail
with blank cc lines and I do not know who else got the message, nor
can I answer to everyone.  If lonex is going to be around, this would
be a good thing to fix.  The RADC peole say that this would be a major
change to the guts of the system and will not be done.

dennis
-------

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 18:59:10 EDT
From:      mcc@ETN-WLV.EATON.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  [VWHITE@NSWC-G.ARPA:]

Dennis:

I'm a little confused.  The LONEX Mail Facility does indicate who the cc:
recipients are on each message when you display the message.  Of course,
there may be some slight differences between the RADC and EATON versions.
A definitive answer can be gotten from Steven M Schultz (sms@etn-wlv.eaton.com)
currently on location (sms@radc-lonex.arpa) about any differences.

Merton Campbell Crockett

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12 Sep 87 15:06:00 GMT-0:00
From:      Zheng Wang <zwang@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   IP Options
What will happen if a packet with a source route option goes through 
a unix 4.2 gateway ?  Will the gateway strip the option out after
updating ?

Zheng.
zwang@uk.ac.ucl.cc
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 19:09:01 EDT
From:      PERRY@VAX.DARPA.MIL.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  [VWHITE@NSWC-G.ARPA:]

Merton, we made a test, and at least the RADC lonex does not include
any names on the cc line.  It does indeed send copies of the mail
to those indicated on the cc lines of the lonex user who generates
the mail, but the mail that is sent out does not include that 
information.  Instead, lonex generates a mail message to everyone
as if they were the only one getting the message.

dennis
-------

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Sat, 12-Sep-87 21:02:11 EDT
From:      vjs@sgi.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: IP options

In article <8709092006.AA09597@okeeffe.Berkeley.EDU>, karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes:

> + 	 * Also, don't send redirect if forwarding using a default route
> + 	 * or a route modfied by a redirect.
>   	 */
> + #define	satosin(sa)	((struct sockaddr_in *)(sa))
>   	if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp &&
> + 	    (ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
> + 	    satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 &&
>   	    ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) {

I have been faithfully following the 4.3 fixes posted here and in the
'official' news group.  However, RTF_MODIFIED does not seem to be
defined in my source.  If I have missed something, would someone 
please give me a pointer to it?  Else, might there be fixes pending to
#define it and to set it?

Thank you
Vernon Schryver
Silicon Graphics, Inc
vjs@sgi.com   or   {decwrl,pyramid,sun,ucbvax,allegra}!sgi!vjs

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Sep-87 01:01:11 EDT
From:      SATZ@MATHOM.CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   DDN X.25 mapping

What should a DDN X.25 interface do about mapping to X.121 addresses
when connected to a class B or C network? I remember seeing something
about this before somewhere. If I remember correctly the C and D octets
should be used for the imp and host octets for class B addresses. For
class C, the upper four bits and the lower four bits of octet D should
be used for the imp and host octets. Is this correct?
-------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Sep-87 15:48:49 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   T1 and distant IP networks

We have:

	1) two IP ethernets separated by 120 miles
	2) a T1 line between the two.

I would like an IP (or ethernet if IP wasn't readly available)
repeater or bridge or gateway so the two networks can talk.  Anybody
have any information about off the shelf products that could be used.
Cost estimates would be greatly appreciated.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Sep-87 19:17:14 EDT
From:      ROODE@BIONET-20.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   EMail User Agents

mkhaw@teknowledge cites several specifics of Unix MM-32
which I agree are points which could stand improvement
or clarification.  Many mail programs seem to keep mail in
their own format so this concern is common.

I wasn't alluding to incompatibility with Unix or similarity
to TOPS-20 as the basis for suggesting taking a look at MM-32.
Specifically, the features in MM-32 that I think recommend
it as an improvement over other Unix mail agents are:

	a) a ? feature for all commands and command options

	The user need not know the options in advance to select
	them; nor need he depart from command interaction
	to consult separate help text for the command.

	b) a distinct top level; i.e. the individual mail commands are
	not merged in with the Unix shell commands.  I think this is a
	plus for user understanding.

	c) a mode change between the top level of the mail program and
	the level under which a particular message is being processed.
	Again, I think clarity is enhanced when distinctions are made
	as to context of user interaction.

	d) profile capability including the ability to suppress
	display of selected headers when they appear in messages

	e) flexible specification of message sequences, i.e. to
	perform an action on sequences specified by compound
	conditions such as 'from joe' and 'since 15 May 1987'; the
	mere ability to identify messages to include in a sequence by
	one attribute of the messages intended let alone ability to
	compound them

	f) capability to search with messages with a certain text
	string in the message body

Characteristics which I would find highly valuable
but which MM-32 does not have are as follows:

	A mode when reading messages to allow display
	of only the first n lines of message body.  At that
	point a one keystroke selection should allow for
	continuation; otherwise all other message disposition
	options ought to be valid.

	Ability to specify automatic disposition with optional
	confirmation, i.e.  "when reading messages addressed to
	'SPECIAL-COMMITTEE' by default save them in file
	'SPECIAL-COMMITTEE.FILE'"; "when reading messages from Joe, by
	default place them in file Joe.mail but confirm first"; when
	reading messages addressed to 'announcements' delete them
	after reading; when reading all other messages not addressed
	directly to myself, place them in file 'LIST.MAIL'"

I think the last set of mail processing capabilities is very
simple yet provide a very powerful tool for managing a history
of online EMAIL.
-------

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Sun, 13-Sep-87 19:26:30 EDT
From:      ron@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  DDN X.25 mapping

There is no standard for the IMP to Class B and C addresses that I
know of.  HOWEVER, both BRL and the Canadian version of MILNET use
the C octet for host number and the D octet for imp number (essentially
sliding the HOST byte right one byte).

-Ron

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1987 06:38:49 CDT
From:      SITT@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        sitt@GUNTER-ADAM.ARPA
Subject:   Romove From Mailing List
Please remove this account from the mailing list.

sitt"at"gunter-adam.arpa

-------
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 07:17:29 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  T1 and distant IP networks

There are a couple of ways to go.  Since you are already IP
oriented, I'd suggest IP bridges.  We use ones from CISCO
systems to bridge several T1 lines to Ethernets here.  Proteon
makes a similar box.  Expect them to cost you $7000-10,000 an
end.  Ungermann/Bass makes a IP bridge (which can also be an
Ethernet bridge (same hardware)) which is probably a little
cheaper but their IP isn't quite as mature as the others.  We
currently run the UB box in ethernet bridge mode (I don't know
how much it cost, I didn't buy it).

-Ron

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 07:38:49 EDT
From:      SITT@GUNTER-ADAM.ARPA
To:        comp.protocols.tcp-ip
Subject:   Romove From Mailing List

Please remove this account from the mailing list.

sitt"at"gunter-adam.arpa

-------

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Sep 87 10:47:48 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        Greg Satz <SATZ@MATHOM.CISCO.COM>, Ron Natalie <ron@TOPAZ.RUTGERS.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM, hinden@CC5.BBN.COM
Subject:   Re: DDN X.25 mapping
Greg,

Ron is correct, RFC 796 only discusses the Class A mapping
between IP addresses and ARPANET/MILNET addresses.  He described
the generally accepted mapping for Class B IP addresses, using
the third octet for the host number and the fourth octet for the
PSN (IMP) number.

PLEASE remember to follow the algorithm in section A-5 of the DDN
X.25 Host Interface Spec (BBN Report 5476, in the DDN Protocol
Handbook, Vol 1, as section 6.6) for deriving the X.25 address,
so that logical addressing will work correctly.  All you have to
do is substitute the third octet of a Class B IP address for the
2nd octet of a Class A IP address as discussed in the algorithm.
This is on pages A-9 and A-10 of the spec (pages 1-497 and 1-498
of the Protocol Handbook).

There is no generally accepted standard for Class C addresses,
nor am I aware of any Class C PSN-based networks.  Certainly, 4
bits for each of the host and PSN numbers would work - it depends
on the number of PSNs in the network and the maximum number of
hosts on each PSN.  This mapping should probably be customized on
a network-by-network basis.  For consistency with the Class A and
Class B mappings, the host number bits should be in the more
significant bits of the 4th octet.

Regards,
Andy Malis
PSN Development
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Sep 87 12:16:41 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        WANCHO@SIMTEL20.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA, malis@CC5.BBN.COM, seisner@CC5.BBN.COM
Subject:   Re: Can of worms...
Frank,

As a host administrator myself (as well as a PSN code developer),
I understand your concern about the costs generated by the
usage-sensitive chargeback. 

However, I can find several problems with your proposed "collect
call" connections: 

1. Even though AHIP traffic is sent by the network using internal
   connections, the AHIP host interface is not explicitly
   connection-based.  There are two alternative ways a host could
   identify "collect calls": 

   a. Add explicit connection-based mechanisms to AHIP.  This
      would effectively turn AHIP into a variant of X.25, and
      would require a very large implementation effort in the
      PSNs and in hosts.  By the way, this would be required for
      the network to be able to automatically charge a host for
      all traffic it generates in BOTH directions of a call it
      originates, as you suggested. 

   b. Add a bit to the AHIP message leader, specifying collect
      charging for this message.  This would require that for
      each such message, a receiving host would need some sort of
      reply mechanism to either "accept" or "reject" such a
      message.  These acceptances or rejections would have to be
      passed back through the network to the originating host,
      which would have to send them back up to the IP and TCP
      layers.  This, again, could not be classified as a
      "trivial" change to either the PSN or host software.  And
      what do you do about hosts that don't upgrade?  Are they
      forced to accept these charges they cannot detect? 

   Or did you have something else in mind? 

2. Given a method to identify "collect calls", how does the
   sending host's AHIP driver know to use it?  Does the TCP
   driver send down, through the IP driver, information that
   identifies certain packets as "collect"?  How does the TCP
   driver know?  For example, how does the mailer daemon
   distinguish mail that is to be sent collect from mail to be
   sent normally?  How does the user FTP program know, when it
   establishes the FTP connection with the other host's FTP
   server, that the user plans to log in to the server using an
   "anonymous" login?  You see possible problems. 

3. How does a host receiving "collect" messages know whether to
   accept them or not?  If hosts just blindly accept all collect
   messages or calls, then I can program my host to ALWAYS send
   traffic collect. 

4. The DDN PMO generally considers AHIP to be fading away as more
   X.25 hosts join the ARPANET and MILNET.  They are also very
   resistant to any changes to AHIP that require changes in host
   software, because they have no control over the hosts and
   their AHIP implementation.  For these reasons, there is no
   assurance that AHIP-E will ever be accepted and implemented
   (don't start those host implementations yet, folks).  In fact,
   I am currently working on defining an alternative to AHIP-E
   that will require NO changes in host software. 

5. The only PSN work the DDN has currently authorized for this
   usage-sensitive charging is to add usage data collection and
   reporting to the AHIP interface code.  This function already
   exists for the X.25 interface.  They have not authorized any
   changes to the actual AHIP interface for this. 

There are other problems I could probably bring up as well, but
you get the point - a technical solution at the PSN level isn't
really feasible.  If you are concerned about the costs of your
host's traffic levels, my advice is to look into methods of
controlling the traffic (such as some that you suggested
yourself), or seek an administrative solution by bringing up
these issues with the DDN PMO before they finalize their charging
policies. 

I am also curious why you would consider discontinuing TAC access
for your regular users.  Any DDN charges for this access should
be directly recoverable from your users. 

Regards,
Andy Malis
PSN Development
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Sep 87 12:33:40 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Mills@LOUIE.UDEL.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, egp-people@PARK-STREET.BBN.COM
Subject:   Re: EGP updates over the top

The number of nets has indeed been sloshing about the arpanet update size
limit, the 1006 octet MTU.

The fragmenting of NR messages sent by core systems will be happenning with
the next release of software to the butterfly and lsi11 gateways.  If you want
to try some pre-release tests, we can send you some test gateway addresses to
try this week.

Re: the DON'T FRAGMENT (DF) bit in the IP header; a meaning has been assigned
for use of gateway implementations which do not initially do reassembly.  If a
poll message is received with the DF bit set, the NR message sent in reply
will be truncated to fit the (1006) MTU of the net.  Thus you can get SOME
info until the time when your gateway implements reassembly.
NOTE: This meaning is only in the new code which has the capability of doing
fragmentation and reassembly.  The current release which does not do
reassembly will only send as many nets as fit in 1000 (+/-) octets.

Look for announcements of debugging this week.

    Mike
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 10:39:26 EDT
From:      howie@cunixc.columbia.edu (Howie Kaye)
To:        comp.protocols.tcp-ip
Subject:   Re: EMail User Agents


Another version of MM is currently being written at Columbia
University, under a User interface package called CCMD.  This is an
expanded Tops-20 like interface, as described in the message about
MM-32.  

This MM program will be mostly compatible with the TOPS20 version,
though it will support several mail file types, and will eventually
run as a POP client.

CCMD currently runs under Berkeley and sysV UNIX, and MSDOS.  MM will
also run on all of these (Only as a POP client under MSDOS though.)

Mail to info-topsux-request@cu20b.columbia.edu, or 
	info-ccmd-request@cu20b.columbia.edu
for more information.]

------------------------------------------------------------
Howie Kaye				howie@columbia.edu
Columbia University 			hlkcu@cuvma.bitnet
Systems Group				...!rutgers!columbia!howie

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 10:56:51 EDT
From:      dzoey@UMD5.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   user interface for urgent data.

Hi, I was looking at the TCP spec (RFC 793) and became slightly curious
about how urgent data should be presented to the application.  Berkeley has
the application either register a function to handle the urgent data
seperately, or indicate that urgent data should be delivered as normal data.
This seems like a reasonable thing to do, but I'm curious about how other
implementations present urgent data.  I'd very much like to hear about how
other implementations do this.

Another question I have is where does the urgent data start?  Is it safe to
assume at the beginning of a packet marked as urgent?  If all the data in
a packet marked urgent is urgent data, then shouldn't urgent data be
delivered as soon as possible (i.e. not wait for sequence reassembly since
you know all data in that packet is urgent and would be delivered out of
sequence anyway)?

Is there something I should have read before asking this?


			Thanks for any info

        		Joe Herman

dzoey@umd5.umd.edu

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 11:18:35 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN X.25 mapping

Greg,

Ron is correct, RFC 796 only discusses the Class A mapping
between IP addresses and ARPANET/MILNET addresses.  He described
the generally accepted mapping for Class B IP addresses, using
the third octet for the host number and the fourth octet for the
PSN (IMP) number.

PLEASE remember to follow the algorithm in section A-5 of the DDN
X.25 Host Interface Spec (BBN Report 5476, in the DDN Protocol
Handbook, Vol 1, as section 6.6) for deriving the X.25 address,
so that logical addressing will work correctly.  All you have to
do is substitute the third octet of a Class B IP address for the
2nd octet of a Class A IP address as discussed in the algorithm.
This is on pages A-9 and A-10 of the spec (pages 1-497 and 1-498
of the Protocol Handbook).

There is no generally accepted standard for Class C addresses,
nor am I aware of any Class C PSN-based networks.  Certainly, 4
bits for each of the host and PSN numbers would work - it depends
on the number of PSNs in the network and the maximum number of
hosts on each PSN.  This mapping should probably be customized on
a network-by-network basis.  For consistency with the Class A and
Class B mappings, the host number bits should be in the more
significant bits of the 4th octet.

Regards,
Andy Malis
PSN Development

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Sep 87 14:36:19 -0400
From:      seisner@CC5.BBN.COM
To:        WANCHO@SIMTEL20.ARPA
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Can of worms...

Frank,

Just to add to Andy's message - the X.25 interface already supports the
reverse charging facilities you desire, and so will the accounting
system we will be putting in, for X.25 connections.  So, one way to get
what you want is to convert your direct host interface(s) from AHIP to
X.25, if that's at all a possibility.

Regards,
Sharon Eisner
PSN Development
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 11:56:33 EDT
From:      mankin@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   (none)

Z. Wang asked what happens to a source route option in a 4.2
gateway.

It depends what you mean by a 4.2 gateway.  The original Berkeley 
release of 4.2 has a typo in the code in ip_stripoptions (a bcopy to  
m instead of mopt--easy to see) which crashes the machine when an IP
packet with *any* option is forwarded.  The Ultrix version of 4.2
does not have this bug.

If this bug is fixed, the updated option goes out on the forwarded
packet.

		Allison

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 12:41:23 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms...

Frank,

As a host administrator myself (as well as a PSN code developer),
I understand your concern about the costs generated by the
usage-sensitive chargeback. 

However, I can find several problems with your proposed "collect
call" connections: 

1. Even though AHIP traffic is sent by the network using internal
   connections, the AHIP host interface is not explicitly
   connection-based.  There are two alternative ways a host could
   identify "collect calls": 

   a. Add explicit connection-based mechanisms to AHIP.  This
      would effectively turn AHIP into a variant of X.25, and
      would require a very large implementation effort in the
      PSNs and in hosts.  By the way, this would be required for
      the network to be able to automatically charge a host for
      all traffic it generates in BOTH directions of a call it
      originates, as you suggested. 

   b. Add a bit to the AHIP message leader, specifying collect
      charging for this message.  This would require that for
      each such message, a receiving host would need some sort of
      reply mechanism to either "accept" or "reject" such a
      message.  These acceptances or rejections would have to be
      passed back through the network to the originating host,
      which would have to send them back up to the IP and TCP
      layers.  This, again, could not be classified as a
      "trivial" change to either the PSN or host software.  And
      what do you do about hosts that don't upgrade?  Are they
      forced to accept these charges they cannot detect? 

   Or did you have something else in mind? 

2. Given a method to identify "collect calls", how does the
   sending host's AHIP driver know to use it?  Does the TCP
   driver send down, through the IP driver, information that
   identifies certain packets as "collect"?  How does the TCP
   driver know?  For example, how does the mailer daemon
   distinguish mail that is to be sent collect from mail to be
   sent normally?  How does the user FTP program know, when it
   establishes the FTP connection with the other host's FTP
   server, that the user plans to log in to the server using an
   "anonymous" login?  You see possible problems. 

3. How does a host receiving "collect" messages know whether to
   accept them or not?  If hosts just blindly accept all collect
   messages or calls, then I can program my host to ALWAYS send
   traffic collect. 

4. The DDN PMO generally considers AHIP to be fading away as more
   X.25 hosts join the ARPANET and MILNET.  They are also very
   resistant to any changes to AHIP that require changes in host
   software, because they have no control over the hosts and
   their AHIP implementation.  For these reasons, there is no
   assurance that AHIP-E will ever be accepted and implemented
   (don't start those host implementations yet, folks).  In fact,
   I am currently working on defining an alternative to AHIP-E
   that will require NO changes in host software. 

5. The only PSN work the DDN has currently authorized for this
   usage-sensitive charging is to add usage data collection and
   reporting to the AHIP interface code.  This function already
   exists for the X.25 interface.  They have not authorized any
   changes to the actual AHIP interface for this. 

There are other problems I could probably bring up as well, but
you get the point - a technical solution at the PSN level isn't
really feasible.  If you are concerned about the costs of your
host's traffic levels, my advice is to look into methods of
controlling the traffic (such as some that you suggested
yourself), or seek an administrative solution by bringing up
these issues with the DDN PMO before they finalize their charging
policies. 

I am also curious why you would consider discontinuing TAC access
for your regular users.  Any DDN charges for this access should
be directly recoverable from your users. 

Regards,
Andy Malis
PSN Development

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 12:50:45 EDT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP updates over the top


The number of nets has indeed been sloshing about the arpanet update size
limit, the 1006 octet MTU.

The fragmenting of NR messages sent by core systems will be happenning with
the next release of software to the butterfly and lsi11 gateways.  If you want
to try some pre-release tests, we can send you some test gateway addresses to
try this week.

Re: the DON'T FRAGMENT (DF) bit in the IP header; a meaning has been assigned
for use of gateway implementations which do not initially do reassembly.  If a
poll message is received with the DF bit set, the NR message sent in reply
will be truncated to fit the (1006) MTU of the net.  Thus you can get SOME
info until the time when your gateway implements reassembly.
NOTE: This meaning is only in the new code which has the capability of doing
fragmentation and reassembly.  The current release which does not do
reassembly will only send as many nets as fit in 1000 (+/-) octets.

Look for announcements of debugging this week.

    Mike

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Sep 87 15:46:51 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        WANCHO@SIMTEL20.ARPA, seisner@CC5.BBN.COM
Cc:        TCP-IP@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: Can of worms...
Frank,

What Sharon forgot to mention is that while the X.25 interface
does support reverse charging, the protocol layering and charging
algorithm issues that I raised still need to be resolved before
reverse charging can or should be actively used.  At least the
PSN implementation that you need is available, now all you need
is agreement on how and when to use it ...

Regards,
Andy
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14 Sep 87 15:50:37 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        Mills@LOUIE.UDEL.EDU
Cc:        Mike Brescia <brescia@PARK-STREET.BBN.COM>, tcp-ip@SRI-NIC.ARPA, egp-people@PARK-STREET.BBN.COM
Subject:   Re: EGP updates over the top
Re: sending fragments - not yet in core

1. Except for a short time around the beginning of August, new code to
fragment EGP NR messages has not yet been run in the LSI11's.  Around that
time, the code was run up on BBN2 and PURDUE for a few hours.

2. The LSI11's will copy the dont-fragment (DF) bit from the IP header of a
EGP POLL request into the NR reply.  This sounds like what you are seeing.
Since the LSI11 was going to truncate the message anyway, the bit was
essentially ignored.

Mike
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 13:13:02 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  EGP updates over the top

Mike,

Are you sure the new code has not escaped to ISI, PURDUE or BBN2? The behavior
I noticed last week, including the DF bit, occured with one or more of those
buzzards. Not to worry, though. At least the fuzz now do buzz EGP reassembly.

Dave

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 14:20:24 EDT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  T1 and distant IP networks

Another way to go is to interconnect at the link (Ethernet) layer using
Vitalink Translan III bridges. They support line speeds up to T1. We've
been running a half dozen of them within Bellcore for a year now and
they have been working very nicely. We have five large locations and
about 1000 hosts in our host table. During a typical daytime minute,
several hundred hosts may be active.  At the moment most of our links
are 250 kbps; one is already T1. All links will soon be upgraded to T1
when our DS-3 fibers are installed.

The big advantage of bridging is that you can run any protocol you want
across them; it doesn't have to be IP.  Another is that you can freely
move hosts between cable segments without having to change addresses; in
a large network like ours, the administrative savings are substantial.

The main disadvantage is that broadcasts go everywhere, although with
T1's bandwidth this isn't much of a problem.

Phil

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 14:33:25 EDT
From:      rms@ACC-SB-UNIX.ARPA (Ron Stoughton)
To:        comp.protocols.tcp-ip
Subject:   Re: ACC's ACCES/MVS

I would like to expand a bit on the comments Bob Dixon made regarding
his experience with ACCES/MVS:

> We use UCLA mail to front-end smtp. That causes minor problems as UCLA
> mail does not allow the full smtp address syntax.

Henry Nussbacher (HANK%BARILVM.BITNET@wiscvm.wisc.edu) told me recently
that an associate of his has made some improvements to UCLA/MAIL, one
being recognition of internet domain names.  I believe these changes
have been provided to UCLA, but I don't know for sure whether they are
included in the public domain release.  I can get you a name of a contact
if you are interested in more information.

> Full-screen telnet to a VM system running KNET does not work.

3270 over Telnet requires three negotiations to take place before going
into full-screen mode -- terminal type (e.g., IBM-3278-2), end-of-record
(EOR), and binary.  When ACCES/MVS is the server, KNET refuses the EOR
negotiations by returning WON'T/DON'T EOR in response to our DO/WILL EOR.
This causes our server to end up in binary (EBCDIC) line-at-a-time mode,
while the KNET client thinks (erroneously) that it is in full-screen 3270
mode.  Our transmissions to the client are therefore terminated with an
EBCDIC <cr><lf>, and KNET is waiting for an <IAC><EOR> sequence.  The
reverse is true in the opposite direction.  At this point the Telnet
session appears hung.

When ACCES/MVS is the client, KNET rejects our terminal type (IBM-3278-2)
and requests that we resend it with another sub-negotiation.  We don't
and we probably should, but even if we did, KNET does not negotiate EOR
which would leave us in the state as described above.  I suspect that
KNET is getting confused because our sub-negotiation response is being
split into two transmissions -- <IAC><SB><TERM-TYPE> in the first message
followed by <IS>IBM-3278-2<IAC><SE> in the second (it's a stream protocol
folks).

Bob Braden has suggested that the 3270 negotiation protocol could be changed
to imply EOR if, but only if, terminal type and binary are successfully
negotiated, and the terminal type is IBM-3278.  There is a separate group
of vendors and users debating this issue.  If and when there is a consensus
that the protocol should be changed, we will comply.  In the meantime, KNET
should conform to the protocol.

> FTP is very powerful in dealing with MVS files, but requires the user
> to supply the MVS volume name, which is a pain.

We agree, and as a result we have removed this wart, along with many others,
in the latest release (2.0).  If a volume name is not provided, a default
volume is used.  Also, DSCB attributes are now retained when writing to pre-
allocated data sets.  We think we have made simple transfers simple by
eliminating the need to use the SITE (i.e., Unix quote) command.  We en-
courage our users to upgrade to the new release.

> FTP allows file transfer between any 2 computers, neither of which needs
> to be the MVS system. This is useful, but requires the user to provide
> login info for MVS twice if one of the systems is MVS.

Bob Dixon was kinder than most in describing this feature.  Many users who
have been introduced to networking via Unix have found the three-party
model confusing, or at least more cumbersome to use.  Therefore, we have
rewritten the MVS FTP client to implement the command syntax of a Unix
client, and mimic a two-party model (the local MVS session is hidden).
This allows us to maintain the performance advantages of a three-party
model (the file does not need to pass through VTAM and the TSO address
space) while gaining the simplicity inherent in the two-party model.  This
will be available in Release 2.1 which is close to being out the door.

Incidentally, before I get growls from this mailing list, I should acknowledge
that we don't hold the Unix FTP client as the model of perfection, but it
does provide a measure of acceptance.  Therefore, we implemented it as an
alternative until we can provide an SPF panel-driven client which may be a
more natural interface for an IBM TSO user.

Ron Stoughton
rms@acc-sb-unix.arpa

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 14:36:43 EDT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   FTP advisory messages

A lot of new FTP users (and some veteran ones, too) get bitten by
forgetting to say "type image" before sending a binary file.  You get no
warning when you do this; you don't discover your mistake until you're
done and find that the file is corrupted. I would like to add an
advisory message to my own FTP server to warn the user when he/she does
this. The FTP client should just display this message to the user but
otherwise ignore it, relying on the user to abort the transfer. But how
should I do this?

I seem to remember that there are reply messages of the "0XX" class that
would do what I want, but I can't find it mentioned anywhere in the
specs.

Comments?

Phil

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 15:19:24 EDT
From:      seisner@CC5.BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms...


Frank,

Just to add to Andy's message - the X.25 interface already supports the
reverse charging facilities you desire, and so will the accounting
system we will be putting in, for X.25 connections.  So, one way to get
what you want is to convert your direct host interface(s) from AHIP to
X.25, if that's at all a possibility.

Regards,
Sharon Eisner
PSN Development

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 16:13:31 EDT
From:      MRC@PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN X.25 mapping

For the record, both BBN and PANDA TOPS-20 assume that any Class C
PSN-based network will have the host number in the high order 2 bits,
and the PSN in the low order 6 bits of the fourth octet.  This is the
format which we used in the good old days of NCP and 32-bit leaders,
for those of us old enough to remember that far back (am I betraying
my age????).

DEC TOPS-20 doesn't handle non-class A PSN's at all, nor does any
version of TOPS-20 I know of handle X.25 interfaces (the DEC IMPterface
is an 1822 device).  I think that DEC is adopting the PANDA algorithm
though.

I know of no controversy about the format a Class B PSN network address,
or, at least TOPS-20 and Unix agree on having the host number in the
third octet and the PSN number in the fourth octet.
-------

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 16:17:30 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms...

Frank,

What Sharon forgot to mention is that while the X.25 interface
does support reverse charging, the protocol layering and charging
algorithm issues that I raised still need to be resolved before
reverse charging can or should be actively used.  At least the
PSN implementation that you need is available, now all you need
is agreement on how and when to use it ...

Regards,
Andy

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 16:39:20 EDT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: EGP updates over the top

Re: sending fragments - not yet in core

1. Except for a short time around the beginning of August, new code to
fragment EGP NR messages has not yet been run in the LSI11's.  Around that
time, the code was run up on BBN2 and PURDUE for a few hours.

2. The LSI11's will copy the dont-fragment (DF) bit from the IP header of a
EGP POLL request into the NR reply.  This sounds like what you are seeing.
Since the LSI11 was going to truncate the message anyway, the bit was
essentially ignored.

Mike

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 18:06:34 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options

Oops.  I created a special version of the ip_input.c file with the fixes
I wanted to send but without post-4.3 changes that wouldn't work with
everyone else's system, but I missed one change (RTF_MODIFIED wasn't
in 4.3).  For those who have been trying to install the change I sent
out last week, here it is again in a form that should work with 4.3.

		Mike

*** /nbsd/usr/src.4.3/sys/netinet/ip_input.c	Thu Jun  5 00:28:15 1986
--- ip_input.c	Mon Sep 14 14:59:07 1987
***************
*** 5,7 ****
   *
!  *	@(#)ip_input.c	7.1 (Berkeley) 6/5/86
   */
--- 5,7 ----
   *
!  *	@(#)ip_input.c	7.6.1.2 (Berkeley) 9/14/87
   */
***************
*** 302,304 ****
  	if (fp == 0) {
! 		if ((t = m_get(M_WAIT, MT_FTABLE)) == NULL)
  			goto dropfrag;
--- 302,304 ----
  	if (fp == 0) {
! 		if ((t = m_get(M_DONTWAIT, MT_FTABLE)) == NULL)
  			goto dropfrag;
***************
*** 490,491 ****
--- 490,492 ----
  
+ extern struct in_ifaddr *ifptoia();
  struct in_ifaddr *ip_rtaddr();
***************
*** 595,597 ****
  				break;
! 			bcopy((caddr_t)(cp + off), (caddr_t)&ipaddr.sin_addr,
  			    sizeof(ipaddr.sin_addr));
--- 596,598 ----
  				break;
! 			bcopy((caddr_t)(&ip->ip_dst), (caddr_t)&ipaddr.sin_addr,
  			    sizeof(ipaddr.sin_addr));
***************
*** 602,604 ****
  				type = ICMP_UNREACH;
! 				code = ICMP_UNREACH_SRCFAIL;
  				goto bad;
--- 603,605 ----
  				type = ICMP_UNREACH;
! 				code = ICMP_UNREACH_HOST;
  				goto bad;
***************
*** 620,622 ****
  			}
! 			sin = (struct in_addr *)(cp+cp[IPOPT_OFFSET]-1);
  			switch (ipt->ipt_flg) {
--- 621,623 ----
  			}
! 			sin = (struct in_addr *)(cp + ipt->ipt_ptr - 1);
  			switch (ipt->ipt_flg) {
***************
*** 630,636 ****
  					goto bad;
! 				if (in_ifaddr == 0)
! 					goto bad;	/* ??? */
! 				bcopy((caddr_t)&IA_SIN(in_ifaddr)->sin_addr,
  				    (caddr_t)sin, sizeof(struct in_addr));
! 				sin++;
  				break;
--- 631,636 ----
  					goto bad;
! 				ia = ifptoia(ifp);
! 				bcopy((caddr_t)&IA_SIN(ia)->sin_addr,
  				    (caddr_t)sin, sizeof(struct in_addr));
! 				ipt->ipt_ptr += sizeof(struct in_addr);
  				break;
***************
*** 638,639 ****
--- 638,642 ----
  			case IPOPT_TS_PRESPEC:
+ 				if (ipt->ipt_ptr + sizeof(n_time) +
+ 				    sizeof(struct in_addr) > ipt->ipt_len)
+ 					goto bad;
  				bcopy((caddr_t)sin, (caddr_t)&ipaddr.sin_addr,
***************
*** 642,646 ****
  					continue;
- 				if (ipt->ipt_ptr + sizeof(n_time) +
- 				    sizeof(struct in_addr) > ipt->ipt_len)
- 					goto bad;
  				ipt->ipt_ptr += sizeof(struct in_addr);
--- 645,646 ----
***************
*** 652,654 ****
  			ntime = iptime();
! 			bcopy((caddr_t)&ntime, (caddr_t)sin, sizeof(n_time));
  			ipt->ipt_ptr += sizeof(n_time);
--- 652,655 ----
  			ntime = iptime();
! 			bcopy((caddr_t)&ntime, (caddr_t)cp + ipt->ipt_ptr - 1,
! 			    sizeof(n_time));
  			ipt->ipt_ptr += sizeof(n_time);
***************
*** 731,733 ****
  		return ((struct mbuf *)0);
! 	m = m_get(M_WAIT, MT_SOOPTS);
  	m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1;
--- 732,736 ----
  		return ((struct mbuf *)0);
! 	m = m_get(M_DONTWAIT, MT_SOOPTS);
! 	if (m == 0)
! 		return ((struct mbuf *)0);
  	m->m_len = ip_nhops * sizeof(struct in_addr) + IPOPT_OFFSET + 1 + 1;
***************
*** 841,843 ****
  	}
! 	if (ip->ip_ttl < IPTTLDEC) {
  		type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS;
--- 844,846 ----
  	}
! 	if (ip->ip_ttl <= IPTTLDEC) {
  		type = ICMP_TIMXCEED, code = ICMP_TIMXCEED_INTRANS;
***************
*** 870,873 ****
--- 873,881 ----
  	 * and if packet was not source routed (or has any options).
+ 	 * Also, don't send redirect if forwarding using a default route
+ 	 * or a route modfied by a redirect.
  	 */
+ #define	satosin(sa)	((struct sockaddr_in *)(sa))
  	if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp &&
+ 	    (ipforward_rt.ro_rt->rt_flags & RTF_DYNAMIC) == 0 &&
+ 	    satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 &&
  	    ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) {
***************
*** 874,876 ****
  		struct in_ifaddr *ia;
- 		extern struct in_ifaddr *ifptoia();
  		u_long src = ntohl(ip->ip_src.s_addr);
--- 882,883 ----

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 19:29:55 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   (none)

On the contrary, 4.2BSD never forwarded IP options.  IP options
were updated if necesssary (not necessarily correctly), stripped from
the packet, then freed in ip_output without inserting them back into
the packet.  (I don't remember that the typo in ip_stripoptions
actually crashed the machine, but it obviously wasn't right.)

		Mike

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Mon, 14-Sep-87 19:49:35 EDT
From:      BUDDENBERGRA@A.ISI.EDU (Rex Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   User chargeback issues

The subject of user chargeback has some economic overtones that may
tend to be overlooked if we don't bring them up.  Since we are in
this business, on this net for 1) improving national security, 2)
propagating networks to make money or 3) both, it is
appropriate to look beyond the technical issues.

Most communications facilities: Autodin, Autovon, FTS, are provided
to the user at no perceived cost -- the 'user' charges are generally
paid for at the headquarters level.  At the unit level, they appear
as 'free goods'.  In the past, decentralizing of user charges was
either not possible or didn't fit 'the way we've always done it'.
This results in an unconstrained Parkinson's Law effect where usage
expands to fill the capacity available.  Take a look at the Navy's
satellite bandwidth, the federal government's phone usage, ...
for examples -- they are two-blocked.

So what happens if we add user chargeback?  Communications services
compete for an organization's resources just like any other 
requirement.  Incentive for rational, balanced budgeting of resources.
OK so far, but there are a couple hidden gotchas.

1.  What are we trying to do with DDN?  If we want to make a single
large internet to handle all data traffic, a user chargeback, or threat
of one, is a strong inhibition to defer taking the plunge.  We have
private nets, continued Autodin usage, ad hoc dial-ups, etc proliferating
because MilNet usage appears more expensive -- to the user.  If
we want DDN to proliferate, the user chargeback probably ought to
be subsidized by appropriation to DCA as it is now.  The extremes are
a) full subsidization by DCA, like now -- provide network as a free
good in order to gain market share from Autodin et al, b) full user
chargeback making the service user bear full costs.  Neither extreme
is good, what we need is a balance somewhere between.

2.  User chargebacks encourage skimming.  Consider the post office;
Uncle's PO, including the APOs and FPOs, delivers worldwide.  I got
mail through the system in the Antarctic and on Iwo Jima.  Can't
say that much for Federal Express or UPS.  The commercial
competition within CONUS takes the lucrative market and leaves Uncle
with the more expensive portion of the system -- the overseas
requirements.  These routes are necessary, and the cost for maintaining
them now goes up because the lucrative routes can't subsidize them
and because we lose economies of scale.  The DDN analogues are
the overseas routes and classified service.  Both are likely to
remain exempt from the user chargeback scheme, at least at first.
This is likely to result in a lot of users buying commercial network
connectivity for CONUS traffic and DCA being stuck for the
overseas and classified service, which will now become more expensive.

3.  The final gotcha is that user chargeback needs to be implemented
in a way that doesn't open the door to traffic analysis.  
Even if we don't chargeback to users, the data flow info is useful --
to Ivan as well as the network managers.  I've been in law
enforcement long enough to know how valuble telephone tolls are
in tracking a smuggler and his activities -- let's not set ourselves
up.

Rex Buddenberg
-------

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 1987 19:49:35 EDT
From:      Rex Buddenberg <BUDDENBERGRA@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        BUDDENBERGRA@A.ISI.EDU
Subject:   User chargeback issues
The subject of user chargeback has some economic overtones that may
tend to be overlooked if we don't bring them up.  Since we are in
this business, on this net for 1) improving national security, 2)
propagating networks to make money or 3) both, it is
appropriate to look beyond the technical issues.

Most communications facilities: Autodin, Autovon, FTS, are provided
to the user at no perceived cost -- the 'user' charges are generally
paid for at the headquarters level.  At the unit level, they appear
as 'free goods'.  In the past, decentralizing of user charges was
either not possible or didn't fit 'the way we've always done it'.
This results in an unconstrained Parkinson's Law effect where usage
expands to fill the capacity available.  Take a look at the Navy's
satellite bandwidth, the federal government's phone usage, ...
for examples -- they are two-blocked.

So what happens if we add user chargeback?  Communications services
compete for an organization's resources just like any other 
requirement.  Incentive for rational, balanced budgeting of resources.
OK so far, but there are a couple hidden gotchas.

1.  What are we trying to do with DDN?  If we want to make a single
large internet to handle all data traffic, a user chargeback, or threat
of one, is a strong inhibition to defer taking the plunge.  We have
private nets, continued Autodin usage, ad hoc dial-ups, etc proliferating
because MilNet usage appears more expensive -- to the user.  If
we want DDN to proliferate, the user chargeback probably ought to
be subsidized by appropriation to DCA as it is now.  The extremes are
a) full subsidization by DCA, like now -- provide network as a free
good in order to gain market share from Autodin et al, b) full user
chargeback making the service user bear full costs.  Neither extreme
is good, what we need is a balance somewhere between.

2.  User chargebacks encourage skimming.  Consider the post office;
Uncle's PO, including the APOs and FPOs, delivers worldwide.  I got
mail through the system in the Antarctic and on Iwo Jima.  Can't
say that much for Federal Express or UPS.  The commercial
competition within CONUS takes the lucrative market and leaves Uncle
with the more expensive portion of the system -- the overseas
requirements.  These routes are necessary, and the cost for maintaining
them now goes up because the lucrative routes can't subsidize them
and because we lose economies of scale.  The DDN analogues are
the overseas routes and classified service.  Both are likely to
remain exempt from the user chargeback scheme, at least at first.
This is likely to result in a lot of users buying commercial network
connectivity for CONUS traffic and DCA being stuck for the
overseas and classified service, which will now become more expensive.

3.  The final gotcha is that user chargeback needs to be implemented
in a way that doesn't open the door to traffic analysis.  
Even if we don't chargeback to users, the data flow info is useful --
to Ivan as well as the network managers.  I've been in law
enforcement long enough to know how valuble telephone tolls are
in tracking a smuggler and his activities -- let's not set ourselves
up.

Rex Buddenberg
-------
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 00:58:00 EDT
From:      WANCHO@SIMTEL20.ARPA
To:        comp.protocols.tcp-ip
Subject:   Can of worms...

Andy,
     The main reason for even bringing up AHIP/AHIP-E is because that
is the level this host talks to the PSN.  As I understand it, the
only logical place to account for host traffic is at the PSN level,
and the PSN knows nothing about any protocol layers above its own - at
least, it's not in that business to know.  All that means is that no
matter what scheme is developed for accounting of packets, any
exceptions must be somehow conveyed to the PSN about each packet.  If
DDN X.25 already has this capability, fine.  However, I doubt you will
see those of us who have been running the old 1822 (a.k.a, AHIP)
rushing out the door to retrofit an X.25 interface just because it
doesn't and won't have this feature.  In our case, we will probably
just move to the backside of our gateway.

Now for your specific comments, objections, and questions:

1.  Because it appears that traffic through a PSN cannot be identified
on a per-connection basis in order to charge for all traffic in both
directions to the originating host, let's define another way: all
outgoing traffic is charged to the sending host, except that traffic
sent to the originating host is sent collect.  It would then be up to
the originating host to accept the collect message because it is
keeping track of which connections it originated.  The host receiving
the connection already knows to send all outgoing traffic collect.
Same bottom line, but without requiring the PSN to keep track of each
connection.

2.  How does the TCP driver know to send something collect?  If it
received the call, then it replies in collect mode.  If it originates
the call, then the only process that needs to be able to make it
collect is SMTP.  For large mailing list mail, we already process
those messages through its own mailer and it really is trivial to add
another option to the mail queue file as it's requeued.  A user FTP
connection is always charged to the originating host, whether normal
or anonymous.

3.  When reduced to the final case, all that's left in establishing a
collect call is a collect SMTP connection.  I would propose that the
SMTP server accept the call, but refuse to receive the message based
on the addressee, if that addressee is not on a special alias file.
The host administrator then has control over which addressees are
permitted to receive collect messages.

4.  I have no sympathy for the argument that AHIP is fading and thus
no changes can be made.  If that's the way it is, then other courses
of action become economically justifiable.  However, conversion to DDN
X.25 is not one of them at this time.

     I am painfully aware that the solutions I have proposed are worse
than the problem.  But, the currently proposed charging algorithm has
many gaping holes in it which allow charges to be incurred which can
only be controlled by dropping those services.  I don't really want to
do that, but I may have no choice.  I'd really prefer someone in
authority to declare usage-sensitive chargeback self-defeating and
drop it.
     Finally, TAC access under the planned chargeback is simply
uneconomical.  I can put in more direct lines with no changes required
to our accounting log mechanism at a one-time cost of much less than
one month's TAC Access charges.  I can buy several mainframe class
computers for what those charges would be in a year.  I'm sorry, but I
don't believe in unchallenged pass-through charges to our users,
especially when I can offer far superior services on a direct
connection at no additional charge.  What do I get for $0.075 per
minute dialup connect time and anywhere from $0.60 to $4.00 per
kilopacket on a TAC?  The right to charge back to my host at the
highest possible packet rate - one character per packet - at some of
the lowest data rates available!!!  Maybe if there was some local
intelligence capable of handling some of the more popular file
transfer protocols at the TAC level which can potentially increase the
packet size from 100 to a 1,000-fold (and reduce the charges by the
same factors) and access at 2400 and 9600 bps to reduce connect time,
I might reconsider.

--Frank

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 87 09:26:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Class C nets and DDN X.25

>For the record, both BBN and PANDA TOPS-20 assume that any Class C
>PSN-based network will have the host number in the high order 2 bits,
>and the PSN in the low order 6 bits of the fourth octet.  This is the
>format which we used in the good old days of NCP and 32-bit leaders,
>for those of us old enough to remember that far back (am I betraying
>my age????).

This was fine for the original IMPS which only had four host ports.
(I remember the ruggedized Honeywell 516 based IMP at UCSB which was
one of the four nodes in the first incarnation of the ARPANET)
But newer IMPS have many more host ports.  Our in-house test IMP has
20 host ports, so we would probably recommend at least 5 bits for host
number.  This leaves room for a net of about 6 IMPS (reserve 0 and 7).
I don't know of anyone really running a class C IMP net.  We have a
class C number assigned for our test IMP but haven't put it to use
yet.

AHIP-E could affect all this, but it may never be deployed.

					Art Berggreen
					art@acc.arpa

------
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 87 09:23:00 PDT
From:      "Mike Anello" <mja@twg.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Reply: HELP: select() under sockets
HELP: select() under Wollongong sockets
Is it me or our sockets service??

code fragment
...
set up connection on file descriptor nfd

/*
**********************************************
** select test code
etc. etc. etc.

In response to your mail about problems with select(3W):

We believe that you are incorrectly using the numfds argument in
the system call. You must increase this number so that select will
work on more that just stdin. Possibly using a number like 5 or 6 to 
be safe. Your code will only select on stdin and you probably really 
want to select on at least stdin, stdout, stderr, and one other file
descriptor. I hope this is helpful for you.

Mike Anello
The Wollongong Group
------
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 1987 09:42-PDT
From:      CERF@A.ISI.EDU
To:        dzoey@UMD5.UMD.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, davidc@TERMINUS.UMD.EDU dzoey@TERMINUS.UMD.EDU
Subject:   Re: user interface for urgent data.
Joe,

In the urgent daa design, it was assumed that TCP should NOT
impose any kind of syntax on the data stream. Rather, the
flagging of urgen data meant, roughly, "start scanning the
data stream wherever you are now and go through at least
to the placed marked URGENT. Process appropriately whatever
you read, given that you know you are in URGENT mode until you
get to byte sequence number X."

It was assumed that the application using TCP would have
conventions for structuring of the TCP byte stream and
for interpreting what to do with urgent data indicator.

Vint Cerf
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Sep 87 13:48:32 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        art@ACC.ARPA
Cc:        tcp-ip <tcp-ip@SRI-NIC.ARPA>, malis@CC5.BBN.COM
Subject:   Re: Class C nets and DDN X.25
Art,

The only addition I would like to make to your comments is that 0
is not a legal PSN number, and there is no network-layer reason
to reserve PSN number 7.

Andy

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 11:50:48 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  T1 and distant IP networks

Although, if you have any VMS machines, I would seriously avoid
protocol independant bridges of this nature.  The older version of
Wollongong TCP choke the vax in response to certain rather common
broadcast messages.

-Ron

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15 Sep 87 14:39:51 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        art@ACC.ARPA
Cc:        tcp-ip <tcp-ip@SRI-NIC.ARPA>, brescia@PARK-STREET.BBN.COM
Subject:   Re: Class C nets and AHIP (was: DDN X.25 )
I don't know of any class C arpanets either, but we have talked about allowing
the full range of 256 hosts and using only one imp.  How do you find the imp
number?  From the NOPS at startup time.

Seriously, that could be one of the range of options if the configuration of
your host specified where the boundary between the host-part and the imp-part
of the 8 bits available in the 'rest' part of the class C address.  Thus you
could have 5 bits of host to keep Art happy, and in another net, 2 bits of
host.  It should not be fixed over all class C arpanets.

If the net grows beyond the number of hosts or imps you allow, you will have
to either move the boundary, or make a transition to a class B net.

/Mike
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 12:23:00 EDT
From:      mja@TWG.ARPA ("Mike Anello")
To:        comp.protocols.tcp-ip
Subject:   Reply: HELP: select() under sockets

HELP: select() under Wollongong sockets
Is it me or our sockets service??

code fragment
...
set up connection on file descriptor nfd

/*
**********************************************
** select test code
etc. etc. etc.

In response to your mail about problems with select(3W):

We believe that you are incorrectly using the numfds argument in
the system call. You must increase this number so that select will
work on more that just stdin. Possibly using a number like 5 or 6 to 
be safe. Your code will only select on stdin and you probably really 
want to select on at least stdin, stdout, stderr, and one other file
descriptor. I hope this is helpful for you.

Mike Anello
The Wollongong Group
------

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 12:42:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: user interface for urgent data.

Joe,

In the urgent daa design, it was assumed that TCP should NOT
impose any kind of syntax on the data stream. Rather, the
flagging of urgen data meant, roughly, "start scanning the
data stream wherever you are now and go through at least
to the placed marked URGENT. Process appropriately whatever
you read, given that you know you are in URGENT mode until you
get to byte sequence number X."

It was assumed that the application using TCP would have
conventions for structuring of the TCP byte stream and
for interpreting what to do with urgent data indicator.

Vint Cerf

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 13:07:19 EDT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP advisory messages

Thanks, Ron, yours sounds like a good idea. I'll do it that way.

Phil

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 13:07:54 EDT
From:      ron@topaz.rutgers.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP advisory messages

DO NOT ADD 0XX CLASS MESSAGES.  They don't exist and some machines
sent them in the past which causes the sequencing of all future
replies to get messed up.  The best bet is for the SERVER to just use
different text to the 150 message that is printed just before the
transfer (UNIX usually places the file name and the size of the file
in bytes here).  You can make it say something like

    150 Starting "foo.bin" IN ASCII MODE

-Ron

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 13:13:22 EDT
From:      ron@topaz.rutgers.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Can of worms...

Of course Frank, the DDN is mandated for use instead of putting
these cheaper (and possibly better) leased circuits through.  Of
course, the same people have been insisting we use FTS rather than
the cheaper WATS as well.

-Ron

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 13:26:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Class C nets and DDN X.25


>For the record, both BBN and PANDA TOPS-20 assume that any Class C
>PSN-based network will have the host number in the high order 2 bits,
>and the PSN in the low order 6 bits of the fourth octet.  This is the
>format which we used in the good old days of NCP and 32-bit leaders,
>for those of us old enough to remember that far back (am I betraying
>my age????).

This was fine for the original IMPS which only had four host ports.
(I remember the ruggedized Honeywell 516 based IMP at UCSB which was
one of the four nodes in the first incarnation of the ARPANET)
But newer IMPS have many more host ports.  Our in-house test IMP has
20 host ports, so we would probably recommend at least 5 bits for host
number.  This leaves room for a net of about 6 IMPS (reserve 0 and 7).
I don't know of anyone really running a class C IMP net.  We have a
class C number assigned for our test IMP but haven't put it to use
yet.

AHIP-E could affect all this, but it may never be deployed.

					Art Berggreen
					art@acc.arpa

------

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 14:14:55 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C nets and DDN X.25

Art,

The only addition I would like to make to your comments is that 0
is not a legal PSN number, and there is no network-layer reason
to reserve PSN number 7.

Andy

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 14:46:54 EDT
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   tn3270 availability

There is a new procedure (previously hinted at) for distributing tn3270
by mail.  The current procedure for arpanet access (via anonymous ftp)
remains in place.

To receive a copy of tn3270 by mail, send a check for $100.00 (US), along
with a note indicating your desire to receive the tn3270 diskette, to:

	Campus Software Office
	295 Evans Hall
	University of California
	Berkeley, California 94720
	USA

You will receive, in exchange, an AT style (1.2MB) diskette with the tn3270
source (in tar format).  For your $100.00 (US), you have unlimited
redistribution rights (for both the source and any binaries generated).

I encourage people to use this path to acquire tn3270.  One advantage of
this path is that you get on "the list".  This list should allow you to
receive updates and announcements.  From our side, the advantage is having
some handle on the use of tn3270.

Sincerely,

Greg Minshall

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 15:21:57 EDT
From:      brescia@PARK-STREET.BBN.COM (Mike Brescia)
To:        comp.protocols.tcp-ip
Subject:   Re: Class C nets and AHIP (was: DDN X.25 )

I don't know of any class C arpanets either, but we have talked about allowing
the full range of 256 hosts and using only one imp.  How do you find the imp
number?  From the NOPS at startup time.

Seriously, that could be one of the range of options if the configuration of
your host specified where the boundary between the host-part and the imp-part
of the 8 bits available in the 'rest' part of the class C address.  Thus you
could have 5 bits of host to keep Art happy, and in another net, 2 bits of
host.  It should not be fixed over all class C arpanets.

If the net grows beyond the number of hosts or imps you allow, you will have
to either move the boundary, or make a transition to a class B net.

/Mike

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 15:41:13 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP advisory messages

ftp contains a "SITE" word that is largely unused. It would be
really nice if most implementations agreed on what came after
the SITE word.

E.g. It would be really nice to have the user mode ftp program
automatically send "SITE UNIX" (or something along that line) and the
ftp server on the other machine return success or failure. Then, if
the user ftp got success as an answer, it could automagically 
set the type to image. If it got back anything but successful, it would
do nothing, so no harm would be done.

I actually implemented this a few years ago. There was one major
problem with it. The TOPS-20 ftp servers always returned success
to ANY SITE command. Obviously, this screwed up things royally. I was never
successful in getting anyone to admit that the TOPS-20 was broken and
to fix it.

It's a pity that SITE can't be used. It work work wonderfully in this
particular case.

---rick

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 15:51:15 EDT
From:      gkenley@palladium.UUCP
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Public Domain TCP/IP

I had been told by someone from pSOS (Real time romable OS) that a public
domain implementation of TCP/IP existed for a CMC Ethernet board (which is
identical to MVME350 motorola board - 68000 with AMD7990).  He told me
to contact John Pope of Aehr Tess in California.  When I called Aehr Tess
told me that he no longer was there and would not give out his forwarding
address or number.  We needed something that simply worked on the MVME350
board just to bootstrap ourselves.  Maybe John is out there somewhere.

Greg Kenley
Palladium Data Sytems, Inc.
"Home of the DataTub"

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      15 SEP 87 16:04-SYS
From:      DHWalker%UCIVMSA.BITNET@wiscvm.wisc.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Connecting DECnet routers over IP
Received: from ORION by UCICP6 with PMDFs; 15 Sep 1987 15:53:12
Received: from localhost by orion.cf.uci.edu id a018460; 15 Sep 87 15:47 PDT
Date: Tue, 15 Sep 87 15:47:17 -0700
From: David Walker <dwalker@orion.cf.uci.edu>

I know this has been hashed over many times, but I haven't seen it
quite like this, so here goes...

Has anyone have a way to use TCP (UDP?) to connect two DECnet routing
nodes?  It would be (I think) an ideal way to provide DECnet
connectivity for people in an IP environment.  The DECnet people in
one subnet can designate one of their systems as one of these routers
to communicate with DECnet people in other subnets.

                                   David Walker
                                   Network Services Manager
                                   University of CA, Irvine
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 18:05:04 EDT
From:      steve@NOTE.NSF.GOV
To:        comp.protocols.tcp-ip
Subject:   Re: User chargeback issues


     3.  The final gotcha is that user chargeback needs to be implemented
     in a way that doesn't open the door to traffic analysis.  
     Even if we don't chargeback to users, the data flow info is useful --
     to Ivan as well as the network managers.  I've been in law
     enforcement long enough to know how valuble telephone tolls are
     in tracking a smuggler and his activities -- let's not set ourselves
     up.

Get real.  The door is already open to traffic analysis, and if (110 dB rattle
of saber) "Ivan" really cares, he's already doing it.

Chargeback is a totally orthogonal issue.

-s

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Tue, 15-Sep-87 20:29:29 EDT
From:      DHWalker@UCIVMSA.BITNET
To:        comp.protocols.tcp-ip
Subject:   Connecting DECnet routers over IP

Received: from ORION by UCICP6 with PMDFs; 15 Sep 1987 15:53:12
Received: from localhost by orion.cf.uci.edu id a018460; 15 Sep 87 15:47 PDT
Date: Tue, 15 Sep 87 15:47:17 -0700
From: David Walker <dwalker@orion.cf.uci.edu>

I know this has been hashed over many times, but I haven't seen it
quite like this, so here goes...

Has anyone have a way to use TCP (UDP?) to connect two DECnet routing
nodes?  It would be (I think) an ideal way to provide DECnet
connectivity for people in an IP environment.  The DECnet people in
one subnet can designate one of their systems as one of these routers
to communicate with DECnet people in other subnets.

                                   David Walker
                                   Network Services Manager
                                   University of CA, Irvine

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 04:18:48 EDT
From:      chris@COLUMBIA.EDU (Chris Maio)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP advisory messages

Rick,

> I was never successful in getting anyone to admit that the TOPS-20 was
> broken and to fix it.

  All the TOPS-20 FTP servers I know return a 504 failure reply to a "SITE
UNIX" command (in contrast to the UNIX server, which mumbles "Please login with
USER first").  On the other hand, you should really be using the SYST command
instead (see RFC959).
							Chris

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 09:16:00 EDT
From:      DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Connecting DECnet routers over IP

I don't think you want to use TCP or UDP to transport DECnet packets. 
Rather, you probably want to use IP for that purpose.  This would make
DECnet a sibling of TCP, UDP, ICMP, etc.  You probably find it useful to
 - to get an assigned number to stick in the IP protocol field, 
 - circulate a draft RFC to make sure several people find the
   functionality sufficient (such as "How do you translate DECnet
   addresses to IP addresses?"), and
 - perhaps get some prototype implementations working to find the bugs
and then publish your results as an RFC.

I don't know the specifics of DECnet, but I am somewhat interested in
what you come up with, as many of the same issues come up with CHAOSnet.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 11:03:15 EDT
From:      HANK@TAUNIVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Proteon p4200 (router)

Can people who are currently using these boxes please send me their
evaluations:  I am most interested in how well it handles Tcp/Ip protocols
and how transparently it passes Decnet traffic.

Please reply directly to me and not to the list.

Thanks,
Hank

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 11:53:17 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP advisory messages

Great. They finally fixed it! The server used to return a 2xx response.

Now all we need is for them to produce legal RFC822 date lines...

---rick

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 13:02:03 EDT
From:      louie@TRANTOR.UMD.EDU (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Clockwatchers beware

Folks,
	The WWVB clock attached to UMD1.UMD.EDU aka WWVB.UMD.EDU is not
currently usable, as the disk drive on that host is very unhappy.  If you
use the clock services of this clock with UDP/NTP or UDP/TIME, you'll be
out of luck for a day or two.

louie

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 13:51:55 EDT
From:      TS0400@OHSTVMA.BITNET (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   ACC ACCES/MVS

Ron Stoughton's information was very helpful.
But I must point out how ironic the full-screen situation is.
Non-IBM computers can telnet into either ACCES or KNET and get full-screen
operation. Yet the 2 IBM systems cannot telnet to EACH OTHER and get full-
screen operation. It would be nice if you two companies stopped the finger-
pointing and solved your mutual interoperability problems.

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

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Sep 87 13:51:55 EDT
From:      Bob Dixon <TS0400%OHSTVMA.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   ACC ACCES/MVS
Ron Stoughton's information was very helpful.
But I must point out how ironic the full-screen situation is.
Non-IBM computers can telnet into either ACCES or KNET and get full-screen
operation. Yet the 2 IBM systems cannot telnet to EACH OTHER and get full-
screen operation. It would be nice if you two companies stopped the finger-
pointing and solved your mutual interoperability problems.

                                           Bob Dixon
                                           Ohio State University
Acknowledge-To: <TS0400@OHSTVMA>
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 14:29:55 EDT
From:      erikn@sics.se (Erik Nordmark)
To:        comp.protocols.tcp-ip
Subject:   Benchmarks for high-level protocols

Sender: 
Reply-To: erikn@sics.se (Erik Nordmark)
Followup-To: 
Distribution: world
Organization: Swedish Institute of Computer Science, Kista
Keywords: benchmark performance

To my knowledge the standard way of comparing protocol performance
is to transfer a large file between two machines using the different 
protocols.

My question to the net is if anybody uses more sophisticated benchmarks
that take into account e.g. real-time communication, transaction-style
communication, the overhead for multiple connections, the protocol's 
ability to handle packet loss due to the sender(s) overrunning the 
receiver et.c. et.c.
(Pointers to any litterature on the topic are appreciated too!)

If the response to this message is significant I'll summarize to the net!

-------------------------------------------------------------------------
Erik Nordmark
Swedish Institute of Computer Science, Box 1263, S-163 13  SPANGA, Sweden
Phone: +46 8 750 79 70	Ttx: 812 61 54 SICS S	Fax: +46 8 751 72 30

uucp:	erikn@sics.UUCP or {seismo,mcvax}!enea!sics!erikn
Domain: erikn@sics.se
-------------------------------------------------------------------------

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 15:47:52 EDT
From:      A024012@RUTVM1.BITNET (Ross Patterson)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP advisory messages

Rick,

    According  to  RFC  959,  the  SYST command  should  be  used  for
verifying the type of server  you're using.  It's documented as having
no parameters,  and returning  as the  first word  of the  response, a
system name defined in the  Assigned Numbers RFC (whatever it's called
this week).  The SITE command  is specifically intended for necessary,
but  non-universal,  parameters.   The  only  system  I've  seen  that
actually  uses it  (UCLA's IBM  MVS implementation)  has 20  different
parameters that it accepts.  It can specify the disk on which to store
a file;  what sort of disk it is;  whether to do tab expansion, and if
so, how wide;   disk storage format (record lengths,  etc);  even that
the next file sent is to be run as a batch job.

    My point  is that any attempt  to standardize the use  of the SITE
command is improper.  If you  want a standard facility, change another
command or add a  new one.  SITE is for those  systems that have other
needs and/or capabilities, beyond the standards.

Ross Patterson
Rutgers University

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Sep 1987 15:47:52 EDT
From:      Ross Patterson <A024012%RUTVM1.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  FTP advisory messages
Rick,

    According  to  RFC  959,  the  SYST command  should  be  used  for
verifying the type of server  you're using.  It's documented as having
no parameters,  and returning  as the  first word  of the  response, a
system name defined in the  Assigned Numbers RFC (whatever it's called
this week).  The SITE command  is specifically intended for necessary,
but  non-universal,  parameters.   The  only  system  I've  seen  that
actually  uses it  (UCLA's IBM  MVS implementation)  has 20  different
parameters that it accepts.  It can specify the disk on which to store
a file;  what sort of disk it is;  whether to do tab expansion, and if
so, how wide;   disk storage format (record lengths,  etc);  even that
the next file sent is to be run as a batch job.

    My point  is that any attempt  to standardize the use  of the SITE
command is improper.  If you  want a standard facility, change another
command or add a  new one.  SITE is for those  systems that have other
needs and/or capabilities, beyond the standards.

Ross Patterson
Rutgers University
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Sep 87 20:00:00 PDT
From:      rms@ACC-SB-UNIX.ARPA (Ron Stoughton)
To:        tcp-ip@sri-nic.arpa
Cc:        .@ACC-SB-UNIX.ARPA
Subject:   Re: ACC's ACCES/MVS
>  It would be nice if you two companies stopped the finger-
>  pointing and solved your mutual interoperability problems.
>  
>                                             Bob Dixon
>                                             Ohio State University

I think we're trying to do this through the TN3270 mail list which
was formed to discuss such problems.  I have included for the record
a copy of my recent message to this list on this very same subject.
I think it is self explanatory.  It was in response to Bruce Craybil's
rehtorical query whether the group was going to decide anything.

I should also point out that the procedures for negotiating a 3270 Telnet
session are not specified in any officially endorsed document.  Thus we
have the situation we have today.  The only official record of this protocol
is the two original systems which implemented it -- Wiscnet and UCLA ACP.

Ron Stoughton
rms@acc-sb-unix.apra

>  Received: by columbia-pdn (5.51/5.17)
>  	id AA25241; Tue, 15 Sep 87 22:06:40 EDT
>  Received: by ACC-SB-UNIX.ARPA (5.51/4.7)
>  	id AA02106; Tue, 15 Sep 87 19:05:53 PDT
>  Date: Tue, 15 Sep 87 19:05:53 PDT
>  From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton)
>  Message-Id: <8709160205.AA02106@ACC-SB-UNIX.ARPA>
>  To: @UMD2.UMD.EDU:BRUCE@UMDD.BITNET, TN3270@terminus.UMD.EDU
>  Subject: Deciding SOMETHING
>  Status: RO
>  
>  As a vendor caught in the middle, I should probably comment.  It is
>  ironic that during the initial flurry of messages when this list first
>  started up, I was out of town at a customer's site trying to find out
>  why we don't interoperate with another vendor's product.  Even though
>  I think I have history on my side, and hopefully Bob Braden since it's
>  his code, it does the customer little good for me to beat my chest
>  claiming we're right.
>  
>  I certainly hope this group does decide SOMETHING, possibly starting
>  with what is the endorsed procedure for negotiating a full-screen
>  session TODAY.  Since our work queue is already overflowing, my initial
>  vote will be cast for that which doesn't require us to change anything
>  (i.e., the minimal pain philosophy).  However, we will comply with
>  whatever this group endorses.
>  
>  In the longer term, we need to decide how to support other 3270 features,
>  which will likely be accommodated by additional negotiations.  This may
>  be the appropriate time to simplify the procedures.  I tend to be more
>  of a pragmatist than a purist, so I have no objection to combining
>  multiple options into a single negotiation.
>  
>  Ron Stoughton
>  rms@acc-sb-unix.arpa
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16 Sep 87 10:59 IST
From:      Hank Nussbacher <HANK%TAUNIVM.BITNET@wiscvm.wisc.edu>
To:        <tcp-ip@sri-nic.ARPA>
Subject:   Proteon p4200 (router)
Can people who are currently using these boxes please send me their
evaluations:  I am most interested in how well it handles Tcp/Ip protocols
and how transparently it passes Decnet traffic.

Please reply directly to me and not to the list.

Thanks,
Hank
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 20:45:08 EDT
From:      mike@BRL.ARPA (Mike Muuss)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple Internet addresses

The strategy that we have used at BRL (implemented by J. Pistritto)
for many years now is to run a simple program on each local net host
(called "router") that is given a prioritized list of "default routes".
The highest priority route that meets certain maximum roundtrip times (<
5 sec) and maximum packet loss rates (50%) is selected.  When the
highest priority route is not selected, all higher priority ones are
PINGed at a slow rates (once/minute).  When a higher priority path
becomes acceptable again, the default route is switched back to it.
No PINGs leave the local network, and the ping rate is very low.

4.3 BSD does the rest, handling redirects, etc., that the gateway issues,
and reconsulting the routing tables when a TCP connection is "halfway"
timed out.

We have found this strategy to work very successfully.
	FYI
	 -Mike

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Wed, 16-Sep-87 23:59:47 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: T1 and distant IP networks

We have three situations similar to what you describe, i.e. pairs of
IP networks connected by T1.  We are using the following three
approaches:
  - VAXes running Ultrix with the T1 line connected to DMR11's.
	Avanti T1 Mux's are used to cut down the speed, since
	no known DEC line controller can deal with speeds this
	high.  This is probably the cheapest of the 3 methods,
	if you already have the VAXes, but also give the worst
	performance and has other disadvantages.
  - Cisco IP routers, using either Digilink T1-izers (boxes that
	take a vanilla 1.5Mb synchronous signal and format it
	for T1) or Avanti T1 muxes (for cases where we need
	to use the line for things other than the IP link, e.g.
	talking to 3270 cluster controllers at the other site).
	This is my preferred solution.  (Of course vendors other
	than Cisco also make routers that would do this.  You
	might want to talk to Proteon and U-B also.)
  - U-B bridges.  These would also need either a T1-izer or
	T1 mux.  These are level 2 bridges rather than level 3
	routers, which have both advantages and disadvantages.
	(They have been discussed so often that I am not about
	to repeat the discussion.)  The U-B bridges have worked
	very well, but note that you must dedicate an IBM PC
	or clone to boot them.  (I believe the same PC can be
	shared for booting all U-B products.)  I strongly oppose
	the use of this approach if the two IP networks are
	under different administration, and if you don't have
	support staff available at both ends.  Junk coming from
	the other end can sink your network.

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 00:04:00 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   official Berkeley fix for telnetd CR-NL mapping

In order to resolve certain compatibility problems when telnet sessions
are nested, 4.3BSD telnetd has been changed to translate <CR><NL> to '\r'
rather than 'n'.  This circumvents problems when using a telnet client
that is incapable of sending <CR><NUL> to signify a carriage return,
then using telnet or tip to connect to a system that differentiates
between carriage return and line feed.  (See previous discussions on
the tcp-ip mailing list.)  This patch also fixes an error that mapped
<CR><NUL> to '\r' in binary mode.  It is recommended that all 4.3BSD
sites change telnetd according to this patch.

		Mike

*** /nbsd/usr/src/etc/telnetd.c	Mon May 12 22:21:51 1986
--- telnetd.c	Wed Sep  2 23:22:30 1987
***************
*** 13,15 ****
  #ifndef lint
! static char sccsid[] = "@(#)telnetd.c	5.18 (Berkeley) 5/12/86";
  #endif not lint
--- 13,15 ----
  #ifndef lint
! static char sccsid[] = "@(#)telnetd.c	5.20 (Berkeley) 9/2/87";
  #endif not lint
***************
*** 573,575 ****
  			*nfrontp++ = c;
! 			if (c == '\r') {
  				if (pcc > 0 && ((*ptyip & 0377) == '\n')) {
--- 573,576 ----
  			*nfrontp++ = c;
! 			/* Don't do CR-NUL if we are in binary mode */
! 			if ((c == '\r') && (myopts[TELOPT_BINARY] == OPT_NO)) {
  				if (pcc > 0 && ((*ptyip & 0377) == '\n')) {
***************
*** 617,618 ****
--- 618,620 ----
  			state = TS_DATA;
+ 			/* Strip off \n or \0 after a \r */
  			if ((c == 0) || (c == '\n')) {
***************
*** 630,632 ****
  			/*
! 			 * We map \r\n ==> \n, since \r\n says
  			 * that we want to be in column 1 of the next
--- 632,638 ----
  			/*
! 			 * We now map \r\n ==> \r for pragmatic reasons.
! 			 * Many client implementations send \r\n when
! 			 * the user hits the CarriageReturn key.
! 			 *
! 			 * We USED to map \r\n ==> \n, since \r\n says
  			 * that we want to be in column 1 of the next
***************
*** 636,644 ****
  			 */
! 			if ((myopts[TELOPT_BINARY] == OPT_NO) && c == '\r') {
! 				if ((ncc > 0) && ('\n' == *netip)) {
! 					netip++; ncc--;
! 					c = '\n';
! 				} else {
! 					state = TS_CR;
! 				}
  			}
--- 642,645 ----
  			 */
! 			if ((c == '\r') && (hisopts[TELOPT_BINARY] == OPT_NO)) {
! 				state = TS_CR;
  			}

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 02:06:03 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting DECnet routers over IP

If someone seriously needs this, and uses Cisco IP routers, please
tell me.  I have an implementation of DECnet for the Cisco routers.
Encapsulating DECnet in IP would be fairly easy in my implementation.
However there is no obvious advantage to doing this, unless you need
to send DECnet between two Ethernets that are fairly far apart.  That
is, if somebody at UCI wanted to talk DECnet to somebody at Rutgers,
it might make sense to send DECnet over the Arpanet encapsulated in IP
(though I'd probably first investigate allocating a link type for
DECnet).  But for two Ethernets on one campus, this probably does not
make sense.  In order to get a DECnet host to send you packets for
forwarding, you must implement most of the DECnet routing layer.
Having done so, you might as well finish it and become a real DECnet
router.  In that case, there's no particular reason to encapsulate
DECnet in IP.  You might as well route it as DECnet.

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 06:20:50 EDT
From:      howellg@idec.stc.co.uk (Gareth Howell)
To:        comp.protocols.tcp-ip
Subject:   DDN Protocol Handbook

Recently I saw a reference to the DDN protocol handbook.  Can anybody
provide a full citation so that I can obtain a copy through our
library service.
Please email if possible
Thanks, Gareth

-- 
Gareth Howell  <howellg@idec.stc.co.uk>  G6KVK @ IO91VX
ICL Network Systems, Private Networks Business Centre   
London Road, Stevenage, Herts, England, SG1 1YB    Tel:+44 (0)438 738294
howellg%idec%ukc@mcvax.uucp, idec!howellg@seismo.CSS.GOV

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 87 03:21:38 GMT
From:      mangler@csvax.caltech.edu  (System Mangler)
To:        tcp-ip@sri-nic.arpa
Subject:   domain forwarder authorization?
One of our uucp neighbors is applying for a domain name via the UUCP
Zone Registry, and has asked us to be their official mail forwarder on
the ARPAnet, i.e. the nameserver MX record for them would point to us.
What authorization do we have to get from the DDN folks to be registered
as the official forwarder for a domain that does not have sponsorship to
connect directly to the Internet?  Whom should I contact about it?

Similarly, what kind of authorization is required for us to be a registered
nameserver for their domain?

Don Speck   speck@vlsi.caltech.edu  {amdahl,rutgers}!cit-vax!speck
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Sep 87 11:37:50 PDT
From:      jlp@Sun.COM (John Pope)
To:        comp.sources.wanted,comp.protocols.tcp-ip tcp-ip@sri-nic.ARPA
Subject:   Re: Public Domain TCP/IP
In article <358@palladium.UUCP> gkenley@palladium.UUCP (Greg Kenley) writes:
>I had been told by someone from pSOS (Real time romable OS) that a public
>domain implementation of TCP/IP existed for a CMC Ethernet board (which is
>identical to MVME350 motorola board - 68000 with AMD7990).  He told me
>to contact John Pope of Aehr Tess in California.  When I called Aehr Tess
>told me that he no longer was there and would not give out his forwarding
>address or number.  We needed something that simply worked on the MVME350
>board just to bootstrap ourselves.  Maybe John is out there somewhere.
>
>Greg Kenley
>Palladium Data Sytems, Inc.
>"Home of the DataTub"

Yes, I am out here. Unfortunately, I don't think I have what you're 
looking for. The PD software in question was a Unix driver modified to 
run under pSOS, not an implementation of TCP/IP. The TCP/IP we were
using at AEHR Test was the one supplied by CMC, which works just fine.

P.S.
	What's a DataTub??

	John Pope
		Sun Microsystems, Inc. 
			jlp@sun.COM
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 11:33:42 EDT
From:      loverso@encore.UUCP (John LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options

In article <6211@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes:
> I have been faithfully following the 4.3 fixes posted here and in the
> 'official' news group.  However, RTF_MODIFIED does not seem to be
> defined in my source.

To my knowledge, they've never been released outside of Berkeley other
than in the Tahoe-Beta release of 4.3BSD.  In there, RTF_MODIFIED is
defined to mean the route came in via a redirect.  Here are the
diffs to net/route.[ch].  With all the various versions of the 4.3 TCP/IP
code I've seen, this is just about all that I've ever seen changed in net/.
BTW, I'm only posting this since I haven't seen a reply from Mike Karels yet,
and without this, his ip_input.c changes aren't much good.

John

*** /source/BSD4.3/sys/net/route.h	Thu Jun  5 02:43:05 1986
--- route.h	Thu Jan 15 18:09:44 1987
***************
*** 4,8 ****
   * specifies the terms and conditions for redistribution.
   *
!  *	@(#)route.h	7.1 (Berkeley) 6/4/86
   */
  
--- 4,8 ----
   * specifies the terms and conditions for redistribution.
   *
!  *	@(#)route.h	7.2 (Berkeley) 1/15/87
   */
  
***************
*** 46,49 ****
--- 46,50 ----
  #define	RTF_HOST	0x4		/* host entry (net otherwise) */
  #define	RTF_DYNAMIC	0x10		/* created dynamically (by redirect) */
+ #define	RTF_MODIFIED	0x20		/* modified dynamically (by redirect) */
  
  /*
*** /source/BSD4.3/sys/net/route.c	Thu Jun  5 02:42:47 1986
--- route.c	Thu Jan 15 18:09:44 1987
***************
*** 4,8 ****
   * specifies the terms and conditions for redistribution.
   *
!  *	@(#)route.c	7.1 (Berkeley) 6/4/86
   */
  
--- 4,8 ----
   * specifies the terms and conditions for redistribution.
   *
!  *	@(#)route.c	7.2 (Berkeley) 1/15/87
   */
  
***************
*** 176,181 ****
  			 */
  			rt->rt_gateway = *gateway;
  		}
 - 		rtstat.rts_newgateway++;
  	} else
  		rtstat.rts_badredirect++;
--- 176,182 ----
  			 */
  			rt->rt_gateway = *gateway;
+ 			rt->rt_flags |= RTF_MODIFIED;
+ 			rtstat.rts_newgateway++;
  		}
  	} else
  		rtstat.rts_badredirect++;

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Sep 87 11:39:58 EDT
From:      fedor@devvax.tn.cornell.edu (Mark Fedor)
To:        mike@brl.arpa, narten@purdue.edu
Cc:        ietf@gateway.mitre.org, tcp-ip@sri-nic.arpa
Subject:   Re:  Multiple Internet addresses
>Date:     Wed, 16 Sep 87 20:45:08 EDT
>From: Mike Muuss <mike@brl.arpa>
>Subject:  Re:  Multiple Internet addresses
>
>The strategy that we have used at BRL (implemented by J. Pistritto)
>for many years now is to run a simple program on each local net host
>(called "router") that is given a prioritized list of "default routes".
>The highest priority route that meets certain maximum roundtrip times (<
>5 sec) and maximum packet loss rates (50%) is selected.  When the
>highest priority route is not selected, all higher priority ones are
>PINGed at a slow rates (once/minute).  When a higher priority path
>becomes acceptable again, the default route is switched back to it.
>No PINGs leave the local network, and the ping rate is very low.
>
>4.3 BSD does the rest, handling redirects, etc., that the gateway issues,
>and reconsulting the routing tables when a TCP connection is "halfway"
>timed out.
>
>We have found this strategy to work very successfully.
>	FYI
>	 -Mike
>

	Mike,

	This sounds interesting, but your letter left me with a question
	on "router".  Since 4.3BSD does not time out/delete routes learned via
	a redirect from the kernel, does the "router" program delete a
	redirect-learned route if the gateway for that route goes away?

	Hope this is clear enough...

	Mark

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 13:51:05 EDT
From:      carlf@cadovax.UUCP
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Networking Delays

Does anyone have information regarding the delays caused 
by software in each of the OSI layers over a 10 mb Ethernet
LAN?

I am also interested in what delay would be experienced if
TCP/IP were used instead of OSI Layers 3 and 4.

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 14:40:14 EDT
From:      jlp@vatican.UUCP
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Re: Public Domain TCP/IP

In article <358@palladium.UUCP> gkenley@palladium.UUCP (Greg Kenley) writes:
>I had been told by someone from pSOS (Real time romable OS) that a public
>domain implementation of TCP/IP existed for a CMC Ethernet board (which is
>identical to MVME350 motorola board - 68000 with AMD7990).  He told me
>to contact John Pope of Aehr Tess in California.  When I called Aehr Tess
>told me that he no longer was there and would not give out his forwarding
>address or number.  We needed something that simply worked on the MVME350
>board just to bootstrap ourselves.  Maybe John is out there somewhere.
>
>Greg Kenley
>Palladium Data Sytems, Inc.
>"Home of the DataTub"

Yes, I am out here. Unfortunately, I don't think I have what you're 
looking for. The PD software in question was a Unix driver modified to 
run under pSOS, not an implementation of TCP/IP. The TCP/IP we were
using at AEHR Test was the one supplied by CMC, which works just fine.

P.S.
	What's a DataTub??

	John Pope
		Sun Microsystems, Inc. 
			jlp@sun.COM

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 17:07:40 EDT
From:      rick@SEISMO.CSS.GOV (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  FTP advisory messages

The SYST command looks cute but in the real world is useless. 

While I suppose that if you get MVS or VMS or TOPS-20 back from the
SYST command it might be useful, if it returns "UNIX" then you really
haven't gained anything.

The wonderful thing about UNIX is that it runs on almost any hardware.
What I really want to know in this example is the packing (and
possibly byte ordering) of characters in a word. I don't believe that
all Unix implementations are 8 bits = 1 character = 1 byte. I think the
C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals
with me, but you get the idea)

If SITE works (and I'm told that it does finally work), then you could
do something like "SITE 8BITBYTES" and decide whether to go into binary
mode based on that.


SYST might be useful, but since its constrained to returning official
system types, it just doesn't cut it for UNIX.

--rick

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 87 13:21:16 GMT
From:      mcvax!enea!ttds!draken!sics!erikn@seismo.css.gov  (Erik Nordmark)
To:        tcp-ip@sri-nic.arpa
Subject:   Benchmarks for high-level protocols
Sender: 
Reply-To: erikn@sics.se (Erik Nordmark)
Followup-To: 
Distribution: world
Organization: Swedish Institute of Computer Science, Kista
Keywords: benchmark performance

To my knowledge the standard way of comparing protocol performance
is to transfer a large file between two machines using the different 
protocols.

My question to the net is if anybody uses more sophisticated benchmarks
that take into account e.g. real-time communication, transaction-style
communication, the overhead for multiple connections, the protocol's 
ability to handle packet loss due to the sender(s) overrunning the 
receiver et.c. et.c.
(Pointers to any litterature on the topic are appreciated too!)

If the response to this message is significant I'll summarize to the net!

-------------------------------------------------------------------------
Erik Nordmark
Swedish Institute of Computer Science, Box 1263, S-163 13  SPANGA, Sweden
Phone: +46 8 750 79 70	Ttx: 812 61 54 SICS S	Fax: +46 8 751 72 30

uucp:	erikn@sics.UUCP or {seismo,mcvax}!enea!sics!erikn
Domain: erikn@sics.se
-------------------------------------------------------------------------
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17 Sep 87 21:35:44 -0400
From:      Mike Brescia <brescia@PARK-STREET.BBN.COM>
To:        William Westfield <BILLW@MATHOM.CISCO.COM>
Cc:        tcp-ip@SRI-NIC.ARPA, brescia@PARK-STREET.BBN.COM
Subject:   Re: Question about IP options
Bill,

When I talked about processing IP options only if the packet was addressed to
the gateway, that was historically accurate for the LSI11 core gateways, which
did not implement record route, timestamping or security options.

Because of the extra overhead of doing a complete scan of the IP options at
every gateway hop, I propose, only slightly tongue-in-cheek, that we extend
the IP header by 8 (16? 32?) bits for a flag word indicating that certain
options are present and should be scanned.  Use bit[i] to indicate the
presence of an option whose value is "i".  Gateways which do not handle
security, for example, can rapidly dispose of (oops, forward :-) those packets
with only the security option bit on.

This is an extension of an earlier idea (source unknown) which used a single
bit in the IP header to declare the presence of options which needed
processing at every gateway.

Note: if you have any flames about the specifics of the proposal, I doubt that
I will answer them.  I did want to get in a bid for faster handling of
packets.  Maybe I am still too concerned with 'efficiency'.

    Mike
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 19:41:20 EDT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple Internet addresses

Mark,

You guessed correctly.  When the current default route goes away "router"
crafts up a new default entry, removes the old one, and then removes any
references to the old default (letting the kernal rebind to the new one).
The end result is that your applications can usually keep on talking without
realizing that their route has been changed.

- Phil

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 19:47:30 EDT
From:      phil@BRL.ARPA (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multiple Internet addresses

Mark,

You guessed correctly.  When the current default route goes away, "router"
crafts up a new default, deletes the old one, and then removes any references
to the old default (letting the kernel rebind them to the new one).  The
end result is that your applications can usually keep on talking without
realizing that their route has changed.

- Phil

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 19:51:33 EDT
From:      bzs@BU-CS.BU.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   FTP advisory messages


From: rick@seismo.CSS.GOV (Rick Adams)
>The wonderful thing about UNIX is that it runs on almost any hardware.
>What I really want to know in this example is the packing (and
>possibly byte ordering) of characters in a word. I don't believe that
>all Unix implementations are 8 bits = 1 character = 1 byte. I think the
>C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals
>with me, but you get the idea)
>
>If SITE works (and I'm told that it does finally work), then you could
>do something like "SITE 8BITBYTES" and decide whether to go into binary
>mode based on that.

It's not even obvious that the particular operating system was ever
germaine, that may have been a false start (as you seem to point out
in your example.) An image file between a VAX/VMS and VAX/UNIX system
will work in image mode as will a 68K and IBM370, something more
abstract needs to be developed to cover the cases.

Perhaps an asymmetrical psuedo-bitstring who's bit order and length
can be used to infer the architecture? Something like:

VAX,NS32k:	"10010110 10010110 10010110 10010110"
68K,IBM370:	"01101001 01101001 01101001 01101001"
PDP10:		"(?just 36 1s?)"
PDP11:		"10010110 10010110"

etc. Perhaps it could be optionally presented in Hex or Octal using
some suitable escape ("0x9696 9696 9696 9696") if that were desired.
This could be prefixed by the OS if desired "SITE UNIX 1001..." and a
lot would be known. A better binary number than my example is probably
needed, but the idea should be clear.

The nice thing about it is the default is easy (don't do image.)

The only thing that bothers me (I guess) is that the scientific
community might have chosen floating point format to normalize upon.
And somewhere down there a whole different project lies.

	-Barry Shein, Boston University

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 20:02:39 EDT
From:      dyer@spdcc.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: FTP advisory messages

In article <8709172107.AA16664@beno.CSS.GOV>, rick@SEISMO.CSS.GOV (Rick Adams) writes:
> What I really want to know in this example is the packing (and
> possibly byte ordering) of characters in a word. I don't believe that
> all Unix implementations are 8 bits = 1 character = 1 byte. I think the
> C/70 has a 9 bit byte or something. It runs Unix (I don't have my manuals
> with me, but you get the idea)

Puhleeaze.  The C/70 has *10* bit bytes and *20* bit words, in 68K-style
byte order.  As you might expect, IMAGE mode was an exercise in bit
manipulation.  As to how it packed them together, well, that depended
on what version of ftp and ftpd we had released at the time.  Luckily,
this confusion was never inflicted on customers, only in-house.  I remember
that the switch between one encoding scheme to another was only slightly less
disruptive than the cutover from NCP to TCP...
-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 20:53:55 EDT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about IP options

[ Indented quotes from Jonathan Biggar, ">"ed quotes from Mike Brescia ]

     2)  When using either loose or strict source routing, does the next hop
         or the final destination go in the destination address field of the
         IP header?

>Next hop.  A rationale for this choice, based on processing power needed, is
>that a gateway does not have to look at the options unless the IP destination
>address is the gateway.  Then you look for options, and, finding a source
>route, send it back out again.

Unfortunately this rationale is completely false, since there are many
IP options that must be processed whether or not the IP destination is
the gateway's address.  (These include record route, timestamping, and
security.)

A better reason is the behavior that you get when some gateway does
not implement source routing is much more sociable this way.

Consider a packet sent from A to D with source route B:C:D, and where
B does not implement source routing.  If the original destination D
stays in the header through the entire trip, then the packet will
arrive at B, and be forwarded on to some gateway (perhaps C) without
processing the source route option.  C will get the packet, notice
that it has an incomplete source route, and forward it to the next
gateway in the list, which is still B.  The packet will loop between
B and C until it dies.  Depending on the type of link between them,
this could be very expensive in some sense.

When the IP destination is replaced at each hop, all that happens is
that B receives the packet, and probably throws it out due to some
higher level protocol checksum faliure...

Bill Westfield
cisco Systems
-------

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 22:38:37 EDT
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Clockwatchers beware

Louie,

Why don't you reterminate the clock on the NSF fuzzball, which would make
it a functional duplicate of the NCAR machine?

Dave

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Thu, 17-Sep-87 23:36:23 EDT
From:      brescia@PARK-STREET.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Question about IP options

Bill,

When I talked about processing IP options only if the packet was addressed to
the gateway, that was historically accurate for the LSI11 core gateways, which
did not implement record route, timestamping or security options.

Because of the extra overhead of doing a complete scan of the IP options at
every gateway hop, I propose, only slightly tongue-in-cheek, that we extend
the IP header by 8 (16? 32?) bits for a flag word indicating that certain
options are present and should be scanned.  Use bit[i] to indicate the
presence of an option whose value is "i".  Gateways which do not handle
security, for example, can rapidly dispose of (oops, forward :-) those packets
with only the security option bit on.

This is an extension of an earlier idea (source unknown) which used a single
bit in the IP header to declare the presence of options which needed
processing at every gateway.

Note: if you have any flames about the specifics of the proposal, I doubt that
I will answer them.  I did want to get in a bid for faster handling of
packets.  Maybe I am still too concerned with 'efficiency'.

    Mike

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 00:12:05 EDT
From:      jed@mbunix.UUCP
To:        comp.protocols.tcp-ip
Subject:   Telnet/FTP for PCs with 3Com Ethernet cards, MACs, any others??

The following public reply to Bob Claeson is provided to spark comment.

Additionally, I am interested in anyone's knowledge of any-domain
implementations of Telnet (vt100, vtXXX, 3278 models 2 and 4, NVT and NVDET),
FTP, and SMTP on CMC, Excelan, 3Com or you pick it.


  Robert Claeson (enea!pvab!robert@seismo.arpa) writes (tcp-ip message 954)
  RE: Telnet for a PC/3Com configuration.
>>
>>Which one should I use? The telnet in Sun's PC/NFS was almost useless. We
>>need support for national characters, ie we need to be able to remap the
>>keyboard in about the same way as SmarTerm 240. 
>>By the way, is it possible to use another telnet together with Sun's PC/NFS
>>and 3Com's EtherLink card? And is there only plain vt100 telnets for PC's?

    I currently have in house three Telnet implementations: FTP Inc's "PC/TCP" 
FTP/Telnet software, the FTP/Telnet that is available with SUN's PC/NFS (V.2), 
and the Telnet/FTP from NCSA (the National Center for Supercomputing 
Applications).  I feel the NCSA Telnet/FTP product is superior to the others 
in the functions it provides (and the price is right ...free).  However to be
fair, FTP Inc. and SUN both offer unique capabilities that may be of value to
you.  But that is for another discussion.

    NCSA's screen "capture" capability is implemented similar to the way the
Kermit communications software does it.  The Telnet is coupled with a vt100
emulation and others are on the way.  The FTP is very easy to use but is a
server-only implementation (that is, you must be logged in to the
source/destination host and initiate your ftp from there; the next release may
allow a user FTP).  My favorite capability is multiple sessions (you can be
logged in as many as 20 times and an indicator on the screen lets you know if
data has been received in any of the sessions).  Also, the NCSA Telnet doesn't
require additional "CONFIG.SYS" drivers.

    As for remapping the keyboard, I use the key redefinition function of 
DESQview (window/task management software).  I am told that Superkey and 
Prokey (which I will implement shortly) should also work.

    I have had no problems with the NCSA software working in my PC/AT with 
the PC/NFS drivers installed.  However, I have not been able to fully test the
compatibility as our NFS server is not yet installed.

    Also, if you have Macintoshes, you'll be glad to know there is an NCSA
Telnet version for the Mac.

    Simtel20.arpa has a ".arc" file in PD:<MSDOS.Telnet>.  Also, you can get
the PC and MAC files via anonymous FTP from uxc.cso.uiuc.edu in the
subdirectory NCSA.
 
    Questions or comments should be directed to one of the authors of the NCSA 
Telnet via mail To: "telbug%newton@uxc.cso.uiuc.edu.arpa".

-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
 ARPA: jed@mitre-bedford.arpa >                      John E. Daum
  or   jed@mitre-omaha.arpa   >
 Phone: (402) 292-5889       >

Disclaimer:  My opinions are just that, and do not reflect corporate views.
------------------------

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 10:11:30 EDT
From:      louie@TRANTOR.UMD.EDU (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: Clockwatchers beware

Dave,
	The clock and machine are feeling much better now, thank you.  We
would have done something like this, but the machines are in two different
rooms.  I decided that I would be faster to replace the disk driver than move
the clock and reroute various wires, cables and other snakes.

Let me know thinks don't seem back to normal.

louie

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 12:32:00 EDT
From:      mbr@aoa.UUCP (Mark Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   Anybody using CMC Transerver? (Was: Ethernet Terminal Servers?)

In discussing the topic of Ethernet Terminal Servers, many people have
reported on their experiences with Encore, Bridge, and Cisco.  Is anybody
out there using the CMC Transerver?  What do you think of it?  How good
are its implementations of TCP/IP, telnet, rlogin?  Can it drive all
10 lines at 9600 baud?  19.2 baud?  What RS232 signals does it implement
besides TxD, RxD, and Sig Gnd?  Can individual lines be configured to pass
8-bit binary to a device (i.e. not put a special interpretation on any
particular character, not discard NULL bytes)?
-- 
	Mark of the Valley of Roses
	...!{harvard,ima}!bbn!aoa!mbr
	...!{wjh12,mit-vax}!biomed!aoa!mbr

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 13:04:49 EDT
From:      postel@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Source Route IP Options

Network Working Group                                  J. Postel
Request for Comments: DRAFT                            J. Reynolds
                                                       XXXX 1987


                 Comments on the IP Source Route Option


Status of this Memo

   This RFC discusses a feature of the Internet Protocol (IP) used in
   the ARPA-Internet community, and requests discussion and suggestions
   for improvements of the description of this feature.  Distribution of
   this memo is unlimited.

Introduction

   The purpose of this memo is to expand the discussion of the IP Source
   Route Option and to give some examples of its use.

Overview

   The IP Source Route option allows the originator (source host) of an
   IP datagram to specify a number of specific gateways the datagram
   must pass though in sequence before being delivered to the
   destination host.

The Source Route Concept

   The concept of the Source Route Option is to let the originator (or
   source) of the datagram specify a list of points (gateways) the
   datagram is to pass through on the way to its destination.

   This type of explicit routing is usually not necessary since the
   Internet gateways exchange routing information and route datagrams
   based only on the destination address (and possibly other factors
   such as type of service).

   One reason for using source routing might be to reach some part of
   the Internet via a path that the gateways somehow don't know about
   via their normal routing information exchange.  Another reason may be
   to explicitly use or avoid certain networks for performance, or
   administrative reasons (such as privacy, access policy, or billing).
   A reason for using source routing that has been exercised with good
   results already is testing.  Source routing allows sending datagrams
   that transit particular Internet paths testing either particular
   networks or particuar gateways (or both) from a remote monitoring
   host.



Postel & Reynolds                                               [Page 1]
 
RFC DRAFT                                                      XXXX 1987


   The source route is implemented by including an option in the IP
   header that lists additional addresses.  That is, a source routed
   datagram starts out with the address of the first stop on the route
   in the IP header destination address field, and the addresses of
   subsequent stops as elements in the option list.  At each stop, an
   address is taken from an element of the list in the option and placed
   in the destination address field and that element of the list is
   replaced by the address of that stop.

   There are three IP options:  Strict Source Route (SSR), Loose Source
   Route (LSR) and Record Route (RR).  Both SSR and LSR also record the
   route as well.  The difference between SSR and LSR is that in SSR the
   route must specify gateway separated by only one network, but in LSR
   the path between stops on the specified route maybe any length and
   determined by normal gateway routing.

   The information in a source route is a list of 32-bit IP addresses
   and a pointer that indicates which address in the list is to be used
   next.

The following example shows the working of the option in simplified
form.

   Example 1:

      Suppose that the source is host A, the destination is host E and
      the gateways to be explicitly passed through are B, C, and D.

      +-----+     +-----+     +-----+     +-----+     +-----+
      |     |     |     |     |     |     |     |     |     |
      |  A  |-----|  B  |-----|  C  |-----|  D  |-----|  E  |
      |     |     |     |     |     |     |     |     |     |
      +-----+     +-----+     +-----+     +-----+     +-----+

      When the datagram is sent from the source host (A) into the
      Internet the Source Address (SA), Destination Address (DA), Source
      Route List (SRL) and Source Route Pointer (SRP) the fields are:

               SA:  A
               DA:  B
               SRL: C,D,E
               SRP: 0

      After the datagram arrives at gateway B, the gateway notices the
      source route option and transposes the address from the
      destination field and the next element of the source route list
      and increments the source route pointer.  As the datagram leaves
      gateway B, the fields are:



Postel & Reynolds                                               [Page 2]
 
RFC DRAFT                                                      XXXX 1987


               SA:  A
               DA:  C
               SRL: B,D,E
               SRP: 1

      At gateway C, the processing is similar.  The datagram leaves
      gateway C with its fields appearing:

               SA:  A
               DA:  D
               SRL: B,C,E
               SRP: 2

      At gateway D, the processing is similar.  The datagram leaves
      gateway D with its fields appearing:

               SA:  A
               DA:  E
               SRL: B,C,D
               SRP: 3

      Finally, the datagram arrives at host E.  Even though the source
      route option is still present, host E knows it is the final
      destination because the source route pointer now indicates that
      the source route list is exhausted.

   Example 1 was simplified to present the general concept.  One detail
   that was omitted is that each gateway really has two (or more)
   addresses.  When the option is processed, the address that must be
   stored back into the option field is the address for going in the
   reverse direction.

   Example 2:

      Suppose that the source is host A, with address IA on net I.  The
      destination is host E, with address LE on net L.  The gateways to
      be explicitly passed through are B, C, and D.  Each gateway has
      two addresses, one on each directly connected network.

      +-----+       +-----+       +-----+       +-----+       +-----+
      |     |IA   IB|     |JB   JC|     |KC   KD|     |LD   LE|     |
      |  A  |-------|  B  |-------|  C  |-------|  D  |-------|  E  |
      |     | net I |     | net J |     | net K |     | net L |     |
      +-----+       +-----+       +-----+       +-----+       +-----+

      When the datagram is sent from the source host (A) into the
      Internet, the Source Address (SA), Destination Address (DA),
      Source Route List (SRL), and Source Route Pointer (SRP) the fields



Postel & Reynolds                                               [Page 3]
 
RFC DRAFT                                                      XXXX 1987


      are:

               SA:  IA
               DA:  IB
               SRL: JC,KD,LE
               SRP: 0

      After the datagram arrives at gateway B, the gateway notices the
      source route option and moves the address from the next element of
      the source route list to the destination field, places its own
      reverse direction address in the that element of the source route
      list, and increments the source route pointer.  As the datagram
      leaves gateway B, the fields are:

               SA:  IA
               DA:  JC
               SRL: JB,KD,LE
               SRP: 1

      At gateway C, the processing is similar.  The datagram leaves
      gateway C with its fields appearing:

               SA:  IA
               DA:  KD
               SRL: JB,KC,LE
               SRP: 2

      At gateway D, the processing is similar.  The datagram leaves
      gateway D with its fields appearing:

               SA:  IA
               DA:  LE
               SRL: JB,KC,LD
               SRP: 3

      Finally, the datagram arrives at host E.  Even though the source
      route option is still present, host E knows it is the final
      destination, because the source route pointer now indicates that
      the source route list is exhausted.












Postel & Reynolds                                               [Page 4]
 
RFC DRAFT                                                      XXXX 1987


An Explicit Detailed Example

   Recall the format of the IP header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The format of the the source route option is shown in the extract from
RFC-791 in Appendix A.





























Postel & Reynolds                                               [Page 5]
 
RFC DRAFT                                                      XXXX 1987


   Example 3:

      Suppose that the source is host ISI-ARK, with address 128.9.0.12
      on ISI-NET, the destination is host DMC-CRC, with address
      128.43.0.1 on DRENET and the gateways to be explicitly passed
      through are ISI-WB-GW, LL-GW, and CRC-GW.  Each gateway has two
      addresses, one on each directly connected network.

      +-----+
      |     | 128.9.0.12
      |ISI  |-------
      |  ARK|     /ISI-NET
      +-----+    /
                /
               /
              /     +-----+                                                                 /      |ISI  | 28.45.0.0
             -------|  WB |-------
         128.9.0.25 |   GW|     /WBNET
                    +-----+    /
                              /
                             /    +-----+
                            /     |     | 10.5.0.10
                           -------|LL-GW|-------
                        28.19.0.0 |     |     /ARPANET
                                  +-----+    /
                                            /
                                           /    +-----+
                                          /     |     | 128.43.1.1
                                         -------|CRC  |-------
                                      10.1.0.15 |   GW|     /DRENET
                                                +-----+    /
                                                          /
                                                         /    +-----+
                                                        /     |     |
                                                       -------|DMC  |
                                                   128.43.0.1 |  CRC|
                                                              +-----+

      When the datagram is sent from the source host (ISI-ARK) into the
      Internet the Source Address (SA), Destination Address (DA), Source
      Route List (SRL), and Source Route Pointer (SRP) the fields are:

               SA:  128.9.0.12
               DA:  128.9.0.25
               SRL: 28.19.0.0, 10.1.0.15, 128.43.0.1
               SRP: 0





Postel & Reynolds                                               [Page 6]
 
RFC DRAFT                                                      XXXX 1987


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       128     |       9       |       0       |      12       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       128     |       9       |       0       |      25       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       137     |      15       |       4       |      28       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        19     |       0       |       0       |      10       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         1     |       0       |      15       |     128       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        43     |       0       |       1       |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      After the datagram arrives at gateway ISI-WB-GW, the gateway,
      notices the source route option and moves the address from the
      next element of the source route list to the destination field,
      places its own reverse direction address in the that element of
      the source route list, and increments the source route pointer.
      As the datagram leaves gateway ISI-WB-GW, the fields are:

               SA:  128.9.0.12
               DA:  28.19.0.0
               SRL: 28.45.0.0, 10.1.0.15, 128.43.0.1
               SRP: 1


















Postel & Reynolds                                               [Page 7]
 
RFC DRAFT                                                      XXXX 1987


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       128     |       9       |       0       |      12       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        28     |      19       |       0       |       0       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       137     |      15       |       8       |      28       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        45     |       0       |       0       |      10       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         1     |       0       |      15       |     128       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        43     |       0       |       1       |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






























Postel & Reynolds                                               [Page 8]
 
RFC DRAFT                                                      XXXX 1987


      At gateway LL-GW, the processing is similar.  The datagram leaves
      gateway LL-GW with its fields appearing:

               SA:  128.9.0.12
               DA:  10.1.0.15,
               SRL: 28.45.0.0, 10.5.0.10, 128.43.0.1
               SRP: 2

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       128     |       9       |       0       |      12       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        10     |       1       |       0       |      15       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       137     |      15       |      12       |      28       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        45     |       0       |       0       |      10       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         5     |       0       |      10       |     128       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        43     |       0       |       1       |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      At gateway CRC-GW, the processing is similar.  The datagram leaves
      gateway CRC-GW with its fields appearing:

               SA:  128.9.0.12
               DA:  128.43.0.1
               SRL: 28.45.0.0, 10.5.0.10, 128.43.1.1
               SRP: 3














Postel & Reynolds                                               [Page 9]
 
RFC DRAFT                                                      XXXX 1987


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       128     |       9       |       0       |      12       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       128     |      43       |       0       |       1       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       137     |      15       |      16       |      28       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        45     |       0       |       0       |      10       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         5     |       0       |      10       |     128       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        43     |       1       |       1       |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Finally, the datagram arrives at host DMC-CRC.  Even though the
      source route option is still present, host DMC-CRC knows it is the
      final destination because the source route pointer now indicates
      that the source route list is exhausted.

























Postel & Reynolds                                              [Page 10]
 
RFC DRAFT                                                      XXXX 1987


Summary *****-----> [words here]

References

   [1]   Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
         Protocol Specification," RFC 791, USC/Information Sciences
         Institute, September 1981.

   [2]   DoD Military Standard, "Internet Protocol", MIL-STD-1777,
         Department of Defense, August 1983.









































Postel & Reynolds                                              [Page 11]
 
RFC DRAFT                                                      XXXX 1987


Appendix A -- Extracts from RFC-791

   Note:  Editors notes and corrections are enclosed in angle brackets
   ("<", ">"), and text that should be deleted is enclosed in braces
   ("{","}").

   Loose Source and Record Route

         +--------+--------+--------+---------//--------+
         |10000011| length | pointer|     route data    |
         +--------+--------+--------+---------//--------+
          Type=131

      The loose source and record route (LSRR) option provides a means
      for the source of an internet datagram to supply routing
      information to be used by the gateways in forwarding the datagram
      to the destination, and to record the route information.

      The option begins with the option type code.  The second octet is
      the option length which includes the option type code and the
      length octet, the pointer octet, and length-3 octets of route
      data.  The third octet is the pointer into the route data
      indicating the octet which begins the next source address to be
      processed.  The pointer is relative to this option, and the
      smallest legal value for the pointer is 4.

      A route data is composed of a series of internet addresses.  Each
      internet address is 32 bits or 4 octets.  If the pointer is
      greater than the length, the source route is empty (and the
      recorded route full) and the routing is to be based on the
      destination address field.

      If the address in destination address field has been reached and
      the pointer is not greater than the length, the next address in
      the source route replaces the address in the destination address
      field, and the recorded route address replaces the source <route>
      address just used, and pointer is increased by four.

      The recorded route address is the internet module's own internet
      address as known in the environment into which this datagram is
      being forwarded.

      This procedure of replacing the source route with the recorded
      route (though it is in the reverse of the order, it must be in to
      be used as a source route) means the option (and the IP header as
      a whole) remains a constant length as the datagram progresses
      through the internet.




Postel & Reynolds                                              [Page 12]
 
RFC DRAFT                                                      XXXX 1987


      This option is a loose source route because the gateway or host IP
      is allowed to use any route of any number of other intermediate
      gateways to reach the next address in the route.

      Must be copied on fragmentation.  Appears at most once in a
      datagram.

   Strict Source and Record Route

         +--------+--------+--------+---------//--------+
         |10001001| length | pointer|     route data    |
         +--------+--------+--------+---------//--------+
          Type=137

      The strict source and record route (SSRR) option provides a means
      for the source of an internet datagram to supply routing
      information to be used by the gateways in forwarding the datagram
      to the destination, and to record the route information.

      The option begins with the option type code.  The second octet is
      the option length which includes the option type code and the
      length octet, the pointer octet, and length-3 octets of route
      dAata.  The third octet is the pointer into the route data
      indicating the octet which begins the next source address to be
      processed.  The pointer is relative to this option, and the
      smallest legal value for the pointer is 4.

      A route data is composed of a series of internet addresses.  Each
      internet address is 32 bits or 4 octets.  If the pointer is
      greater than the length, the source route is empty (and the
      recorded route full) and the routing is to be based on the
      destination address field.

      If the address in the destination address field has been reached
      and the pointer is not greater than the length, the next address
      in the source route replaces the address in the destination
      address field, and the recorded route address replaces the source
      <route> address just used, and pointer is increased by four.

      The recorded route address is the internet module's own internet
      address as known in the environment into which this datagram is
      being forwarded.

      This procedure of replacing the source route with the recorded
      route (though it is in the reverse of the order, it must be in to
      be used as a source route) means the option (and the IP header as
      a whole) remains a constant length as the datagram progresses
      through the internet.



Postel & Reynolds                                              [Page 13]
 
RFC DRAFT                                                      XXXX 1987


      This option is a strict source route because the gateway or host
      IP must send the datagram directly to the next address in the
      source route through only the directly connected network indicated
      in the next address to reach the next gateway or host specified in
      the route.

      Must be copied on fragmentation.  Appears at most once in a
      datagram.

   Record Route

         +--------+--------+--------+---------//--------+
         |00000111| length | pointer|     route data    |
         +--------+--------+--------+---------//--------+
           Type=7

      The record route option provides a means to record the route of an
      internet datagram.

      The option begins with the option type code.  The second octet is
      the option length which includes the option type code and the
      length octet, the pointer octet, and length-3 octets of route
      data.  The third octet is the pointer into the route data
      indicating the octet which begins the next area to store a route
      address.  The pointer is relative to this option, and the smallest
      legal value for the pointer is 4.

      A recorded route is composed of a series of internet addresses.
      Each internet address is 32 bits or 4 octets.  If the pointer is
      greater than the length, the recorded route data area is full.
      The originating host must compose this option with a large enough
      route data area to hold all the address expected.  The size of the
      option does not change due to adding addresses.  The intitial
       contents of the route data area must be zero.

      When an internet module routes a datagram it checks to see if the
      record route option is present.  If it is, it inserts its own
      internet address as known in the environment into which this
      datagram is being forwarded into the recorded route beginning at
      the octet indicated by the pointer, and increments the pointer by
      four.

      If the route data area is already full (the pointer exceeds the
      length) the datagram is forwarded without inserting the address
      into the recorded route.  If there is some room but not enough
      room for a full address to be inserted, the original datagram is
      considered to be in error and is discarded.  In either case, an
      ICMP parameter problem message may be sent to the source host [3].



Postel & Reynolds                                              [Page 14]
 
RFC DRAFT                                                      XXXX 1987


      Not copied on fragmentation, goes in first fragment only.  Appears
      at most once in a datagram.

















































Postel & Reynolds                                              [Page 15]
 
RFC DRAFT                                                      XXXX 1987


Appendix B -- Extracts from MIL-STD-1777

   Note:  Editors notes and corrections are enclosed in angle brackets
   ("<", ">"), and text that should be deleted is enclosed in braces
   ("{","}").

   9.2.1.2  Routing options.

      IP provides a mechanism, called source routing, to supplement the
      gateway's independent routing decisions.  This mechanism allows an
      upper layer protocol to influence the gateway route in which a
      datagram traverses.  The UPL can pass a list of internet
      addresses, called a source route list, as one of the SEND service
      request parameters.  Each address in the list, except for the
      last, is an intermediate gateway destination.  The last address on
      the list is the final destination.  The source IP module uses its
      normal routing mechanism to transmit the datagram to the first
      address in the source route list.  Then the gateway IP replaces
      source route list entry with its own address as known in the
      environment into which it is forwarding the datagram.  Thus, the
      datagram follows the source route while recording its "inverse" or
      recorded route.

   9.2.1.2.1 Routing types.

      Two kinds of source routing are proviced by IP: loose and strict.
      With loose source routing, the host and gateway IP modules along
      the route may use any number of other intermediate gateways to
      reach the addresses in the source list.  With strict source
      routing, the datagram must travel directly (i.e., through only the
      directly connected subnetwork indicated by each address) to each
      address on the source list.  When the source route cannot be
      followed, the source host IP is notified with an error message.
      For testing or diagnostic purposes, a ULP can acquire a datagram's
      record route (independent of the source route option) by using the
      record route mechanism.  The sending ULP supplies an empty record
      route list and indicates that the gateway route is to be recorded
      in transit.  Then, as each gateway IP module on the gateway route
      relays the datagram, it adds its address as known in the
      succeeding environment to the record route list.  The destination
      ULP receives the original datagram along with the record route
      list which, if reversed, provides a source route to the sending
      ULP.  If more gateways are traversed than can be recorded in the
      list, the additional gateway addresses are not recorded.  Problems
      with the record route option discovered in transit are reported to
      the source host IP.  When using a routing otion, the source ULP
      must provide a large enough route list to accommodate all the
      routing information expected.  The size of a routing option does



Postel & Reynolds                                              [Page 16]
 
RFC DRAFT                                                      XXXX 1987


      not change due to adding addresses.

   9.3.15.4 Loose source and record route.

      option type:  131   option length:  variable

      The loose source route option provides a way for the source ULP of
      a datagram to supply routing information to be used by IP modules
      along the gateway route.  At the same time, the "inverse" route is
      recorded in the option field.  This option {is not} <must be>
      copied on fragmentation.  It appears at most once in a datagram.
      The option begins with the option type code.  The second octet is
      the option length which includes the option type octet, the length
      octet, the pointer octet, and the source route list.  The third
      octet is a pointer into the route data indicating the octet which
      begins the next source address to be processed.  The pointer is
      relative to this option, and its smallest legal value is 4.  A
      loose source route list is composed of one or more internet
      addresses identifying intermediate gateways to be visited in
      transit.  Each internet address is 4 octets long.  When a gateway
      in the source route list is visited, the gateway address (as known
      in the environment into which the datagram is being forwarded)
      replaces that list entry <while that list entry replaces the
      destination address>.  The size of this option is fixed by the
      source.  It cannot change to accommodate additional information.
      The routing options are described in section {9.2.1.1} <9.2.1.2>.

   9.3.15.5 Strict source and record route.

      option type:  137   option length:  variable

      The strict source route option provides a way for the source ULP
      of a datagram to name the exact set of IP modules to be visited
      along the gateway route.  At the same time, the "inverse" route is
      recorded in the option field.  This option must be copied on
      fragmentation.  It appears at most once in a datagram.  The option
      begins with the option type code.  The second octet is the option
      length which includes the option type octet, the length octet, the
      pointer octet, and the source route list.  The third octet is a
      pointer into the route data indicating the octet which begins the
      next source address to be processed.  The pointer is relative to
      this option, and its smallest legal value is 4.  A strict source
      route list is composed of one or more internet addresses
      identifying the gateways to be visited in transit.  The datagram
      must visit exactly the gateways listed, traversing only the
      directly connected subnetworks indicated in the route list
      addresses.  When a gateway in the source route list is visited,
      the gateway address (as known in the environment into which the



Postel & Reynolds                                              [Page 17]
 
RFC DRAFT                                                      XXXX 1987


      datagram is being forwarded) replaces that list entry <while that
      list entry replaces the destination address>.  The size of this
      option is fixed by the source.  It cannot change to accommodate
      additional information.  Routing options are described in section
      {9.2.1.1} <9.2.1.2>.

   9.3.15.6 Record route.

      option type:  7   option length:  variable

      The record route option provides a way to record a datagram's
      gateway route.  This option is not copied on fragmentation.  It
      appears at most once in a datagram.  The option begins with the
      option type code.  The second octet is the option length which
      includes the option type code, the length octet, and the return
      route list.  The third octet is a pointer into the route data
      indicating the octet which begins the next area to store a route
      address.  The pointer is relative to this option, and the smallest
      legal value for the pointer is 4.  A record route list is composed
      of a series of internet addresses.  Each internet address is 4
      octets long.  The source ULP provides a route list with zero value
      entries.  As each gateway is visited in transit, it registers its
      address in the next free entry (indicated by the pointer).  When
      the pointer is greater than the length, the record route list is
      full.  No additional addresses are recorded, even if more are
      visited before arriving at the destination.  The size of this
      option is fixed by the source.  It cannot cnange to accommodate
      additional information.  The routing options are described in
      section {9.2.1.1} <9.2.1.2>.

   9.4.6.3.13 Route.

Editors' Notes


















Postel & Reynolds                                              [Page 18]

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      18 SEP 87 14:22-SYS
From:      mslagley%UCIVMSA.BITNET@wiscvm.wisc.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   List of TCP/IP software for various hosts
Received: from ORION by UCICP6 with PMDFm; 18 Sep 1987 14:13:21
Received: from localhost by orion.cf.uci.edu id a026076; 18 Sep 87 13:42 PDT
From: Mike Slagley <mslagley@orion.cf.uci.edu>
Date: Fri, 18 Sep 87 13:42:25 -0700
Sender: mslagley@orion.cf.uci.edu

We at University of California at Irvine we are constructing a list of
recommended TCP/IP software for users.

Those hosts not using Berkeley UNIX are the ones which need added
software.  Some of the most popular types are:

IBMPC + compatibles running DOS.  There are PC networks with Novell,
     3COMM, PC-NFS software.
Apple Macintosh, with Appletalk networks.
Vaxes + MicroVaxes running VMS.
PC's running OS/2 and UNIX System V will probably be popular.

If anybody else has a list already compiled of TCP/IP software
available for one or more hosts, we would appreciate getting a copy.

Information on individual programs would also be appreciated.  If
software is commercial it would also be nice to know an approximate
price.  Any comments about successful or unsuccessful use of software
or hardware would be helpful.

The list will be made available to others on request.

Thanks for any help:
Bitnet = MWSlagley%UCI                Mike Slagley
                                      Network and Telecommunications
                                      University of CA, Irvine, 92617

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 15:35:13 EDT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Question about IP options

Just how many datagrams in the Internet even carry options anyway? I
recently discovered that the implementation of source routing I did over
a year ago was buggy. Not because it didn't work in operation, but
because I re-read the spec the other night and realized I had done it
wrong.  I've never even seen a datagram with options.

It might seem that it's not really worth worrying much about performance
when processing IP options if they are that rare.

Phil

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 17:55:44 EDT
From:      mslagley@UCIVMSA.BITNET
To:        comp.protocols.tcp-ip
Subject:   List of TCP/IP software for various hosts

Received: from ORION by UCICP6 with PMDFm; 18 Sep 1987 14:13:21
Received: from localhost by orion.cf.uci.edu id a026076; 18 Sep 87 13:42 PDT
From: Mike Slagley <mslagley@orion.cf.uci.edu>
Date: Fri, 18 Sep 87 13:42:25 -0700
Sender: mslagley@orion.cf.uci.edu

We at University of California at Irvine we are constructing a list of
recommended TCP/IP software for users.

Those hosts not using Berkeley UNIX are the ones which need added
software.  Some of the most popular types are:

IBMPC + compatibles running DOS.  There are PC networks with Novell,
     3COMM, PC-NFS software.
Apple Macintosh, with Appletalk networks.
Vaxes + MicroVaxes running VMS.
PC's running OS/2 and UNIX System V will probably be popular.

If anybody else has a list already compiled of TCP/IP software
available for one or more hosts, we would appreciate getting a copy.

Information on individual programs would also be appreciated.  If
software is commercial it would also be nice to know an approximate
price.  Any comments about successful or unsuccessful use of software
or hardware would be helpful.

The list will be made available to others on request.

Thanks for any help:
Bitnet = MWSlagley%UCI                Mike Slagley
                                      Network and Telecommunications
                                      University of CA, Irvine, 92617

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Fri, 18-Sep-87 18:17:12 EDT
From:      david@varian.UUCP (David Brown)
To:        comp.protocols.tcp-ip
Subject:   CMU-TEK + DECnet?

Can anyone tell me what ethernet boards are supported in CMU-TEK
TCP/IP?  We're interested in using DEC boards (DEUNA, DELUA, DEQNA).
Can CMU-TEK be run simlutaneously with DECnet?

Thanks in advance

-- 
David Brown	 (415) 945-2199
Varian Instruments 2700 Mitchell Dr.  Walnut Creek, Ca. 94598
{ptsfa,lll-crg,zehntel,dual,amd,fortune,ista,rtech,csi,normac}!varian!david

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Sat, 19-Sep-87 00:11:25 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Clockwatchers beware

Louie,

Things do seem better, although last night (before you redrived?) I noticed
a few timewarps between umd1 and udel1. Note that the Linkabit clock has
frozen again. They won't fix it, since that costs money, so Woody is
reduced to conking it with a wrench, which sometimes even wakes it up.

Dave

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Sep-87 08:26:42 EDT
From:      david@geac.UUCP (David Haynes)
To:        comp.protocols.tcp-ip
Subject:   Re: Benchmarks for high-level protocols

In article <1514@sics.se> erikn@sics.se (Erik Nordmark) writes:
>Sender: 
>Reply-To: erikn@sics.se (Erik Nordmark)
>Followup-To: 
>Distribution: world
>Organization: Swedish Institute of Computer Science, Kista
>Keywords: benchmark performance
>
>To my knowledge the standard way of comparing protocol performance
>is to transfer a large file between two machines using the different 
>protocols.
>
>My question to the net is if anybody uses more sophisticated benchmarks
>that take into account e.g. real-time communication, transaction-style
>communication, the overhead for multiple connections, the protocol's 
>ability to handle packet loss due to the sender(s) overrunning the 
>receiver et.c. et.c.
>(Pointers to any litterature on the topic are appreciated too!)
>
>If the response to this message is significant I'll summarize to the net!
>
>-------------------------------------------------------------------------
>Erik Nordmark

I have been using a home-brew version of the "ping" program to
test the relative performance of STREAM and DATAGRAM messages
in the UNIX and INTERNET domains of BSD unix.

Primarily, the code asks for a packet size and the number of
messages to be sent and then sets up a bounce-back type
connection between the server and the client.

Time is taken to complete all the messages and the throughput
in messages per second and bytes per second are taken.

Modifications I want to make (if I ever get the time :-)) are
to allow for different sized packets (random and double-bell
curve distribution) and to have the packet carry some of the
timing information.

As a second test, I have almost completed the internet version
of Stonebreakers' concurrency control model for (relational)
databases. The UNIX domain version works just fine. The idea
is to have a client process which simulates a "user" or a
number of users entering transactions of various size and length.
The actual properties of these users can be configured by
the tester. The system then moves the transactions through the
concurrency controller model and performs such things as
re-tries, transaction commits, transaction aborts, etc.
until all transactions are completed. (Actually, the model
runs forever as it sits now, we just watch it run for the
first 1,000 transactions or so and see how it doing.)

The entire system is controlled via a master clock which
simulates the system clock in a machine.

The whole system requires the co-operation of 19 distict processes.

This, I think, makes a nice benchmark set for any message-based 
communications system.

-david-
-- 
David Haynes                          [ mnetor, yetti, utgpu] ! geac ! david
Geac Computers International Inc.          Wise words in mouths of fools
350 Steelcase Road,Markham, Ontario,       do oft themselves belie.
CANADA, L3R 1B3    +1 416 475 0525 x 3420

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Sun, 20-Sep-87 14:00:11 EDT
From:      ksand@mapper.UUCP (Kent Sandvik++)
To:        comp.protocols.tcp-ip
Subject:   Re: Unisys 5000, Unix, and TCP/IP

In article <8709041300.AA05135@ucbvax.Berkeley.EDU> AFDDN.TCP-IP@GUNTER-ADAM.ARPA writes:
>
>   Just a request for any information out there.  Does anybody have any
>experience with internetting Unisys 5000s?  These beasts run some flavor
>of Unix.  The words filtering through the grapevine are that Unisys
>wrote TCP/IP, FTP, SMTP and Telnet from scratch, and that there are a few
>problems with it.  Any comments are welcome.
>Darrel Beach
>-------

Yeah, we beasts run an ugly UNIX flavour called SysV, yacky :-).
Also the internetworking comes from Excelan as an OEM product, and those
guys wrote TCP/IP also for VMS and Sun machines. I think there are a few
problems, but there are always problems with all software in general.

I've tested the r-series commands (rsh, rcp, rlogin) to a VAX running 4.2 BSD,
and also the ftp and telnet to SUN:s and Apollo workstations. We found
*one* bug in connection with a Bridge Server and telnet (a minor one),
and this was corrected in the latest release.

Don't trust the grapevine, man...

					-Kent Sandvik-
-- 
|COMPRESSED SIGNATURE:ADDRESS:Vallgatan7,17191SolnaSwedenPHONE:+46 8-551639| 
|job,-7333235 homeARPA:enea!mapper!ksand@seismo.arpa UUCP:ksand@mapper.UUCP|
|Thrue Utopia Fan\007.Telex-to-work:10499.Looking-for-other-ROLAND-D-50-own|
|ers.DOB:600418.Discl:They just don't know(Oliver North).FIAWOL.Oh, shitEOT|

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Sep-87 16:59:27 EDT
From:      fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor)
To:        comp.protocols.tcp-ip
Subject:   RIP congestion woes......


	Hi people.  Recently here at cornell we have been
	experiencing a number of strange routing problems.
	Routes on certain vaxen gateways were being mysteriously
	timed out, while other dedicated gateway boxes seemed
	fine.  Here at Cornell, we use RIP and everything is
	dynamic.  We have Proteon P4200's and vaxen running
	gated/routed for gateways.

	Our ARPAnet gateway, CU-ARPA was one of the victims of this
	problem.  CU-ARPA is a vax750 with 2 DEUNA's and one Pronet-10
	interface.  CU-ARPA also has an ARPAnet interface.

	After pulling my hair out and checking the routing software, I
	noticed that our vax was experiencing RIP congestion and couldn't
	keep up with all the RIPpers on its networks.

	On its Pronet 10 interface we have approx 11 RIPpers.
	On 1 of its Ethernet interfaces we have approx 7 RIPpers.
	on the other Ethernet interface we have 2 RIPpers.

	Plus, since we have a large number of networks being RIPped
	around, each gateway sends out 3 RIP packets for a complete update.

	The routing process opens one socket and listens on the
	RIP port.  If I read the UDP code right, each socket
	allocates space for 4k of datagrams.  CU-ARPA is
	easily dropping RIP packets left and right.

	Has anyone else experienced this?  Any suggestions?  I suppose
	I could increase "udp_recvspace" in netinet/udp_usrreq.c,
	but that would only prolong the agony.  I know, I know,
	get a real machine for a gateway..... :^)

	Thanks.

	Mark

	P.S.  Not suprisingly, the Proteon P4200 is having no problems.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Sep-87 18:12:56 EDT
From:      kurt@hi.UUCP (Kurt Zeilenga)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   DSU/CSU units

Well, now I need info on good DSU/CSU units for T1.  Any
information on good vendors would be greatly appreciated.

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 87 15:17:25 GMT
From:      rti!xyzzy!meissner@mcnc.org  (Michael Meissner)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  HELP: select() under sockets
In article <8709091653.AA15944@topaz.rutgers.edu> ron@topaz.rutgers.EDU (Ron Natalie) writes:
> The other arguments to select are pointers to bit fields so assumably
> 
> char	buf[10];
> 
> 	select(80, buf, (char *) 0, (char *) 0, (char *) 0, (time_t) 0)
> 

In 4.2 systems the three pointer arguments are pointers to INT's, not char's.
In 4.3 this was changed to be the type fd_set (declared in sys/types.h), which
is a structure big enough to hold 256 file descriptors, with a way to expand
it further.  In no case is a character array used.  This may be seen as picking
nits, but it becomes important on machines that have different representations
for pointers to char's and other pointers.
-- 
Michael Meissner, Data General.		Uucp: ...!mcnc!rti!xyzzy!meissner
					Arpa/Csnet:  meissner@dg-rtp.DG.COM
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Mon, 21-Sep-87 21:36:29 EDT
From:      sklower@RENOIR.BERKELEY.EDU (Keith Sklower)
To:        comp.protocols.tcp-ip
Subject:   Re:  RIP congestion woes......

In his message of Mon, 21 Sep 87 16:32:08 -0400, Mark Fedor
<fedor@devvax.tn.cornell.edu> writes:


:        The routing process opens one socket and listens on the
:        RIP port.  If I read the UDP code right, each socket
:        allocates space for 4k of datagrams.  CU-ARPA is
:        easily dropping RIP packets left and right.
: 
:        Has anyone else experienced this?  Any suggestions?  I suppose
:        I could increase "udp_recvspace" in netinet/udp_usrreq.c,
:        but that would only prolong the agony.

In fact, this has been noticed here at Berkeley as well.  It is possible
in 4.3 unix to increase the buffering for a particular datagram socket,
and the current version of routed has been changed to do that to circumvent
this problem.  (There have been other changes since 4.3, but Mike Karels
is traveling, and will not be able to supply a definitive statement about
which are worth incorporating until his return).

In the meantime, you can apply this patch to routed/main.c:
*** main.c.fix  Mon Sep 21 18:22:13 1987
--- main.c      Mon Sep 21 18:19:11 1987
***************
*** 186,195 ****
                close(s);
                return (-1);
        }
-       on = 48*1024;
-       if (setsockopt(s, SOL_SOCKET, SO_RCVBUF, &on, sizeof (on)) < 0)
-               syslog(LOG_ERR, "setsockopt SO_RCVBUF: %m");
- 
        if (bind(s, sin, sizeof (*sin), 0) < 0) {
                perror("bind");
                syslog(LOG_ERR, "bind: %m");
--- 186,191 ----

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22 Sep 87 10:19:19 CDT
From:      Bryan McWilliams <OPRBBDM%TCSVM.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: DSU/CSU units
Kurt,  In response to request for CSU/DSU   Go with Verilink.  you can
order them through DCA direct at 404-442-4244.   They're 2395.00 each, but
if you can get the educational discount you'll save another 30%.

Bryan McWilliams
Manager, Network Services
Tulane University
OPRBBDM@TCSVM
504-865-5631
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Sep-87 09:22:15 EDT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re:  DSU/CSU units

Kurt,

We have been using the AVANTI Tpac DSU/CSU multiplexer for over a year
with good results.  If you need more info contact me directly.


					-- Sergio

-----------------------------------------------------------------------------
Sergio Heker				tel:	(609) 520-2000
Internet: "heker@jvnca.csc.org"		Bitnet:	"heker@jvnc"
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
-----------------------------------------------------------------------------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Sep-87 11:19:19 EDT
From:      OPRBBDM@TCSVM.BITNET (Bryan McWilliams)
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

Kurt,  In response to request for CSU/DSU   Go with Verilink.  you can
order them through DCA direct at 404-442-4244.   They're 2395.00 each, but
if you can get the educational discount you'll save another 30%.

Bryan McWilliams
Manager, Network Services
Tulane University
OPRBBDM@TCSVM
504-865-5631

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 87 12:33:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Cc:        enger
Subject:   DSU/CSU units
We have a couple of T1 circuits, but the equipment on the ends functions
as its own "DSU", so all that is required are outboard CSU units.

We use Digital Link Corp. Model 551C.
I think we have had three blow out so far.  And a fourth leaked span power
to its chasis!  It turns out they had problems with the physical construction
of the units.  A bolt came very close to the circuit board and often shorted
or arcked during electrical storms, etc.  The factory supposedly installed
an engineering modification (cutting the excess off of the bolts probably)
to lower the likelyhood of lightning damage.  When one of the units came back 
from getting "the fix", its Percent Error Free Seconds display simply counted 
down constantly.  

The Error Free seconds display is a nice feature.  It keeps an "objective" 
eye on the status of the line.  Makes it real easy to point the finger at the 
phone company.  Other than span power outages due to lightning blowing the 
CO fuses, the only problem I have ever had with the T1s was a bad punch at 
the undergroud, and the CSU EFS display showed it as an excessive error rate, 
and indicated which direction the problem was in.  The local operating 
company fixed it promptly, no questions asked.  They took one look at the 
display on the csu, and went to work on the span.  

If you wish to contact them, Digital Link is in Sunnyvale, Ca
Phone number 408-745-6200

Good luck,
bob


From:	GBURG::ENGER        "Robert M. Enger {CONTEL Fed. Sys} (301)840-4906" 22-SEP-1987 12:42
To:	GBURG::MAILER,ENGER       
Subj:	RE: [TCP/IP Mail From: <weidlich@ludwig.scc.com>] ludwig non-functional when net is down

I don't "think" the ypbind has anything to do with the iebark reset.
I'll check into it.
bob
 (I think rebooting the machine is what cleared your problem??)
bob
------
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Sep-87 13:33:00 EDT
From:      enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To:        comp.protocols.tcp-ip
Subject:   DSU/CSU units

We have a couple of T1 circuits, but the equipment on the ends functions
as its own "DSU", so all that is required are outboard CSU units.

We use Digital Link Corp. Model 551C.
I think we have had three blow out so far.  And a fourth leaked span power
to its chasis!  It turns out they had problems with the physical construction
of the units.  A bolt came very close to the circuit board and often shorted
or arcked during electrical storms, etc.  The factory supposedly installed
an engineering modification (cutting the excess off of the bolts probably)
to lower the likelyhood of lightning damage.  When one of the units came back 
from getting "the fix", its Percent Error Free Seconds display simply counted 
down constantly.  

The Error Free seconds display is a nice feature.  It keeps an "objective" 
eye on the status of the line.  Makes it real easy to point the finger at the 
phone company.  Other than span power outages due to lightning blowing the 
CO fuses, the only problem I have ever had with the T1s was a bad punch at 
the undergroud, and the CSU EFS display showed it as an excessive error rate, 
and indicated which direction the problem was in.  The local operating 
company fixed it promptly, no questions asked.  They took one look at the 
display on the csu, and went to work on the span.  

If you wish to contact them, Digital Link is in Sunnyvale, Ca
Phone number 408-745-6200

Good luck,
bob

 
From:	GBURG::ENGER        "Robert M. Enger {CONTEL Fed. Sys} (301)840-4906" 22-SEP-1987 12:42
To:	GBURG::MAILER,ENGER       
Subj:	RE: [TCP/IP Mail From: <weidlich@ludwig.scc.com>] ludwig non-functional when net is down

I don't "think" the ypbind has anything to do with the iebark reset.
I'll check into it.
bob
 (I think rebooting the machine is what cleared your problem??)
bob
------

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Sep-87 13:41:25 EDT
From:      mike@bucasb.bu.edu (Michael Cohen)
To:        comp.protocols.tcp-ip,comp.os.vms,comp.unix.wizards,comp.unix.questions
Subject:   Secure Telnet/FTP

Is there a version of telnet/ftp running under VMS which runs in
such a way so that access can be restricted to certain users.
This is a query for someone running telnet/ftp a secure site,
and is unable to run it in standard configuration at his site
because password security is not enough.  Thanks much for your response

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Sep-87 18:07:29 EDT
From:      pvm@VENERA.ISI.EDU (Paul Mockapetris)
To:        comp.protocols.tcp-ip
Subject:   Change in root servers

The root server set for the domain system will change in October.

The C.ISI.EDU machine is going to its just reward, and its name server
will stop some time in October.  Toast its demise with a root bier.  The
NIC will remove it from the domain database approximately one week in
advance.  Gunter-Adam.arpa will join the official set of root servers
before C's demise.

As a more long term solution, shakedown of several new root servers
"closer" to the east coast, NSFnet, etc is underway, and should be
provide a long term solution.

paul

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Tue, 22-Sep-87 21:46:43 EDT
From:      eshop@saturn.ucsc.edu (Jim Warner)
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

In article <8709221539.AA06394@ucbvax.Berkeley.EDU> OPRBBDM@TCSVM.BITNET (Bryan McWilliams) writes:
>Kurt,  In response to request for CSU/DSU   Go with Verilink.  you can
>order them through DCA direct at 404-442-4244.   They're 2395.00 each, but
>if you can get the educational discount you'll save another 30%.
>
I wish I could be so positive about Verilink.  It looks like they
are nothing but trouble from my perspective.  Ours get into funny
states which they can't recover from without pulling the plug.  I
mean that literally.  They have no on/off switch or reset button.
The factory recommendation to unjam one of these things is to pop
the modules out with the power on.  That grates.  There's not even
a button to force it out of loopback mode (again - just pull the 
plug). 

I wish I could be more specific about what "funny states" means.
What we think happens is that something happens to a phone circuit
that causes a lot of errors.  After several hours of whatever
mistreatment the phone co has to offer, the Verilink finally gets
confused, looses sync and locks up.  After the phone line has
gotten good again, the Verilink doesn't recover by itself.

Besides that, they break a lot.  We're working on our third unit 
this year.  

Another thing that's been a headache is their 8ZBS encoding.  While
the encoding itself isn't a problem, the equipment that our telco
gives its people sees a circuit that is working perfectly as having
thousands of errors per second.  In fairness to Verilink, this
last point is mostly a telco problem, but the bottom line is that
our phone co can't passively monitor our line to tell us what it
looks like from their perspective.   That hurts. 

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 87 10:25:00 PDT
From:      "Jerry Scott" <jerry@twg.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Put me on the list
Sorry to bother the net with this but requests to tcp-ip-request seem
to not be heard.  Please add address
	<tcp-ip@twg.arpa>
to this distribution list.

Thanks,
Jerry Scott
------
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 08:41:40 EDT
From:      BDK@UNB.BITNET
To:        comp.protocols.tcp-ip
Subject:   PCP/IP

As a potential new user of TCP and IP I would like to get some info
on PCP/IP. What is it and where can I get a copy?

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1987 10:55:51 CDT
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA
To:        tcp-ip@SRI-NIC.ARPA
Cc:        AFDDN.TCP-IP@GUNTER-ADAM.ARPA
Subject:   Can of worms revisited
To anyone who might know, especially Andy or Sharon,

  I've been trying to get someone(mostly DCA) to specify to me exactly
what a "packet" is in terms of the billing algorithm.  Since the
billing algorithm is based on the traffic stats gathered by the PSN's,
I'm really asking what are the packets reflected on the throughput
reports.  I make the differentiation between X.25 packets which can be
anywhere from 128 to 1024 bytes, and the subnet "packets" passed between
E-to-E in the PSNs.  If memory serves me, the EE's break "messages"
into 128 byte subnet "packets" for sending thru the backbone.  X.25 packets,
(basic that is) are viewed as messages, therefore a 1024 byte X.25 packet
is 8 subnet "packets".  With standard X.25, your message is a complete
packet sequence and is actually now the length of you IP datagrams.  But
the the datagram is still broken into 128 byte "packets" by EE.
  If all this is true then a you could calculate the minimum number of
"packets" to send x number of bytes thru the network.  Not really that easy,
but a place to start.
Darrel Beach
AF DDN PMO
-------
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Sep 87 11:06:34 CDT
From:      Bryan McWilliams <OPRBBDM%TCSVM.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: DSU/CSU units
I'm sorry to hear about your Verilink problems.  Were I suffering the same
difficulty I surely would not have recommended the box.  One question, are
you span powered?  South Central Bell (in Louisiana) provides T-1 via fiber
only, so my boxes are powered by standalone 48 v. power supplies from
Tellabs.  You may be taking some hits on the span if that's where your D.C
is coming from.  We test our line with firebird sets, and they show zero
errors.  The gear the phone company uses is not nearly as sophisticated
(at laest in our region).  I've had 2 verilink 551V models running absolutely
flawlessly for 10 months now.  From my perspective it's an excellent unit.
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23 Sep 87 13:51:08 -0400
From:      Andy Malis <malis@CC5.BBN.COM>
To:        AFDDN.TCP-IP@GUNTER-ADAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA, malis@CC5.BBN.COM
Subject:   Re: Can of worms revisited
Darrel,

I'm afraid I'm not going to be able to be much of a help.  You
really are going to have to get the billing algorithm from DCA.

The PSN is quite flexible in what it reports with regards to host
traffic.  For accounting purposes, it reports both octet and
"segment" counts, where a segment is a configurable (power of 2)
number of octets.  When a host sends a message (X.25 "packet"),
the number of octets and segments in that message are added to
running totals (a partial segment counts as a segment), and these
running totals are periodically reported to the MC.

Thus, what gets reported and billed depends on the billing
algorithm and the PSN configuration settings used by DCA.

Regards,
Andy
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 11:55:51 EDT
From:      AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Can of worms revisited

To anyone who might know, especially Andy or Sharon,

  I've been trying to get someone(mostly DCA) to specify to me exactly
what a "packet" is in terms of the billing algorithm.  Since the
billing algorithm is based on the traffic stats gathered by the PSN's,
I'm really asking what are the packets reflected on the throughput
reports.  I make the differentiation between X.25 packets which can be
anywhere from 128 to 1024 bytes, and the subnet "packets" passed between
E-to-E in the PSNs.  If memory serves me, the EE's break "messages"
into 128 byte subnet "packets" for sending thru the backbone.  X.25 packets,
(basic that is) are viewed as messages, therefore a 1024 byte X.25 packet
is 8 subnet "packets".  With standard X.25, your message is a complete
packet sequence and is actually now the length of you IP datagrams.  But
the the datagram is still broken into 128 byte "packets" by EE.
  If all this is true then a you could calculate the minimum number of
"packets" to send x number of bytes thru the network.  Not really that easy,
but a place to start.
Darrel Beach
AF DDN PMO
-------

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 12:06:34 EDT
From:      OPRBBDM@TCSVM.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

I'm sorry to hear about your Verilink problems.  Were I suffering the same
difficulty I surely would not have recommended the box.  One question, are
you span powered?  South Central Bell (in Louisiana) provides T-1 via fiber
only, so my boxes are powered by standalone 48 v. power supplies from
Tellabs.  You may be taking some hits on the span if that's where your D.C
is coming from.  We test our line with firebird sets, and they show zero
errors.  The gear the phone company uses is not nearly as sophisticated
(at laest in our region).  I've had 2 verilink 551V models running absolutely
flawlessly for 10 months now.  From my perspective it's an excellent unit.

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 13:18:00 EDT
From:      CERF@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms revisited

Public data nets in the U.S.  and in other countries, utilizing
X.25 and X.75, have chosen an accounting fiction, the "segment"
as a way to deal with variance in actual and in maximum packet
sizes.

Exchange tariffs and user tariffs are based on the number of
segments sent or received by a particular pair of parties.
Typically the bill is accumulated against the originator of the
virtual circuit although reverse charging is permitted; usually
only domestically as international reverse charge calls are
sometimes hard to collect for.

The public network administration announces the segment size (in
octets) and the charges are for the number of octets sent on a
given virtual circuit.  If a packet contains less than one
segment's worth or an integral number plus a fraction of
segments, the accounting is rounded up to the nearest segment for
that packet.

Between administrations that normally charge for service using
DIFFERENT segment sizes, there is an agreement at the X.75
interconnect on an interexchange segment size for purposes of
calculating balances due between each administration.  Charges to
users are up to each domestic public data net - some stick with
their standard domestic segment size and some use the smaller of
the domestic and the size for going to the target administration.
This assumes, of course, that the target administration's network
is "one hop" from the originating network.  There are cases of
transit nets, and these require 3-way negotiations to determine
how much of the user charges will be shared by each
administration.

In the case of datagram systems, similar segment size accounting
methods can be used - binding the charges to a particular user
rather than to a host might be the easier path since datagrams
often don't have user level identifying information in them.l

Vint Cerf

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 1987 13:18-EDT
From:      CERF@A.ISI.EDU
To:        AFDDN.TCP-IP@GUNTER-ADAM.ARPA
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Can of worms revisited
Public data nets in the U.S.  and in other countries, utilizing
X.25 and X.75, have chosen an accounting fiction, the "segment"
as a way to deal with variance in actual and in maximum packet
sizes.

Exchange tariffs and user tariffs are based on the number of
segments sent or received by a particular pair of parties.
Typically the bill is accumulated against the originator of the
virtual circuit although reverse charging is permitted; usually
only domestically as international reverse charge calls are
sometimes hard to collect for.

The public network administration announces the segment size (in
octets) and the charges are for the number of octets sent on a
given virtual circuit.  If a packet contains less than one
segment's worth or an integral number plus a fraction of
segments, the accounting is rounded up to the nearest segment for
that packet.

Between administrations that normally charge for service using
DIFFERENT segment sizes, there is an agreement at the X.75
interconnect on an interexchange segment size for purposes of
calculating balances due between each administration.  Charges to
users are up to each domestic public data net - some stick with
their standard domestic segment size and some use the smaller of
the domestic and the size for going to the target administration.
This assumes, of course, that the target administration's network
is "one hop" from the originating network.  There are cases of
transit nets, and these require 3-way negotiations to determine
how much of the user charges will be shared by each
administration.

In the case of datagram systems, similar segment size accounting
methods can be used - binding the charges to a particular user
rather than to a host might be the easier path since datagrams
often don't have user level identifying information in them.l

Vint Cerf
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 13:22:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

Sorry to seem dense, but I thought the idea behind 8ZBS was to force
some ones in the stream to maintain sync - but that this was done in
a way which the telco did NOT see anything funny. The telco equipment
usually requires that there be some 1s in the data stream every so
often to assure clock synchronization. If a data stream threatens to
send a long sequence of zeros (as a crypto stream might), one puts in
a gadget that will convert 8 zeroes into a different bit pattern, and
on the receiving side, turn them back into zeroes. Why would the telco
see that as lots of line errors?

Vint Cerf

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 13:25:00 EDT
From:      jerry@TWG.ARPA ("Jerry Scott")
To:        comp.protocols.tcp-ip
Subject:   Put me on the list

Sorry to bother the net with this but requests to tcp-ip-request seem
to not be heard.  Please add address
	<tcp-ip@twg.arpa>
to this distribution list.

Thanks,
Jerry Scott
------

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 15:53:19 EDT
From:      ROODE@BIONET-20.ARPA (David Roode)
To:        comp.protocols.tcp-ip
Subject:   PC Telnet with Tek Graphics emulator

We have need of a PC Telnet implementation which includes
having the terminal emulation component cover Tektronics
4014-style graphics.  Since this is a quite common feature
in terminal emulators for an RS232 port, it seems
reasonable that it would be available for TCP Telnet
as well.  Does anyone have any pointers?
-------

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 16:19:19 EDT
From:      hubcap@hubcap.UUCP (Mike S Marshall)
To:        comp.protocols.tcp-ip
Subject:   VMS 4.6 and WIN/TCP

We received VMS 4.6 the other day. We run Wollongonk's WIN/TCP 3.0 on
our VMS VAXen. I am responsible for WIN/TCP's operation. The sysadmin
for the VMS machines is trying to anticipate what might break when she
does the OS upgrade. She asked me to find out what I could about the 
compatibility of WIN/TCP and VMS 4.6.

So now I'm asking you guys... has anyone that is using WIN/TCP upgraded to
VMS 4.6? If so, did you experience any problems?

thanks in advance.

-Mike Marshall          hubcap@hubcap.clemson.edu      ...!hubcap!hubcap

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      Wed, 23-Sep-87 22:37:55 EDT
From:      jas@MONK.PROTEON.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   DSU/CSU units

(This may be a little rusty, since I'm not near my PUB's, but I think
I've got the spirit, if not the letter, right.)

T1 coding is trilevel, with levels I will call -1, 0, and +1.  A bit
of "zero" is always represented as 0.  A bit "one" of will will be
represented as -1 if the last "one" was +1, and as +1 if the last
"one" was -1.

T1 uses regenerative reclocking repeaters along the line.  They
require flux transitions to ge the clock out of.  If they don't get
enough, they lose it.  To get transitions, you've got to send some
"one"'s.  This is why the rule of no more than 7 (?) "zero"'s in a
row.

B8ZS avoids this by putting a code violation in the bit cell for the
8th "zero".  Thus, if the last "one" was -1, the 8th "zero" will be
-1, and if the last "one" was +1, the 8th "zero" will be +1.

This offends Central Offices, who constantly check for code
violations.  This one way they decide the line is sick.  The nation
may not be fully B8ZS safe for another decade.

Many CSU/DSU's offer to run without B8ZS.  They use different schemes
to put your raw sync data on the T1 line without needing B8ZS to
provide data transparency.  Their price is usually correlated with how
many bits they waste doing this, and how high a clock rate you get at
the sync (RS-449) interface.

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 00:23:27 EDT
From:      malis@CC5.BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms revisited

Darrel,

I'm afraid I'm not going to be able to be much of a help.  You
really are going to have to get the billing algorithm from DCA.

The PSN is quite flexible in what it reports with regards to host
traffic.  For accounting purposes, it reports both octet and
"segment" counts, where a segment is a configurable (power of 2)
number of octets.  When a host sends a message (X.25 "packet"),
the number of octets and segments in that message are added to
running totals (a partial segment counts as a segment), and these
running totals are periodically reported to the MC.

Thus, what gets reported and billed depends on the billing
algorithm and the PSN configuration settings used by DCA.

Regards,
Andy

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 00:55:46 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re: PCP/IP


    From:        BDK%UNB.BITNET@wiscvm.wisc.edu

    As a potential new user of TCP and IP I would like to get some info
    on PCP/IP. What is it and where can I get a copy?

I am guessing that you meant "PC/IP".  This is a set of user TCP/IP
utilities for MS/DOS PCs originally written at MIT some years back,
and released as freeware.  You can get a version from the MIT Microcomputer
Office (source or binary, but the source requires a cross-compiler which
you need a 4BSD source license to obtain).  You can get another version
from CMU, ported to Microsoft C and with various improvements.  You can
get commercialized, enhanced & supported versions of it from various
suppliers (we're proud of the ancestry of ours...).  Most of them are
listed in the "Vendor's Guide", available electronically or printed from
the people at SRI.

You can get lots more information by joining the mailing list devoted to
PC/IP and its descendants:  pc-ip@huey.udel.edu.

James VanBokkelen
FTP Software Inc.

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 05:12:20 EDT
From:      fedor@DEVVAX.TN.CORNELL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   gated 1.3.1 available now!



	The newest version of gated can be obtained by
	anonymous FTP from devvax.tn.cornell.edu.
	The distribution is in the file ~ftp/pub/gated/gated.tar
	or compressed as ~ftp/pub/gated/gated.tar.Z

	So my little VAX-750 doesn't get bogged down, I also have
	it available on nic.nyser.net.  Same access method and same
	files.

	If for some reason you can't grab gated over the internet,
	UUCP could be arranged, but until I hear some requests, I
	won't worry about it.

	Maybe I'll post to mod.sources or something.....

	read the README file for info on joining the bugs/update
	gated mailing list.

	Cheers,

	Mark

	P.S.  those of you which sent me tapes, they were sent out.

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 07:43:00 EDT
From:      BEAME@MCMASTER.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: PC Telnet with Tek Graphics emulator


Many people require terminal emulators that exist in the RS232 realm to
work on Telnet. One solution to this problem is the product BWCOM from
Beame & Whiteside software Ltd. . It allows interupt driven RS232
terminal emulators to run Telnet over an ethernet. The serial terminal
emulator thinks it's talking to a Hayes compatible modem.


 - Carl Beame
   BEAME@MCMASTER.BITNET

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24 Sep 87 07:43 EDT
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: PC Telnet with Tek Graphics emulator

Many people require terminal emulators that exist in the RS232 realm to
work on Telnet. One solution to this problem is the product BWCOM from
Beame & Whiteside software Ltd. . It allows interupt driven RS232
terminal emulators to run Telnet over an ethernet. The serial terminal
emulator thinks it's talking to a Hayes compatible modem.


 - Carl Beame
   BEAME@MCMASTER.BITNET
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 10:16:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

In the early days of digital voice, when T1 was invented, I recall
that every 8th bit of each 24 channel sequence (192 bits total) was
a 1 for signalling/sync purposes. That coding gave you only 56 kb/s
of digital information, but avoided any problems with regeneration.

Over time, the need for such signalling went down (after all, 1/8
of each channel was 8 kb/s which is a lot just for signalling).
It sounds as if the coding trinary coding scheme didn't account
for arbitrary data passing through repeaters. Sigh.

Vint

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 10:20:21 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms revisited

Vint--

Shades of the October, 1971 Network Working Group meeting!  Not positive
you were there (seem to think so, but Early Middle Age does funny things
to the memory, as we saw the other week in re the "But My NCP Costs
$500 a Day..." RFC), so for the List's benefit at least and maybe
yours as well, the relevant incident was that at one point Larry
Roberts said that ARPA's intention was eventually to be charging
30 cents a kilo-packet and Frank Heart called out "Don't you mean 30
cents a mega-bit?"; Larry replied that he really maent 30 cents a
kilo-packet and there was a small round of applause from those of us
whose Hosts were line-at-a-time rather than character-at-a-time by
nature.  (For the benefit of non-oldtimers, Larry was head of ARPA's
Information Processing Techniques [or Technology--but I always got
confused over that even before EMA] Office at the time [a/k/a Our
Sponsor] and Frank was either still a Division Head at BBN or maybe
already a VP [I think the former, but ...].)

It sure sounds to me as if the time has finally come when we really
have to deal with the Remote Controlled Echoing issue, in light of
the apparent return of the point of view which holds that it doesn't
matter whether you've got one word or several pages in the metaphorical
envelope, it still requires a metaphorical stamp.  As you know
(but as I'm not sure it's proper to go into detail about on the List),
I'm not in a position to volunteer to head up an ad hoc working
group on RCTE (T for Terminal, as I recall) at present, but I'd
certainly urge somebody to step forward and I'd be glad to offer
whatever help I'm in a position to offfer when it gets going, or
even, if it makes the pot sweeter, to offer to stay out of it
entirely, if that's what it takes to get a volunteer.  If Dave
Clark is watching, perhaps he'd like to do the convening, or
mabye it's within the purview of one of the existing task forces,
but in any event it does seem that if there's a clear and present
danger of having to pay per character for all the character-at-a-time
transmissions it's incumbent on us to decrease the number of
those transmissions.

cheers, map
-------

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1987 10:20:21 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        CERF@A.ISI.EDU
Cc:        AFDDN.TCP-IP@GUNTER-ADAM.ARPA, tcp-ip@SRI-NIC.ARPA
Subject:   Re: Can of worms revisited
Vint--

Shades of the October, 1971 Network Working Group meeting!  Not positive
you were there (seem to think so, but Early Middle Age does funny things
to the memory, as we saw the other week in re the "But My NCP Costs
$500 a Day..." RFC), so for the List's benefit at least and maybe
yours as well, the relevant incident was that at one point Larry
Roberts said that ARPA's intention was eventually to be charging
30 cents a kilo-packet and Frank Heart called out "Don't you mean 30
cents a mega-bit?"; Larry replied that he really maent 30 cents a
kilo-packet and there was a small round of applause from those of us
whose Hosts were line-at-a-time rather than character-at-a-time by
nature.  (For the benefit of non-oldtimers, Larry was head of ARPA's
Information Processing Techniques [or Technology--but I always got
confused over that even before EMA] Office at the time [a/k/a Our
Sponsor] and Frank was either still a Division Head at BBN or maybe
already a VP [I think the former, but ...].)

It sure sounds to me as if the time has finally come when we really
have to deal with the Remote Controlled Echoing issue, in light of
the apparent return of the point of view which holds that it doesn't
matter whether you've got one word or several pages in the metaphorical
envelope, it still requires a metaphorical stamp.  As you know
(but as I'm not sure it's proper to go into detail about on the List),
I'm not in a position to volunteer to head up an ad hoc working
group on RCTE (T for Terminal, as I recall) at present, but I'd
certainly urge somebody to step forward and I'd be glad to offer
whatever help I'm in a position to offfer when it gets going, or
even, if it makes the pot sweeter, to offer to stay out of it
entirely, if that's what it takes to get a volunteer.  If Dave
Clark is watching, perhaps he'd like to do the convening, or
mabye it's within the purview of one of the existing task forces,
but in any event it does seem that if there's a clear and present
danger of having to pay per character for all the character-at-a-time
transmissions it's incumbent on us to decrease the number of
those transmissions.

cheers, map
-------
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 11:18:16 EDT
From:      jas@MONK.PROTEON.COM (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   DSU/CSU units

Now that I'm at my office, I see I goofed a little on B8ZS.  There are
two complex patterns that replace the 8 "zero"'s, depending on the
polarity of the last "one".  If the last "one" was +1, then you send
0,0,0,+1,-1,0,-1,+1.  If the last "one" was -1, you send
0,0,0,-1,+1,0,+1,-1.  The fourth and seventh positions are bipolar
violations.  This is better than what I described before, as it gives
you a lot more flux changes (4 vs. 1).

I beleive the eigth bit in voice use is used for signalling
(on-hook/off-hook), but not to provide one's density.  It appears that
the one's density is provided by having the PCM voice not have any
voltage that comes out as seven "zero"s.  (Or at least making this
very infrequent.)

However, the 56KB of DDS service definitely comes from stuffing that
eighth bit as a "one".  This is also what the cheaper DSU/CSU's do.

For further reference, see AT&T PUB 62411.

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 13:15:23 EDT
From:      garrett@udel.EDU (Joel Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: PC Telnet with Tek Graphics emulator

In article <8709241203.AA14116@ucbvax.Berkeley.EDU>
BEAME@MCMASTER.BITNET writes:

>Many people require terminal emulators that exist in the RS232 realm to
>work on Telnet. One solution to this problem is the product BWCOM from
>Beame & Whiteside software Ltd. . It allows interupt driven RS232
>terminal emulators to run Telnet over an ethernet. The serial terminal
>emulator thinks it's talking to a Hayes compatible modem.
>
> - Carl Beame
>   BEAME@MCMASTER.BITNET

This looks like a very interesting product.  How could one get in touch
with B&W Ltd. to get more info and also possibly purchase the product?

					Joel Garrett
					garrett@udel.edu

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 18:04:52 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

8ZBS generates bipolar violations of a specific kind.  Some
telco equipment allows it and some does not.  For single-channel
T1 (i.e. two IP gateways that want the whole bandwidth of a 
T1 connecting them), we have used a gadget from Digilink
that I call a T1-izer.  It takes a vanilla synchronous signal,
and supplies everything that is needed to pass it through T1.
There are a number of switches that control the encoding.
You can select 8ZBS, if your telco can hack that, or a more
convservative encoding if they can't.  (There is of course a
slight benefit in terms of line speed if you use 8ZBS.)
THis also has a DSU/CSU builtin.  (However we more typically
use Avanti equipment, because we need to multiplex several
channels on one T1 line.)

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 24-Sep-87 22:48:22 EDT
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: PC Telnet with Tek Graphics emulator

Our PC/TCP comes with "glass" versions of Telnet and Rlogin.  These contain
no terminal emulation of their own, and do all I/O via the MS/DOS console
devie (CON).  If a terminal-emulating device driver is present (like
ANSI.SYS), whatever emulation it provides is passed the Telnet data stream,
and keyboard input gets passed through it too.

We don't sell any drivers to go with this, but we do have one public-domain
one that we provide on request (for an HP26?? terminal), and there is at least
one commercial Tek emulator (from Grafpoint, it does a 4105) which is known
to work with our stuff.  NANSI works, too, and I would expect anything else
that loads as a device driver for CON to work (subject to the lamentable fact
that very few Telnets are able to pass 8-bit data).

James B. VanBokkelen
spdcc!ftp!jbvb@harvard.harvard.edu
FTP Software Inc.
(617) 868-4878

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Sep-87 07:00:57 EDT
From:      piet@cwi.nl (Piet Beertema)
To:        comp.protocols.tcp-ip
Subject:   Re: Can of worms revisited


	...have chosen an accounting fiction, the "segment" as a way to
	deal with variance in actual and in maximum packet sizes.
	The public network administration announces the segment size (in
	octets) and the charges are for the number of octets sent on a
	given virtual circuit.
Note that the accounting entity "segment" comprises
pure user data only, no headers and other stuff.

-- 
	Piet Beertema, CWI, Amsterdam
	(piet@cwi.nl)

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 87 17:36:00 PDT
From:      "Dave Crocker" <dcrocker@twg.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   RCTE
Reviving the Remote Controlled Transmission and Echoing telnet option is
an interesting idea.  Certainly SOMETHING needs to be done.  Part of the
problem with the original protocol (my very first effort and it looks like
it) was that it was not rich enough in maintaining synchronization.  

Stepping back a bit, it requires that the serving host allow the application
to specify what kinds of characters are "interesting" (on the theory that
the sending host can aggregate all the characters up to the interesting
one and then send them in a batch).  RCTE was based upon John Davidson's
(then of Univ. of Hawaii) observation that Tenex (a derivative of which
now runs on Decsystem-20s) had just such a feature.

Unfortunately, it is not common to some well-known operating system.

Even more interesting is the thought that such a protocol should be
more ambitious.  RCTE does not know anything about the terminal or the
semantics of the session.  A "display-oriented" protocol could be much
more powerful.  John Day, then of Univ of Illinois, began a campaign for
such a telnet option and continued it for quite some time.  I believe
that a version is still in the protocol books.  Perhaps we should dust
it off and see why it shouldn't be aggressively implemented.

Dave
------
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Sep-87 15:38:29 EDT
From:      tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   request for peer review


To whom it may concern (and a plea for help)......................

I am working on a set of new techniques for dynamic routing in very
large networks, called Landmark Routing.  Anybody at the July IETF
meeting saw a presentation of some of this work.  I have just
finished a rough draft of a major piece of work that describes,
mostly at medium to high level, how all of Landmark Routing works.
(The previous document, which a lot of people have seen, is full
of fairly nitty-gritty details about one small aspect of Landmark
Routing--the Landmark Hierarchy).

I am looking for people to read the paper and give me feedback.
I hope that there is a varied collection of people out there
that would be interested in this work--partly because it contains
a lot of new ideas, and partly because there is a reasonably good
chance that implementations of it will find their way into the
internet in the near future (one year at best).  Landmark
Routing basically is a set of protocols and algorithms that allow
for fully automated routing in arbitrarily large networks and
internets.

Its main feature is that it automatically configures
its own hierarchy for dealing with large numbers of nodes--no
preassigned addresses are necessary!  To deal with changing addresses,
it offers a general, fully distributed name-to-address binding
scheme, which we have dubbed Assured Destination Binding.  As a
fallout of this, Landmark Routing can handle any number of mobile
hosts.  We have also incorporated the concept of administrative
boundaries into the scheme.  This allows messages to stay within
a pre-defined boundary, prevents other messages from going through
the boundary (if desired), and allows a fair amount of autonomy
between different groups.

The paper itself, called "Landmark Routing:  Architecture,
Algorithms, and Issues," is long; over 140 pages.  However,
don't let this lower your expectations about the quality of
the work.  Unlike many long papers, I don't think any of this
thing is content-free.  (Believe me, if I could fit all of it
into one double spaced page, I would).

Because of the length, I would only expect people to give substantive
review individual sections.
There are 5 major sections (not including the section that overviews
the main idea behind Landmark Routng).
Although a general understanding of Landmark Routing is needed to
help understand any section, they all pretty much stand alone.
Therefore, one could realistically give substantive review to any
one section without reading the whole thing in gory detail.

Let me outline each section, so that people can get an idea of
whether they want to read it.  I am only interested in hearing
from people who will give it a real critical review.

Section 2 describes the basic idea behind Landmark Routing.  I
don't need any review of this section.

Section 3 describes the routing protocol I intend to use with
Landmark Routing (the way it is architected, multiple and/or
different routing protocols can be used, as long as they are
of the distance-vector (i.e., Bellman-Ford, Old ARPANET, etc.) variety).
Don't worry about the count-to-infinity business.  This section
contains a simple and efficient fix to count-to-infinity that
has INSTANT convergence to new routes given bad news.  (Even
good-ole SPF doesn't have instant convergence.)  This is
because the alternate route is pre-primed even before bad news comes
along.  We call this scheme Alternate-path Distance-vector Routing.
The alternate route also provides some nice path splitting to boot.

Section 4 describes how the hierarchy is maintained and adjusted in
the face of topology changes, including merging networks together.

Section 5 describes the administrative autonomy and trust scheme
that we employ, called Administrative Zones.  It provides some
of what Autonomous Systems provide.

Section 6 describes the name-to-address binding technique mentioned above.
This technique works with a completely flat name space (as long as
names are unique), and can be distributed among as many or as few nodes
as desired.

Finally, section 7 provides a lot of miscellaneous, include implementation
ideas, transition issues, address structures, how to configure across
large, non-broadcast subnetworks, and the like.  I should note that
this implementation will be for ISO only (the DoD IP address
is just too small), but will be able to
handle DoD IP packets.  As such, it will be useful during transition.
Also, most of the implementation will run at the application layer.


I GREATLY appreciate any help people wish to offer.

Thanks in advance..................

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


P.S. (Sorry for those of you who received this over several lists)

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Sep-87 17:19:23 EDT
From:      weiser.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: newer (bug fixed) 4.3bsd tcp for Sun OS 3.3 available

Although Van Jacobson modestly states you don't want to run his code if
you have Sun 3.4, I continue to measure large performance differences in
extreme cases.  I get the following times for transferring 10 megabytes
memory-to-memory (in other words, the client generates the bytes from
thin air, and the server puts them all into the same buffer):

33 secs		SunOs 3.4
23 secs		The Berkeley 4.3 + fixes courtesy of Van Jacobson, on top of
3.3.

This times are measured from Sun-3/260 to Sun-3/260 on the same
ethernet.  Base load on the ethernet was 10-20%, so conceivably these
times could improve a bit.

I suspect that what accounts for the difference is that the SunOS 3.4
never seems to generate an ethernet packet larger 576 bytes or so when
operated through tcp, even though with UDP it generates the full 1500+
byte packets.  netstat -i gives an MTU of 1500.

-mark

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Sep-87 17:24:26 EDT
From:      davidc@UMD5.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Survey of people working on TCP/IP for the PC

I was wondering who is actively working on TCP/IP for the PC and which flavor 
(CMU, MIT, commercial, etc).  Please send replies directly to me and I'll 
summarize if there is any interest.

-drc

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Sep-87 20:36:00 EDT
From:      dcrocker@TWG.ARPA ("Dave Crocker")
To:        comp.protocols.tcp-ip
Subject:   RCTE

Reviving the Remote Controlled Transmission and Echoing telnet option is
an interesting idea.  Certainly SOMETHING needs to be done.  Part of the
problem with the original protocol (my very first effort and it looks like
it) was that it was not rich enough in maintaining synchronization.  

Stepping back a bit, it requires that the serving host allow the application
to specify what kinds of characters are "interesting" (on the theory that
the sending host can aggregate all the characters up to the interesting
one and then send them in a batch).  RCTE was based upon John Davidson's
(then of Univ. of Hawaii) observation that Tenex (a derivative of which
now runs on Decsystem-20s) had just such a feature.

Unfortunately, it is not common to some well-known operating system.

Even more interesting is the thought that such a protocol should be
more ambitious.  RCTE does not know anything about the terminal or the
semantics of the session.  A "display-oriented" protocol could be much
more powerful.  John Day, then of Univ of Illinois, began a campaign for
such a telnet option and continued it for quite some time.  I believe
that a version is still in the protocol books.  Perhaps we should dust
it off and see why it shouldn't be aggressively implemented.

Dave
------

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Fri, 25-Sep-87 21:04:45 EDT
From:      jbvb@ftp.UUCP (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for HP 3000s?

I'm pretty sure HP doesn't have one.  Does anything exist in the public
domain, or from another vendor?  If respondents think there will be enough
responses to annoy the list, send them to me, and I will summarize.

spdcc!ftp!jbvb@harvard.harvard.edu
James B. VanBokkelen
FTP Software Inc.
501 Cambridge St.
Cambridge, MA 02141
(617) 868-4878

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 87 01:57:00 EST
From:      "GBURG::ENGER" <enger%gburg.decnet@bluto.scc.com>
To:        "dcrocker" <dcrocker@twg.arpa>
Cc:        tcp-ip@sri-nic.arpa,enger
Subject:   RCTE functionality
Dave:
It is my impression that DEC's CTERM protocol provides at least some of the 
desired functionality.

Bob
------
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 02:57:00 EDT
From:      enger%gburg.DECnet@BLUTO.SCC.COM ("GBURG::ENGER")
To:        comp.protocols.tcp-ip
Subject:   RCTE functionality

Dave:
It is my impression that DEC's CTERM protocol provides at least some of the 
desired functionality.

Bob
------

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 03:26:42 EDT
From:      page@ulowell.cs.ulowell.edu (Bob Page)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   route & routed info

I just added a dmr-11 to a 4.3 system, and can't talk to it.  I say:

ifconfig il0 inet 129.63.1.1 broadcast 129.63.1.0 -trailers netmask 0xffff0000
ifconfig dmc0 inet 128.188.230.2 128.188.230.1 -trailers netmask 0xffff0000

and after starting routed, 'netstat -rn' shows:

Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      14         lo0
128.188.230.1        128.188.230.2        UH       0      0          dmc0
128.188.230.2        129.63.1.1           UH       0      29         il0
129.63.1.1           129.63.1.1           U        0      198        il0
128.188              128.188.230.1        UG       0      0          dmc0
129.63               129.63.1.1           U        1      2914       il0

I can use the 129.63 network, but can't get to the 128.188 net.  Routed
sets up the 128.188.230.2 route via 129.63.1.1; it's not in my gateways
file.  I can ping my dmc at 128.188.230.2 but don't believe it; netstat
shows all the traffic is going through il0.  I can't talk to 128.188.230.1,
and if I delete the route from 129.63.1.1 to 128.188.230.1 I can no longer
ping the dmc.  Any attempt results in a "Network is unreachable" message.

How can I set up the routes so I can get to the 128.188 network?
I'm running stock 4.3 routed.  Thanks in advance.

..Bob
-- 
Bob Page, U of Lowell CS Dept.   page@ulowell.{uucp,edu,csnet} 

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 10:38:00 EDT
From:      BEAME@MCMASTER.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: PC Telnet with Tek Graphics emulator


In message <2811>
Udel!garrett@princeton.edu writes:

>How could one get in touch with B&W Ltd. to get more info ?

BWCOM is available from:

Beame & Whiteside Software Ltd.
259 Fiddler's GReen Rd.
Ancaster, Ontario
Canada L9G 1W9
(416) 648-6556

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Sep 87 10:38 EDT
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: PC Telnet with Tek Graphics emulator

In message <2811>
Udel!garrett@princeton.edu writes:

>How could one get in touch with B&W Ltd. to get more info ?

BWCOM is available from:

Beame & Whiteside Software Ltd.
259 Fiddler's GReen Rd.
Ancaster, Ontario
Canada L9G 1W9
(416) 648-6556

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 11:06:00 EDT
From:      BEAME@MCMASTER.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE


In the SET HOST protocol (CTERM) DEC uses a one or several longwords passed
from the remote side to indicate what characters the local size should terminate
the QIO request. Thus echoing and deleting of characters is performed on the
local end and sent only when one of the characters listed as a terminator is
hit. DEC also sends a length field which will terminate the QIO and send the
data when X number of characters have been sent.

With the above method both "line at a time" and single character transfers
can be requested.

- Carl

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26 Sep 87 11:06 EDT
From:      <BEAME%MCMASTER.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: RCTE

In the SET HOST protocol (CTERM) DEC uses a one or several longwords passed
from the remote side to indicate what characters the local size should terminate
the QIO request. Thus echoing and deleting of characters is performed on the
local end and sent only when one of the characters listed as a terminator is
hit. DEC also sends a length field which will terminate the QIO and send the
data when X number of characters have been sent.

With the above method both "line at a time" and single character transfers
can be requested.

- Carl
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 13:35:54 EDT
From:      zeeff@b-tech.UUCP (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: Survey of people working on TCP/IP for the PC

I'm interested in tcp/ip software for the PC that includes support for FTP
and the SLFP (similar but different from SLIP) serial line protocol that
I believe the CMU package has.  Is there such a thing?

I've dome some work on making the KA9Q package speak SLFP, but with a new
version out, I expect I'd have to do it over again.


-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 15:09:09 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re:  RCTE

On Unix, my impression is that we have roughly three modes:
  - normally software lets the system do line editing.  In this
	mode, the terminal server could do the editing and
	then pass whole lines without echo
  - raw or cbreak mode is used by a few programs that do screen
	handling.  It is specifically enabled by a system call,
	which would give the kernel a chance to trigger
	negotiation of a different telnet mode.  THis would
	be full duplex, char at a time.
  - some screen-oriented programs are used enough that it is
	worth modifying them to give the terminal server
	instructions.  Emacs is probably the best example.
	The main screen-oriented programs I use are emacs nad
	vnews.  Vnews is not worth doing, I suspect, since
	normally the characters typed a single letters anyway,
	so not much improvement is to be had.  I understand
	that Encore already has support for emacs in their
	terminal servers.  I don't know what they are doing,
	but experiments were done with TOPS-20 Emacs based
	on the concept that Emacs should let the temrinal
	server echo, and should specify two things: a bit
	map - when any of these characteris is typed, the
	server should go back into char at a time mode, and
	let Emacs respond to that character; a count - when
	that many characters had been typed, ditto.  The idea
	was that most people spent most of their time typing
	text at the end of a line.  Emacs would set the bitmap
	to all of the command chars (in effect, all but printing
	characters), and the count to the number of characters
	left on the line (since Emacs will have to do some
	screen management when you reach the end of the line).
	probably Encore is in a position to make additional
	suggestions, but this seems a reasonable place to start.

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 18:04:52 EDT
From:      narten@PURDUE.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: route & routed info

Bob,

Here is a 4.3 kernel problem that would give the symptoms you
describe. I don't take credit for finding the bug, but I did remember
to save it where I could find it! One way you can verify that this is
really your problem is to see if things work if you *don't* run
routed. Routed will time out routes for interfaces that aren't
working. An interface "doesn't work" if no routed packets are received
with a source address on the network. If UDP packets are being sent
with an incorrect source address, this will certainly confuse routed.

Thomas

From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: 4.3bsd can mistake p-to-p interfaces
Message-ID: <717@mcgill-vision.UUCP>
Date: 29 Mar 87 09:26:28 GMT
Organization: McGill University, Montreal
Lines: 50
Posted: Sun Mar 29 04:26:28 1987

We are running mtXinu 4.3+NFS, and there is a bug in netinet/in_pcb.c.
I can't be certain, but I expect that this is present in 4.3 because it
is an obvious mistake once noticed; in fact earlier in the file there
is another opportunity for the same bug but someone noticed it.  The
symptom is that packets being sent over UDP sockets, such as used by
routed(8), get stamped with the wrong "from" address.  This is because
in_pcbsetaddr() is calling ifa_ifwithdstaddr() with the socket address
it is looking for, instead of a socket address with a zero port number.
Ifa_ifwithdstaddr is then comparing the entire 14 bytes of sockaddr
data to the data in the ifaddr entry, and of course the sockaddr in the
ifaddr entry has a zero port number.  So the compare fails.  The
earlier code I referred to is a similar call to ifa_ifwithaddr(); look
for yourself for the fix used.  The fix I used is similar; here is the
original code:

		if (ia == 0) {
			ia = (struct in_ifaddr *)
			    ifa_ifwithdstaddr((struct sockaddr *)sin);
			if (ia == 0)
				ia = in_iaonnetof(in_netof(sin->sin_addr));
			if (ia == 0)
				ia = in_ifaddr;
			if (ia == 0)
				return (EADDRNOTAVAIL);
		}

and here is my fixed version (I know it isn't pretty, I didn't care
about esthetics when I fixed it):

		if (ia == 0) {
int oldport;
oldport = sin->sin_port;
sin->sin_port = 0; /* for ifa_ifwithdstaddr */
			ia = (struct in_ifaddr *)
			    ifa_ifwithdstaddr((struct sockaddr *)sin);
			if (ia == 0)
				ia = in_iaonnetof(in_netof(sin->sin_addr));
sin->sin_port = oldport;
			if (ia == 0)
				ia = in_ifaddr;
			if (ia == 0)
				return (EADDRNOTAVAIL);
		}

					der Mouse

Smart mailers: mouse@mcgill-vision.uucp
USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Sat, 26-Sep-87 23:22:57 EDT
From:      eshop@saturn.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units


After I wrote about my Verilink experiences, the machine room at the
far end of our T1 line had an air conditioning failure.  By the time
the temperature had reached 85 F, our packet loss rate had climbed
to something on the order of 70 percent.  The guy at the other end
of the wire opened the doors to the machine room (it was evening and
fairly cool outside) and pulled the temperature down.  The packet 
losses dropped back down to near zero.  

There are three Verilinks in the same cabinet in the aforementioned
room (this is at Stanford).  Only our line suffered when the temp
climbed.  My conclusion is that there is definitely something wrong
with that Verilink.  NOTHING should be that temperature sensitive,
as the other two Verilinks in the cabinet testify.   The environmental
spec's for the 551VCC/U call for it to operate at up to 50 C (122 F)
so it's clear we have a lemon.  

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27-Sep-87 02:22:36 EDT
From:      melohn@SUN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECnet

Technically speaking, DECservers do not speak DECnet, they use a DEC
propriatary protocol called LAT. This is an ethernet protocol which
coexists with any other Ethernet protocol (like TCP/IP) without any
problems.

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27-Sep-87 12:56:47 EDT
From:      edward@engr.uky.edu (Edward C. Bennett)
To:        comp.protocols.tcp-ip
Subject:   Re: Public Domain TCP/IP

In article <28325@sun.uucp> jlp@sun.UUCP (John Pope) writes:
>In article <358@palladium.UUCP> gkenley@palladium.UUCP (Greg Kenley) writes:
>>"Home of the DataTub"
>	What's a DataTub??

Perhaps a large bit-bucket?

-- 
Edward C. Bennett				DOMAIN: edward@engr.uky.edu
						UUCP: cbosgd!ukma!ukecc!edward
"Goodnight M.A."				BITNET: edward%ukecc.uucp@ukma
	"He's become a growling, snarling white-hot mass of canine terror"

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27-Sep-87 13:31:22 EDT
From:      blumenth@VAX.BBN.COM (Steve Blumenthal)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for HP 3000s?

James,

Here is a message which I sent to the TCP/IP mailing list back in April
about the BBN developed TCP/IP software for the HP3000.

/Steve

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

Received: from sri-nic.arpa by VAX.BBN.COM id a004313; 15 Apr 87 0:15 EST
Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 11:56:00-PDT
Date:     Tue, 14 Apr 87 13:48:20 EST
From:     Steve Blumenthal <blumenth@VAX>
To:       tcp-ip@sri-nic.ARPA
Subject:  Re:  TCP on an HP 3000

BBN had a contract from DARPA to develop TCP/IP for the HP3000.  Under
that effort we also developed user and server TELNET and user FTP.  This
software required modifications to the HP3000 operating system and ran
on an HP3000 Series 3 under MPE IV.  We completed this effort in 1983
and delivered the software to White Sands Missle Range, where it was
modified to run on an HP3000 Series 44 system under the MPE V/P
operating system.  Because we needed access to the HP3000 operating
system sources, we had to sign a source license with HP.  This agreement
restricts our ability to redistribute this software except to U.S.
government sites as directed by DARPA.

Because BBN is not heavily involved with the development of software for
the HP3000, we tried to give our software to HP to have them support it
and track subsequent HP3000 operating system and hardware improvements.
To date, HP has not taken us up on our offer.  They may be in the
process of developing TCP/IP for the HP3000 themselves, but at this
point, we have no current contacts at HP.

Steve Blumenthal
BBN Laboratories

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Sun, 27 Sep 87 13:31:22 EDT
From:      Steve Blumenthal <blumenth@VAX.BBN.COM>
To:        James Van Bokkelen <ftp!jbvb@HARVARD.HARVARD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  TCP/IP for HP 3000s?
James,

Here is a message which I sent to the TCP/IP mailing list back in April
about the BBN developed TCP/IP software for the HP3000.

/Steve

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

Received: from sri-nic.arpa by VAX.BBN.COM id a004313; 15 Apr 87 0:15 EST
Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 11:56:00-PDT
Date:     Tue, 14 Apr 87 13:48:20 EST
From:     Steve Blumenthal <blumenth@VAX>
To:       tcp-ip@sri-nic.ARPA
Subject:  Re:  TCP on an HP 3000

BBN had a contract from DARPA to develop TCP/IP for the HP3000.  Under
that effort we also developed user and server TELNET and user FTP.  This
software required modifications to the HP3000 operating system and ran
on an HP3000 Series 3 under MPE IV.  We completed this effort in 1983
and delivered the software to White Sands Missle Range, where it was
modified to run on an HP3000 Series 44 system under the MPE V/P
operating system.  Because we needed access to the HP3000 operating
system sources, we had to sign a source license with HP.  This agreement
restricts our ability to redistribute this software except to U.S.
government sites as directed by DARPA.

Because BBN is not heavily involved with the development of software for
the HP3000, we tried to give our software to HP to have them support it
and track subsequent HP3000 operating system and hardware improvements.
To date, HP has not taken us up on our offer.  They may be in the
process of developing TCP/IP for the HP3000 themselves, but at this
point, we have no current contacts at HP.

Steve Blumenthal
BBN Laboratories



-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 00:28:30 EDT
From:      dolson@ADA20.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECnet

> From: melohn@Sun.COM (Bill Melohn)
> Technically speaking, DECservers do not speak DECnet, they use a DEC
> propriatary protocol called LAT. This is an ethernet protocol which
> coexists with any other Ethernet protocol (like TCP/IP) without any
> problems.

Mostly right, thats during normal operations.  However, during
software downline loading from a VAX or PDP (or other?) host, and
during the infrequent software crash dump UPline load, they do speak
DECnet.  Also, they support remote console facility which I guess is
also DECnet...(thats NCP> CONNECT CONSOLE, check it out, nice for the
times when you have to forceably logout a locked-up port and the
terminal server in question is a long stroll away down the building!)
Point is, 'technically speaking' the beasties do speak both LAT and
DECnet, sometimes at the same time.

Doug
-------
-------

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 08:41:43 EDT
From:      mckee@MITRE.ARPA (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: DSU/CSU units

At the risk of discussing the obvious: You noted that one of three 
Verilinks behaved badly when the temperature went up.  It may be that
the distribution of cooling air within the cabinet was such that yours
went out-of-spec.  

Regards - Craig

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 09:51:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   RCTE

RCTE sounds a lot like the echo-negotiation protocol that the Multics
Emacs people developed circa 1980.  I'm sorry I can't give you a
reference; they may not have published anything.

There is and has been a display oriented terminal protocol for a long,
long time.  The only reason it needs "dusting off" is because only now
are commonplace terminals and computer systems really able to take
advantage of it.  Most operating systems were (originally) written with
printing terminals in mind, which is why it has been hard to graft this
into existing systems, such as TOPS20.  I'm refering, of course, to the
SUPDUP protocol, RFC 734 of 1978.  If you want graphics, you can do that
too: the SUPDUP Graphics extension, RFC 746 March 1978.  I suggest you
look at these before doing too much wheel reinvention.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 10:53:29 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE

Dave--
   It happens that I had occasion to check with John Day about his
"NVDET" (Network Virtual Data Entry Terminal) stuff several years ago.
He told me to wait for the ISO Virtual Terminal Protocol instead.
So I did that.  And did that.  And am still doing that.
   Actually, some work on NVDET is/was being done in the "DoDIIS"
(DoD Intelligence Information System) arena.  A year or so ago,
I reviewed a draft RFC on the topic by a contractor; still waiting
for the next draft.  Since it was intended for release to the research
community eventually, you might see it before I do if impending
threats to my daily access to the net eventuate.
   In my view, the trouble with NVDET--and TN3270, which somebody
semi-facetiously put forward in a side msg--is that you get wrapped
around the the screen-at-a-time axle instead of the char-a-a-t one,
and in the context we're addressing that isn't desirable.  (Not to
deny that there are contexts in which it's necessary to deal with
screen-a-a-t, just to observe that this doesn't have to be one of
them--unless, of course, a solution to char-a-a-t falls out of it
naturally.)
   Are you volunteering to retrieve the RCTE baton/torch, by the way?
   cheers, map
-------

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1987 10:53:29 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        "Dave Crocker" <dcrocker@TWG.ARPA>
Cc:        "tcp-ip" <tcp-ip@SRI-NIC.ARPA>
Subject:   Re: RCTE
Dave--
   It happens that I had occasion to check with John Day about his
"NVDET" (Network Virtual Data Entry Terminal) stuff several years ago.
He told me to wait for the ISO Virtual Terminal Protocol instead.
So I did that.  And did that.  And am still doing that.
   Actually, some work on NVDET is/was being done in the "DoDIIS"
(DoD Intelligence Information System) arena.  A year or so ago,
I reviewed a draft RFC on the topic by a contractor; still waiting
for the next draft.  Since it was intended for release to the research
community eventually, you might see it before I do if impending
threats to my daily access to the net eventuate.
   In my view, the trouble with NVDET--and TN3270, which somebody
semi-facetiously put forward in a side msg--is that you get wrapped
around the the screen-at-a-time axle instead of the char-a-a-t one,
and in the context we're addressing that isn't desirable.  (Not to
deny that there are contexts in which it's necessary to deal with
screen-a-a-t, just to observe that this doesn't have to be one of
them--unless, of course, a solution to char-a-a-t falls out of it
naturally.)
   Are you volunteering to retrieve the RCTE baton/torch, by the way?
   cheers, map
-------
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28 Sep 1987 13:01:02 LCL
From:      John M. Wobus <JMWOBUS%SUVM.BITNET@wiscvm.wisc.edu>
To:        TCP-IP Discussion Group <TCP-IP@SRI-NIC.ARPA>
Subject:   RTCE & Line-at-a-time TELNET-like protocols
DEC's TOPS-10 OS optionally echos for user programs and does it remotely
via its "ANF-10" networking protocols.  It allows a user program to
declare its own set of input characters that stop echoing.  It goes to a
lot of trouble to make certain that the first characters that are not
supposed to echo, don't (like passwords).  I recall some technical device
they call "pipeline echo markers".

My own inclination is that any protocol adopted in this day and age should
be able to locally generate cursor movements in response to cursor movement
keys.

John Wobus
Syracuse University
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 12:36:16 EDT
From:      PERILLO@SRI-NIC.ARPA (Francine Perillo)
To:        comp.protocols.tcp-ip
Subject:   DDN "Vendors Guide"

Having noticed recent inquiries on this mailing list for a list
of TCP/IP implementations, it seems appropriate to announce that 
a new version of the "DDN Protocol Implementations and Vendors Guide"
is available from the NIC.  This document is issued by SRI under
contract with DCA.

The online file is FTP'able from SRI-NIC.ARPA using the anonymous
login convention: log in as "anonymous", with password of "guest".
Pathname is NETINFO:VENDORS-GUIDE.DOC

A hardcopy version (dated August 1987) is also available.  Contact
NIC@SRI-NIC.ARPA for details on how to order this.

Request to all:  Kindly let us know about implementations which are
missing from this document.

-Francine  /NIC
-------

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 13:50:53 EDT
From:      kumar@hpindda.HP.COM (Krishna Kumar)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for HP 3000s?

/ hpindda:comp.protocols.tcp-ip / jbvb@ftp.UUCP (James Van Bokkelen) /  6:04 pm  Sep 25, 1987 /
I'm pretty sure HP doesn't have one.  Does anything exist in the public
domain, or from another vendor?  If respondents think there will be enough
responses to annoy the list, send them to me, and I will summarize.

spdcc!ftp!jbvb@harvard.harvard.edu
James B. VanBokkelen
FTP Software Inc.
501 Cambridge St.
Cambridge, MA 02141
(617) 868-4878
----------


DISCLAIMER: This is a statement based on my personal knowledge, to give you
	    an idea of the TCP/IP products on the HP3000s and is NOT 
	    to be taken as an official statement of the Hewlett-Packard
	    Company.

I have been maintaining the TCP/IP product on the HP3000 for the last year and
a half, so I would state with reasonable surety that HP does have a TCP/IP
product for its 3000 family of computers!!!

The first release of TCP/IP for the 3000 which is part of the Network Transport 
(NXPORT) product was in March '85. The transport supports HP's proprietary
Networking Services (NS/3000). Note that the two are separate products and can
be bought independently. The NXPORT product if bought by itself could still be
used for the NetIPC (Inter Process Communication) interface that it provides.
The Services would not be of any use if bought without NXPORT. This initial
phase I release, was a IEEE 802.3 LAN only product.

The second release of Transport for the HP3000 (Netxport II) came out in March
'87 and is the phase II version of the Transport. This comprises of various
functional enhancements to the Transport including support of point-to-point
links, Transport level DDN compatibility and Transparent nodal access (store
and forward) for both intranet and internet destinations (includes gateways
and gateway halves). Netxport II is backward compatible with the phase I
product.

The following excerpts taken from the "NS3000/V Network Manager Reference
Manual, Volume I", gives an idea of the capabilities of the networking products
on the 3000s.

"NS3000/V consists of two parts: NS3000/V Services and NS3000/V links. Network
Services consist of software that enables users to access data, initiate
processes, and exchange information among all systems on a network. NS3000/V
links provide connections among systems (either HP3000s or personal computers)
in the same network. To use NS3000/V Services, the systems must be connected by
an NS3000/V network link.

A variety of network link products are available with NS3000/V. The link product
that connects individual systems in an NS3000/V network can be any of the
following:

	o NS Point-to-Point Network Link for MPE-V based systems
	o Asynchronous SERIAL Network Link
	o StarLAN/3000 Link
	o ThinLAN/3000 Link (includes ThickLAN option for thick coaxial cable..)

The link products listed above can all be used to connect HP3000s to one another

The Asynchronous SERIAL Network Link, StarLAN/3000, and ThinLAN/3000 can
connect HP 3000s to personal computers as well as to other HP3000s.

The ThinLAN/3000 Link, including the ThickLAN option, can also connect HP3000s
with HP 1000s and HP 9000s."

Netxport II is bundled with hardware, NetIPC and driver software to form several
network link products.

The ARPA services FTP, TELENET and SMTP will be available for the 3000 around
April '88. These services are being developed by The Wollongong Group.

The X.25 link product for the HP3000 will be available around July '88.

To my knowledge the BBN software was not used to develop any product.

As the disclaimer states, this statement is my own, written to give you some
information about the HP3000 networking products, and I (and NOT the Hewlett
Packard Company) am responsible for any oversights/misstatements. Please
contact the marketing dept. for official statements and information regarding
the 3000 networking products.

Best Regards,

Krishna Kumar
Software Development Engineer
MS43 UX 
Information Networks Division
Hewlett Packard
19420 Homestead Road
Cupertino, CA 95014.

(hpda!hpindda!kumar@hplabs.HP.COM)
(408-447-2970)

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Mon 28 Sep 87 17:00:32-PDT
From:      Karl Auerbach <AUERBACH@CSL.SRI.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   TCP performance limitations
Someone asked me today what are the performance limits on a TCP connection.
The situation he posited was on in which there are no intervening
IP routers, massive availability of underlying bandwidth, massive computing
resources in the hosts, and low noise.  It was further posited that
the hosts could be using acknowledgement strategies highly tuned for
this specific situation.

How to make such an estimate is well outside my expertise.  Can anyone
give me any pointers?

			Thanks, --karl--
-------
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      28 SEP 87 13:28-SYS
From:      mslagley%UCIVMSA.BITNET@wiscvm.wisc.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: PC Telnet with Tek Graphics emulator
Received: from ORION by UCICP6 with PMDFs; 28 Sep 1987 13:13:08
Received: from localhost by orion.cf.uci.edu id a016378; 28 Sep 87 13:09 PDT
In-reply-to: Your message of Sat, 26 Sep 87 10:38:00 -0400.<8709262251.aa10347@I
CS.UCI.EDU>
Date: Mon, 28 Sep 87 13:09:48 -0700
From: mslagley@orion.cf.uci.edu

Beam & Witeside is sending their promotional information.
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 18:00:17 EDT
From:      mslagley@UCIVMSA.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: PC Telnet with Tek Graphics emulator

Received: from ORION by UCICP6 with PMDFs; 28 Sep 1987 13:13:08
Received: from localhost by orion.cf.uci.edu id a016378; 28 Sep 87 13:09 PDT
In-reply-to: Your message of Sat, 26 Sep 87 10:38:00 -0400.<8709262251.aa10347@I
CS.UCI.EDU>
Date: Mon, 28 Sep 87 13:09:48 -0700
From: mslagley@orion.cf.uci.edu

Beam & Witeside is sending their promotional information.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 18:27:08 EDT
From:      jaw@JPL-MIL.JPL.NASA.GOV (Joe Wieclawek)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip mailing list

Sorry to bother the net with this but my requests to TCP-IP-REQUEST
seem to fall in the bit bucket.

	Please change the address on the
		TCP-IP distribution list
			from jaw@jpl-vlsi.arpa
			  to tcp-ip@jpl-mil.jpl.nasa.gov
			  OR tcp-ip@jpl-mil.arpa (26.9.0.65)

Thanks,


Joe Wieclawek                   Mail stop: 602-145
Jet Propulsion Laboratory       Office: (818)354-2419	FTS: 792-2419
4800 Oak Grove Drive            jaw@sesun.jpl.nasa.gov
Pasadena CA     91109

System Engineering
Communications and Computing Network Services Section

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 18:31:31 EDT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   SUPDUP protocol

Although the SUPDUP protocol has a lot of advantages over the TELNET
protocol for modern computers systems, it does not provide for any
local echoing capability at all, nor does it provide for local "break
characters"  (what it does provide is a standard way of negotiating
terminal capabilities (now somewhat dated in scope), and terminal
independent display capabilities).

TOPS20 has the concept of a break character bitmap, but not for an
echoing bitmap, and it required monitor modifications to get the
break character implementation to be at all useful to the popular
display editor emacs.  (I originally implemented these changes back
at SRI, to (hopefully) lessen the impact of emacs on system performance.

I believe that VMS has a similar scheme.

DEC's CTERM protocol provides the means of transmitting such info over
a network connection, but DEC engineers I have talked with said that
even within DEC, the standard is rather abused (eg, most of VMS
terminal IO is done via system-extension-code XYZZY, and such).

Unix, one of the worlds most popular operating systems, doesn't have
either concept.  The Annex boxes implement some local editing
functionality, but this requires both a custom version of the editor,
and custom software on the Annex, and is not a published standard.
(nor does it help outside of the editor...)

A good protocol would permit some local intelligence (eg echoing,
bunching of characters) without the local server having to know
specifics about the type of terminal being used.

What it amounts to is that most operating systems are STILL dealing
with the terminal as if it were a printer, and that this probably has
to change before a smarter virtual terminal protocol can be defined.

Bill Westfield
cisco Systems
-------

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Mon, 28-Sep-87 20:00:32 EDT
From:      AUERBACH@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   TCP performance limitations

Someone asked me today what are the performance limits on a TCP connection.
The situation he posited was on in which there are no intervening
IP routers, massive availability of underlying bandwidth, massive computing
resources in the hosts, and low noise.  It was further posited that
the hosts could be using acknowledgement strategies highly tuned for
this specific situation.

How to make such an estimate is well outside my expertise.  Can anyone
give me any pointers?

			Thanks, --karl--
-------

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 02:01:13 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP performance limitations

Karl,

Geez, how can I respond to such a wonder? Given your scenario, I would
posit something like X-band speeds, which works out to 10^10 bps, assuming
you use the right waveguide. Now, if you are phond of photons, we can
escalate that a few megatons. Seriously, existing Unix implementations
might horse up to a couple of megabits, but Craymonsters on Hyperbolts
might up that a magnitude. Meanwhile, ask Dave Clark at MIT about the
NETBLT performance, which is currently dimming the lights on FATNET
at megabit speeds over real satellite channels.

Dave

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 03:41:04 EDT
From:      melohn@SUN.COM (Bill Melohn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECnet

Not true. Downline loading, upline dumping, and the remote console
utility are handled by MOP, the Maintenance Operations Protocol, yet
another Digital propriatary protocol that is NOT included under the
publically available DECnet suite. True, to provide a mapping between
LAT server names and their ethernet addresses they use the DECnet node
database, but this is purely an implementation convienence (since
their is no DNA equivalant of ARP).

The point I was making is that DECnet is a publically specified
interface for talking to DEC machines; however it does NOT include
terminal servers, VAX clusters, and many other protocols which Digital
considers propritary. I'm tired of explaining to customers why we
can't support DEC terminal servers, "since they run DECnet" (which we
can and do support under SunOS).

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 07:22:13 EDT
From:      jsloan@wright.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and DECnet

in article <8709270622.AA01122@sluggo.sun.com>, melohn@SUN.COM (Bill Melohn) says:
> 
> Technically speaking, DECservers do not speak DECnet, they use a DEC
> propriatary protocol called LAT. This is an ethernet protocol which
> coexists with any other Ethernet protocol (like TCP/IP) without any
> problems.

True, LAT terminal servers are nice with LAT-capable machines (like
VMS or Ultrix) but just about useless with any other vendors equipment,
which is why we're going to TCP/IP terminal servers. Anyway, I think
the issue here is whether the TCP/IP code and the DECnet code running
on the same machine can coexist on the same ethernet controller, which
is a very sticky question. The DECnet/Ultrix implementations seems to
work fine. We use DECnet to talk to the VMS machines, TCP/IP (and NFS)
to talk to the UNIX machines and our terminal servers, and LAT to talk
to the few LAT boxes in other departments. I remember reading, I think,
that other commercial products, like TWG's TCP/IP for VMS, would do the
same. But I would read the fine print very carefully.

I do know that there were a variety of changes to the networking code
in Ultrix to support DECnet. I seem to recall that the lowest level
TCP/IP layer was boosted up above an sort of generic ethernet packet
server that controlled the interface board, and handed out appropriate
ethernet packets to the TCP/IP or DECnet code.


-- 
John Sloan  CSNET: jsloan@CS.Wright.EDU UUCP: ...!cbosgd!wright!jsloan
Computer Science Department, Wright State University, Dayton OH, 45435        
+1 513 873 2491   belong(opinions,jsloan). belong(opinions,_):-!,fail.
The only thing that depreciates faster than a computer is fresh fruit.

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 08:10:50 EDT
From:      doug@ICASE.ARPA (Doug Peterson)
To:        comp.protocols.tcp-ip
Subject:   in.routed dying

I'm experiencing a phenomenon with my routed daemon. It dies at seemingly
random intervals, for no apparent reason.

My configuration is as follows:

--------------------------------------------------------------
           |                                                 |
           | 128.102.7.51 (outside world)                   ----
         -------                                            |  |P4200 gw
         |      | Sun 3/180 file server (runs in.routed)    ----
         --------                                             |
             |192.12.48.1                            -------------------
---------------------------- (private net)             Another net
   |    |     |     |   |192.48.12.n
 ---  ---   ---   --- ---
  |  | |  |  |  |  | | | |
  ---  ---   ---   --- ---
      14 3/50 diskless clients

I'm running Sun OS 3.4 currently, but I've had the same problem under 3.3.
The file server has 8mb ram, 2 380mb Eagle disks, an FPA card, 16 serial
lines for printers, terminals, etc. Admittedly, the system is loaded,
but other things function properly, with response we can live with. However,
routed just dies without a clue.

Sun says they haven't heard of this problem with other customers. Does
anyone have any ideas about what to look at, or has anyone experienced
a similar problem?

Thanks.

Doug Peterson
Systems Manager
(804) 865-4090

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 09:01:15 EDT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP performance limitations

Karl,
	It sounds like you've removed the major bottlenecks and
throughput ought to approach infinity!  :-)  Without queue delays,
transmission delays, checksum computing delays, and retransmissions,
there's not much left to stall data.

	Walt

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 09:04:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   TCP performance limitations

Given your assumptions, TCP is not the limitting factor.  The limitting
factor are rate at which producers can produce data and consumers
can consume it.  It is quite easy to multibuffer TCP, and I suspect most
implementations have.  Given the horsepower of the consumer and the
producer, and the channel bandwidth, and the multibuffering methodology,
you can probably calculate the minimum window size that ensures the pipe
will always be full.

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 10:09:29 EDT
From:      JMWOBUS@SUVM.BITNET (John M. Wobus)
To:        comp.protocols.tcp-ip
Subject:   RTCE & Line-at-a-time TELNET-like protocols

DEC's TOPS-10 OS optionally echos for user programs and does it remotely
via its "ANF-10" networking protocols.  It allows a user program to
declare its own set of input characters that stop echoing.  It goes to a
lot of trouble to make certain that the first characters that are not
supposed to echo, don't (like passwords).  I recall some technical device
they call "pipeline echo markers".

My own inclination is that any protocol adopted in this day and age should
be able to locally generate cursor movements in response to cursor movement
keys.

John Wobus
Syracuse University

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 10:55:38 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE

Never having been at all fond of reinventing wheels, I hastened to
FTP the SUPDUP RFC and print it out at my terminal.  When I got to
"Due to the highly interactive characteristics of both the SUPDUP
protocol and the ITS system [which was the original Server for which
the protocol was developed], all transactions are strictly character
at a time and all echoing is remote" I aborted the printing.  Am I
misunderstanding something--the context is, as far as I know, avoiding
"unnecessary" transmissions--or have you misremembered SUPDUP?
(If the latter, let me be the first to welcome you to Early Middle Age.)
As things stand, I have to deem SUPDUP a reinvention of the travois,
in context; please correct me if I'm wrong.
   cheers, map
-------

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 1987 10:55:38 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Cc:        Dave Crocker <dcrocker@TWG.ARPA>, Charles Hedrick <hedrick@TOPAZ.RUTGERS.EDU>, BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU, "GBURG::ENGER" <enger%gburg.decnet@BLUTO.SCC.COM>, tcp-ip <tcp-ip@SRI-NIC.ARPA>, enger@SCRC-QUABBIN.ARPA
Subject:   Re: RCTE
Never having been at all fond of reinventing wheels, I hastened to
FTP the SUPDUP RFC and print it out at my terminal.  When I got to
"Due to the highly interactive characteristics of both the SUPDUP
protocol and the ITS system [which was the original Server for which
the protocol was developed], all transactions are strictly character
at a time and all echoing is remote" I aborted the printing.  Am I
misunderstanding something--the context is, as far as I know, avoiding
"unnecessary" transmissions--or have you misremembered SUPDUP?
(If the latter, let me be the first to welcome you to Early Middle Age.)
As things stand, I have to deem SUPDUP a reinvention of the travois,
in context; please correct me if I'm wrong.
   cheers, map
-------
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 11:07:27 EDT
From:      vwhite@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   more on LONEX?

29 September 1987

Merton, Dennis, Steven:

Thank you for responses about the LONEX system.  We have some
questions:

It sounds as if the primary function of LONEX is
keeping most of the processing on a larger system,
away from the PCs, but is doing load balancing to share
the work among several such larger systems.  Are we on the
right track?  How about the supported spreadsheet and database 
programs; are they implemented on the server or the PCs? 

Where is the mail delivered?  Do users have mailboxes on the
server?  (It doesn't sound like mail is delivered directly
to the PC.)  Can users send mail from the PC or must they
do so directly from the server?  How about printing?  Must
the user queue print jobs from the server or can he do so from
the PC?

Why are these terminals and PCs connected to your larger systems
via an ethernet?  Most of the implementations we've seen in
which PCs accessed servers only as terminal emulators use asynchronous
connections; it's cheaper and can handle the requirement.  Is
LONEX offering a service that makes the ethernet important?  (perhaps
those database programs are distributed database servers?)

You said LONEX runs on 2.9bsd or 4.3.  Did you mean, in addition,
anything in the middle?  How about vendor implementations of 4.2 such
as those of Pyramid or CCI?  What software is required on the PC?

Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA)
implement a file server?  If you could describe them briefly we might 
know whether it was worthwhile to go looking for more information.

Thanks for the help!  We want to learn as much as we can
from other people before we make any decisions.

Vicky White
Code K33
NSWC
Dahlgren, VA  22448
(703) 663-7745
vwhite@nswc-g.arpa

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29 Sep 87 14:16:05 PDT
From:      braden@braden.isi.edu
To:        AUERBACH@csl.sri.com, lazear@gateway.mitre.org, tcp-ip@sri-nic.arpa
Subject:   Re:  TCP performance limitations
	
	Karl,
		It sounds like you've removed the major bottlenecks and
	throughput ought to approach infinity!  :-)  Without queue delays,
	transmission delays, checksum computing delays, and retransmissions,
	there's not much left to stall data.
	
		Walt
____________________________
	
The max TCP window size (2**16) divided by the round-trip delay.

    Bob Braden
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 11:30:50 EDT
From:      sfp@APLPY.ARPA (Steven Parr)
To:        comp.protocols.tcp-ip
Subject:   closing half-open connections

Hi,

We are having problems with tcp connections getting hung in the LAST_ACK state.
I believe the fault lies with the software at the other end of the connection
and so we are in the process of getting an update of that software.  However
purchasing takes time and in the mean time, we keep re-transmitting a FIN
every second or two until the next reboot.

So my question is this:

Does anyone know of a way to force closed a half-open connection such as this?

Seems to me that you should be able to change the state to FIN_ACK_2 or
TIME_WAIT and the connection should go ahead and close itself on the next
expiration of the timer.  Has anyone tried anything like this?  Any suggestions
on how to go about it?  (Looks like adb may be useful, but I know almost nothing
about it.)

If it matters, we have a Pyramid running release 3.1 (without source).

Thanks in advance,
-Steve Parr

sfp@aplpy.arpa

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 12:07:26 EDT
From:      slevy@UF.MSC.UMN.EDU (Stuart Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE

I've just submitted an RFC that tries to deal with this problem --
it basically is CCITT's X.3 adapted for Telnet, with extensions.
So it does things like local editing, echoing, selective forwarding,
flow control &c, all controllable from the host side.
It -doesn't- try to do as much as RCTE.  It also doesn't try to
provide for general local screen editing, e.g. interpreting & buffering cursor
movements -- that seems like an awful lot to pile onto a poor Telnet protocol.


I'm leaving the draft RFC for anonymous FTP from uc.msc.umn.edu,
as "staff/rfc.x3", if anyone's interested.

					Stuart Levy
					Minn. Supercomputer Center
					612 626 0211

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 87 16:15:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   TCP performance


Hey Folks,

Physics won't let us go infinitely fast!!!
A practical limit is probably related to distance.

Lets look at the facts:

	TCP has a maximum window size of 65535 bytes (16 bit field).

 	Single satellite hop is approx. 1/2 sec round trip (approx.
	90 Thousand miles).

	Thus for satellite, max. rate is about (65535*8)/(0.5)
	  or 1.048 Megbit/sec.

	Coast to Coast should be about 30 times quicker, or
	about 30 Megbit/sec.

Of course, this is for a single TCP session,  multiply for number of
concurrent sessions.

					Art Berggreen
					art@acc.arpa
------
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 14:12:08 EDT
From:      CASNER@VENERA.ISI.EDU (Stephen Casner)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance limitations

Karl,
	For all the variables you mention, you've specified values that
would pose no limit to TCP performance.  However, you left out one
critical variable:  delay.  If the bandwidth and processing power are
infinite, the sender will immediately transmit as many octets as the
receiver's window will allow.  The sender cannot transmit any more until
an ACK is returned, and the receiver cannot send an ACK until the data
gets there.  Therefore, the maximum throughput is one window's worth of
octets every round-trip delay time.

	The window size is determined by the amount of buffer space
available in the receiver.  If you assume buffer space is also
unlimited, then you bump into the first real limit:  the maximum TCP
window size is 64K octets because it is carried in a 16-bit field.  To
cite a real example, the Wideband Satellite Network has a raw data rate
of 3Mb/s, but it also has a round-trip delay time of 1.8 seconds.  The
maximum TCP throughput is 64K octets per 1.8 seconds or 290Kb/s.

	There have been proposals by the INENG Task Force and others to
define a TCP option to carry a larger window-size field.  If you assume
this option field could be as large as necessary, then the only limits
left are physical:  the speed of light and the distance between hosts.

							-- Ste.

A with t time
r

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 15:24:41 EDT
From:      kent@DECWRL.DEC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance limitations

There are some protocol details (like the IP identification field) and
common MTUs that will limit the data rate.

chris

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 15:48:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE

I assumed, incorrectly it turns out, that your requests for local
echoing and display-oriented terminal service were separate.  If your
goal is to minimize network traffic, then indeed, SUPDUP is not for you.
if your goal is to minimize program (e.g., editor) wakeups, then you
can still use SUPDUP as is.  You do need to make a system call that
causes the system, not the program, to do the echoing and return control
to the program on the special characters.  ITS has such a system call.
Multics has such a system call and/or communication with its front end.

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 18:18:59 EDT
From:      mmolle@Q2.ICS.UCI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance limitations

Hey, wait a minute!  Even assuming no errors, arbitrarily high data rates
and arbitarily fast processors interpretting the protocols, there is still
propagation time across the channel to contend with.  Assuming a window
size of one (a.k.a. "stop and wait") you get at most one frame per round
trip time, i.e., a finite maximum data rate.  A larger (but still finite)
window size of W outstanding and unacknowledged frames raises that bound
by a factor of W, but it certainly doesn't give you infinite throughput.

Does that clarify the situation, or am I missing something deeper?

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 18:32:55 EDT
From:      andrew@mitisft.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE


	It seems to me there are is a middle ground in here, between
char-at-a-time and line- (or screen-) at-a-time, that can be implemented
purely on the server side using the normal telnet protocol (ECHO negotiation).
We are considering implementing this for support of low speed TCP links
(eg async modems), and I'm curious if I'm going to run into some "common
knowledge problem"...

        The basic idea is to have the kernel (virtual terminal driver) inform
the telnet daemon when it *would be* doing immediate character echo, and
not do it.  The daemon turns this information into echo negotiation, which
the client (hopefully) heeds.  This results in speeded echo response in
(for example) un*x "cooked" mode, plus a reduction in packet traffic.

	Has anyone tried this?  The UCB virtual terminal driver has some
hooks in it ("packet mode", currently used for flow control negotiation
with rlogin) that could be used for this (after extension).

Andrew Knutsen
(408)435-3623

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 19:49:00 EDT
From:      SRA@XX.LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   RCTE and stranger things

I was going to say something about that, but decided to wait to see if
anybody had in fact read Dave's message.  You did, so here goes.

Yes, SUPDUP as specified in the RFC is character at a time.  However,
I believe that a very minor enhancement to the protocol would handle
that problem.  The big advantages of SUPDUP (sales pitch) are that (1)
it works in a heterogenous environment (thus is better than rlogin),
and (2) has a wider view of the terminal than just the print head of a
hardcopy TTY (thus is better than TELNET).  In particular, there are a
whole set of useful options under the heading of "The Intelligent
Terminal Protocol".  Not all of these are documented in the SUPDUP
RFCs, for a full explanation of the ITS terminal system see the file
"MC: INFO; ITSTTY >" on MC.LCS.MIT.EDU.  It's a bit long, so if you're
not up for a lot of reading, you want the parts on "Control of the
TTY" and "The Intelligent Terminal Protocol".

The model I'm using for the local/remote echo and wakup problem is the
TOPS-20 TEXTI% JSYS, which was mentioned obliquely a few messages ago
when somebody referred to TOPS-20 EMACS enhancements.  For those who
aren't familiar with TOPS-20, one of the arguments to TEXTI% is a
break mask, a 128 bit vector indicating which characters should cause
the TEXTI% call to return.  I believe that the EMACS extentions that
were mentioned were based on an extension to TEXTI% which would cause
any character with the meta bit (octal 200) turned on to act as a
wakeup.  I may be wrong about this, I've never seen the code.

Presumably the entity that decides what the break mask should be is
the server (where applications programs are running) while the entity
that implements the break mask is the client (where the physical
display terminal is).  So presumably the "change the break mask"
sequence would begin with a %TDxxx code.  I can't think of any reason
why the client would want to tell the server about break masks, but if
so the process would be identical except for the escape character (a
30x code, presumably).  Henceforth I'll refer to the entity sending
the break mask as the "sender" and the entity receiving the break mask
as the "recipient".

For the 12 bit character set SUPDUP permits, a complete break mask
would be rather cumbersome, but there's a natural way to compress
this.  Make the first data byte a flag byte, with one flag per bucky
bit, one flag for characters with no bucky bits, and two unused bits.
The flag bits indicate which bucky bits the sender wants the client to
try to optimize; if a flag bit is set, a break mask is supplied, if a
flag is cleared, no break mask is supplied and the receiver should
fall back to the default behavior (wake on every character).  The most
common message would presumably be one with the no-bucky-bit and
control-bucky-bit flags set and all others cleared, indicating that
any meta, super, or hyper characters are wakeups.  In general, if a
program doesn't expect to see a class of characters, it should
probably wake up on them so that it can tell the user about typing
errors ASAP.

The flag byte is followed by a series of break masks (128 bits in 16
bytes, presumably).  For completeness, this would have to be separate
break masks for each case that the sender has indicated in the flag
byte; ie, just because the sender wants to break on CONTROL-A and
META-A doesn't mean the server wants to break on CONTROL-META-A.  This
is part of the reason for the flag byte, so that the sender needn't
send a lot of masks that are all ones.

All SUPDUP connections would still start out in character at a time
remote echo mode.  Setting the break mask requests local echo of any
characters that are not breaks.  Break characters are still handled
remotely.  Setting the break mask with a zero flag byte (and thus no
following masks) would put the connection back in the default
character at a time mode.

One extension of this idea would be incremental changes to the break
mask; if anybody cares enough to do it, there's always the two unused
bits in the flag byte.  But the above covers the basic scheme.

Yes, a similar mechanism could be used in TELNET, without having to
think about 12 bit characters and bucky bits, but TELNET is really not
a very good model for a display terminal.  SUPDUP (and the abstract
model of terminals and capabilities that underlies it) is a much
better model.  I think the existing software speaks for itself.

--Rob

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 20:15:00 EDT
From:      art@ACC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   TCP performance



Hey Folks,

Physics won't let us go infinitely fast!!!
A practical limit is probably related to distance.

Lets look at the facts:

	TCP has a maximum window size of 65535 bytes (16 bit field).

 	Single satellite hop is approx. 1/2 sec round trip (approx.
	90 Thousand miles).

	Thus for satellite, max. rate is about (65535*8)/(0.5)
	  or 1.048 Megbit/sec.

	Coast to Coast should be about 30 times quicker, or
	about 30 Megbit/sec.

Of course, this is for a single TCP session,  multiply for number of
concurrent sessions.

					Art Berggreen
					art@acc.arpa
------

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Tue, 29-Sep-87 20:36:14 EDT
From:      lamaster@pioneer.arpa (Hugh LaMaster)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance limitations

In article <8709290008.AA00477@ucbvax.Berkeley.EDU> AUERBACH@CSL.SRI.COM (Karl Auerbach) writes:

>Someone asked me today what are the performance limits on a TCP connection.
>The situation he posited was on in which there are no intervening
:
>resources in the hosts, and low noise.  It was further posited that

An interesting question. It depends on HOW low noise your connection is.
Because of acknowledgement and retransmission requirements, the faster the
link, the lower noise it has to be to maintain a high delivered fraction of
the raw channel speed.  This is in addition to the question of the interaction
of acknowledgement delay and window size, which some have mentioned, and which
is also a big problem.  To realize the high bandwidth in practice requires
host software smart enough to adaptively distinguish between a high bandwidth
low noise channel, and something like Arpanet, and adjust its behavior
appropriately to either situation.  Offhand, I am not sure how to do this.
Anybody have any ideas?





  Hugh LaMaster, m/s 233-9,  UUCP {topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

(Disclaimer: "All opinions solely the author's responsibility")

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 00:32:06 EDT
From:      mark@comp.vuw.ac.nz (Mark Davies)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Kinetics power supplies

We just got a kinetics box (KFPS-2) and want to set it up to use 220v
(actually 240v) power supply.  The installation guide keeps refering to
Appendix B for details on adapting the power supply.  Unfortunately our
manual has an Appendix A and an Appendix C but *NO* Appendix B (pages 63
and 64 are missing).

Does anyone out there know what needs to be done?

Replies by mail to the below address please.

mark
-- 
Domainised:  mark@comp.vuw.ac.nz	Bang form: ...!uunet!vuwcomp!mark

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 01:15:14 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   TCP performance limitations


    ... what are the performance limits on a TCP connection .... in which
    there are no intervening IP routers, massive availability of underlying
    bandwidth, massive computing resources in the hosts, and low noise.
    ... the hosts could be using acknowledgement strategies highly tuned for
    this specific situation.

    			Thanks, --karl--

My initial estimate would be based on the media bandwidth and the memory
bandwidth of the host.  If the memory bandwidth of the host limits, then
I would expect the data rate will be on the order of the memory bandwidth
times the number of times the data must be copied on the way out (count DMA
and the checksum, please).  If the net bandwidth limits, I would guess
somewhere between 40% and 80% of the network bandwidth, depending on the
architecture (CSMA/CD maybe towards the low side, well-implemented Token
Passing maybe towards the high side?).

Memory bandwidth definitely dominates on the implementation I am most
familiar with.  We recently unrolled the TCP checksum loop, and a ~35%
speed improvement there produced a ~15% overall throughput increase on
memory-to-memory TCP.  This got us up to 1.4 Mbits/sec between two 8Mhz
AT clones on a lighty-loaded Ethernet (with 3rd-generation boards - LAN
controller chip & multiple packet buffers, but no processor).  40% of a
4.3-modified Sun (3.5 Mbits/sec per a recent posting)...

James B. VanBokkelen
FTP Software Inc.

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 01:17:04 EDT
From:      dyer@spdcc.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE

I am aware of an effort at BBNCC a few years ago in support of the MINET
(European MILNET) network to handle this via TELNET echo negotiation when
switching between RAW, CBREAK and "cooked" terminal modes.  MINET trunk
lines at the time were 9600 baud, hence the desirability of minimizing
micro-packet traffic induced by character echoing.

I don't remember exactly how successful this was, perhaps because many of
the applications they were using ("vi", InfoMail, "tcsh") preferred to run
in character-at-a-time mode with echoing under the explicit control of the
application.  Cooked mode applications seemed to work OK, as I remember.
-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 01:27:51 EDT
From:      JTW@XX.LCS.MIT.EDU (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE


Hmm. The basic SUPDUP protocol doesn't address the remote echoing
overhead problem at all, and won't do a thing for those paying
per-packet charges, which is how this all started.

Some (long) time ago Richard Stallman designed and implemented an
extension called the SUPDUP Local Editing Protocol, which allowed a
remote display-oriented program, such as EMACS, to arrange to have
most operations performed at the user's local terminal, with
information transferred to the remote end as required. This vastly
reduces the need to send screen update information over the net, and
allows bunching of update information into a few large packets rather
than zillions of one-character ones. Network utilization is improved
in both directions.

This protocol was documented in at least one MIT AI Lab memo. I think
the final version of the AI memo that described SUPDUP included it
also.

SUPDUP LEP is to some extend a superset of the functionality of RCTE,
and could be useful for reducing the load caused by
non-display-oriented programs.

The basic SUPDUP protocol has some very good ideas about how to do
virtual terminals, but could use some updating. A new protocol could
be based on the structure of SUPDUP, maintaining the LEP and input
processing concepts, but with a newer set of capability descriptors in
the startup negotiation and output encodings based on the ANSI X3.64
terminal standards. This protocol would nicely address both the
network efficiency concerns raised here and the problems which come up
using arbitrary window-based emulators as remote terminals.
-------

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Sep 87 05:02:01 PDT
From:      wilt@trout.nosc.mil (Steven M. Wilt)
To:        tcp-ip@sri-nic.arpa
Subject:   Removal from tcp-ip relay list
-------
Pls remove my address from the tcp-ip relay list.
Thanks
-------

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 08:02:01 EDT
From:      wilt@TROUT.NOSC.MIL (Steven M. Wilt)
To:        comp.protocols.tcp-ip
Subject:   Removal from tcp-ip relay list

-------
Pls remove my address from the tcp-ip relay list.
Thanks
-------

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 08:24:28 EDT
From:      turkewit@CCV.BBN.COM ("Kenneth A. Turkewitz")
To:        comp.protocols.tcp-ip
Subject:   Re:  RCTE


Steve,
	The MINET experiment was fairly successful, but was very limited
in scope.  The users on the MINET were using NO screen editors, or
anything else that required "special" characters to be noticed right
away.  As a matter of fact, all MINET applications were tailored so that
a response was not needed until a linefeed was seen.  Hence, MINET users
were all able to run in a "line at a time" (i.e. send characters only
on line feed) mode.
	(This only lasted for a short time, due to a minor bug that needed
to be fixed in the BBN O/S kernel or the TELNET server, I forget which.  By
the time it was fixed, nobody really wanted to go back to the line-at-a-time
mode, despite the savings on the network trunks.)
	Interestingly, during the planning and integration of the MINET
project, we were seriously considering using RCTE (or a modification of it,
known as "RACE" [Remote Application Controlled Echoing] in our planning
sessions).  The MINET people were not particularly interested in funding
it, however.
		--Ken

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Sep 87 8:24:28 EDT
From:      "Kenneth A. Turkewitz" <turkewit@CCV.BBN.COM>
To:        Steve Dyer <spdcc!dyer@HUSC6.HARVARD.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  RCTE

Steve,
	The MINET experiment was fairly successful, but was very limited
in scope.  The users on the MINET were using NO screen editors, or
anything else that required "special" characters to be noticed right
away.  As a matter of fact, all MINET applications were tailored so that
a response was not needed until a linefeed was seen.  Hence, MINET users
were all able to run in a "line at a time" (i.e. send characters only
on line feed) mode.
	(This only lasted for a short time, due to a minor bug that needed
to be fixed in the BBN O/S kernel or the TELNET server, I forget which.  By
the time it was fixed, nobody really wanted to go back to the line-at-a-time
mode, despite the savings on the network trunks.)
	Interestingly, during the planning and integration of the MINET
project, we were seriously considering using RCTE (or a modification of it,
known as "RACE" [Remote Application Controlled Echoing] in our planning
sessions).  The MINET people were not particularly interested in funding
it, however.
		--Ken
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 09:40:00 EDT
From:      CERF@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance limitations

Karl,

I have been doing some work in this area to predict potential
performance at 100 Mb/s FDDI rates. First, you can expect a
TCP to execute about 1000-1200 instructions per packet,
assuming all is well. Some of this is checksum. In fact, I
recall some early statistics in which the checksum alg took up 40% of the
CPU cycles for processing incoming segments of TCO. I am lumping
IP level processing into TCP in the 1000-1200. This is absolutely
a WAG - so anyone with some hard data on instruction count is
most welcome to provide better info.

Roundtrip time and window size limitations affect performance
with respect to total throughput, all other things ignored.

Suppose you were operating at 10MB (megabytes)/second and
had a prop. delay of 10 microseconds on the ring.

With no constraints, and using 1000 byte packets, you would
be sending 10,000 packets/second to achieve full throughput.
That gives you 100 microseconds worth of insruction time.
At 14 MIPs, that is 1400 instructions. So, if you did nothing
else but TCP/IP, you might make it, with respect to
instruction rate.

Window size limitations: you can have 65,536 bytes outstanding
and at 10 MB/sec, it takes 6.5 ms to send them. Assuming you
can send the ack in the 100 microseconds you have to "process"
the packet, it takes 10 microseconds + 100 + 10 = 120 usec
(2 X propagation delay plus processing time) to get the ACK.
Even asusming another 100 usec to process the ACK, that 220 usec
worth of window needed, minimum. That's only 2200 bytes - so
even a factor of 10 increase is well within the window capacity
of the TCP.

The killer in all this is propagation and round-trip delay. It
doesn't take much to cause the window requirment for full
bandwidth to exceed the maximum allowed window of outstanding
bytes. For example, a round-trip time of 10 ms (the prop
delay of only 1000 miles, one way!) requires a window of 
over 100KB to maintain full capacity at 10MB/sec.

What these very sketchy and rough numbers suggest is that
window-based schemes won't be very satisfactory for long haul,
long delay, very high speed nets. Flow control based on rates is needed,
rather than on round-trip acks/permissions - of course, this is precisely
the kind of thinking that I believe underlies the work that
Dave Clark has been doing with NETBLT (Dave, holler if I
have put words/thoughts into your work inappropriately).

To sum up, TCP can probably be made to work well in low delay
systems at pretty high speeds, maybe up to 100 Mbit/sec, but
probably not at a gigabit and probably not at long haul cross
country at 100's of megabits/sec.

By the way, most of these same considerations apply to ISO TP,
in my estimation.

Vint

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1987 09:40-EDT
From:      CERF@A.ISI.EDU
To:        AUERBACH@CSL.SRI.COM
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: TCP performance limitations
Karl,

I have been doing some work in this area to predict potential
performance at 100 Mb/s FDDI rates. First, you can expect a
TCP to execute about 1000-1200 instructions per packet,
assuming all is well. Some of this is checksum. In fact, I
recall some early statistics in which the checksum alg took up 40% of the
CPU cycles for processing incoming segments of TCO. I am lumping
IP level processing into TCP in the 1000-1200. This is absolutely
a WAG - so anyone with some hard data on instruction count is
most welcome to provide better info.

Roundtrip time and window size limitations affect performance
with respect to total throughput, all other things ignored.

Suppose you were operating at 10MB (megabytes)/second and
had a prop. delay of 10 microseconds on the ring.

With no constraints, and using 1000 byte packets, you would
be sending 10,000 packets/second to achieve full throughput.
That gives you 100 microseconds worth of insruction time.
At 14 MIPs, that is 1400 instructions. So, if you did nothing
else but TCP/IP, you might make it, with respect to
instruction rate.

Window size limitations: you can have 65,536 bytes outstanding
and at 10 MB/sec, it takes 6.5 ms to send them. Assuming you
can send the ack in the 100 microseconds you have to "process"
the packet, it takes 10 microseconds + 100 + 10 = 120 usec
(2 X propagation delay plus processing time) to get the ACK.
Even asusming another 100 usec to process the ACK, that 220 usec
worth of window needed, minimum. That's only 2200 bytes - so
even a factor of 10 increase is well within the window capacity
of the TCP.

The killer in all this is propagation and round-trip delay. It
doesn't take much to cause the window requirment for full
bandwidth to exceed the maximum allowed window of outstanding
bytes. For example, a round-trip time of 10 ms (the prop
delay of only 1000 miles, one way!) requires a window of 
over 100KB to maintain full capacity at 10MB/sec.

What these very sketchy and rough numbers suggest is that
window-based schemes won't be very satisfactory for long haul,
long delay, very high speed nets. Flow control based on rates is needed,
rather than on round-trip acks/permissions - of course, this is precisely
the kind of thinking that I believe underlies the work that
Dave Clark has been doing with NETBLT (Dave, holler if I
have put words/thoughts into your work inappropriately).

To sum up, TCP can probably be made to work well in low delay
systems at pretty high speeds, maybe up to 100 Mbit/sec, but
probably not at a gigabit and probably not at long haul cross
country at 100's of megabits/sec.

By the way, most of these same considerations apply to ISO TP,
in my estimation.

Vint
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 10:26:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   SUPDUP protocol


    Date: Mon 28 Sep 87 15:31:31-PDT
    From: William Westfield <BILLW@MATHOM.CISCO.COM>
	...
    What it amounts to is that most operating systems are STILL dealing
    with the terminal as if it were a printer, and that this probably has
    to change before a smarter virtual terminal protocol can be defined.

That's an interesting point.  I can name at least two operating systems
that natively know about display terminals and considered printing
terminals as a (crippled) subset.  I believe they knew this as long as
15 years ago.  They are: ITS (developed at the MIT AI lab) and, if
memory serves, WAITS (developed at Stanford).  There are things in ITS
that are profound even today, since as you say, "most OSs are STILL"
wedged about terminal==printer.  SRA and JTW aren't talking through
their teeth; they are familiar with and have access to existing systems
that know about display terminals and have for many years.

The cynic in me says you won't see much real improvement in Unix or VMS
or whatever unless and until their owners bite the bullet, commit to
entering the 1980s (from the 1960s), and pour money into the development
hole.  I would actually suggest they try to be visionaries and enter the
1990s.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 12:51:51 EDT
From:      GLM@IPGUNIV.BITNET (Gianfranco Galmacci)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE

please remove me
Acknowledge-To: <GLM@IPGUNIV>

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 13:52:24 EDT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: RCTE


    The basic idea is to have the kernel (virtual terminal driver) inform
    the telnet daemon when it *would be* doing immediate character echo,
    and not do it.  The daemon turns this information into echo
    negotiation, which the client (hopefully) heeds.  This results in
    speeded echo response in (for example) un*x "cooked" mode, plus a
    reduction in packet traffic.

This means that the client must send every character immediately to
the host, and then wait (for an indeterminate time) for a response
from the host that indicates whether the next characters should not
be echoed.  (This is in the worst case, of course.  If you are willing
to assume that when the client is doing local echo, it is doing local
echo of ALL characters, and that it doesn't matter if the client
accidently echos some characters it should not have or doesn't echo
some characters it should have, it may indeed help...)

Bill Westfield
cisco Systems
-------

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 15:32:29 EDT
From:      lamaster@pioneer.arpa (Hugh LaMaster)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP performance limitations

In article <[A.ISI.EDU]30-Sep-87.09:40:42.CERF> CERF@A.ISI.EDU writes:

>
>What these very sketchy and rough numbers suggest is that
>window-based schemes won't be very satisfactory for long haul,
>long delay, very high speed nets. Flow control based on rates is needed,
>rather than on round-trip acks/permissions - of course, this is precisely
>the kind of thinking that I believe underlies the work that
>Dave Clark has been doing with NETBLT (Dave, holler if I
>have put words/thoughts into your work inappropriately).
>

I have seen/heard references to rate based flow control before - but I haven't
seen (or maybe remembered) what the idea is.  Is there a summary somewhere or
could someone summarize the basic idea?  (Is there an RFC? etc.)





  Hugh LaMaster, m/s 233-9,  UUCP {topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

(Disclaimer: "All opinions solely the author's responsibility")

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 15:37:49 EDT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   closing half-open connections

I assume that Pyramid release 3.1 has the Berkeley 4.2 network layer.
In this case you can force the connections closed.  I wrote a program
to do this a while back, but it's full of unix source I shouldn't
redistribute to someone without a source license...

To do it by hand, run
	netstat -A 
and find the address of the PCB for the connection.  This is the hex
number in the first column).  Then start adb with
	adb -w -k /vmunix /dev/kmem

and zero out the short word 8 bytes past the address of the PCB (this
is the size of the offset on the vax, it may vary on the Pyramid.  You
can check it by looking at struct tcpcb in <netinet/tcp_var.h>, and
finding the offset to t_state)
	address+8/w 0
this forces the state of this connection to CLOSED.  The next time a
timer fires for that connection, it will notice that it is in the
closed state and deallocate it.  You can exit adb with
	$q
I suspect that this would work on 4.3 based network layers also,
although the bug shouldn't exist there that requires it.
					-Mark

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 18:26:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  RCTE

The MCI Mail system, which runs on an X.25 version of the BBN C.30 packet
net, is a line-at-a-time system which forwards on CR and does intra-line
editing at the PAD (TAC). Most users preferred that mode because
of the immediate echoing response. Remote echo mode was simply not
acceptable. Of course, many of the long haul lines were 9.6 rather
than 50 kb/s and this contributed to increased "stickiness" of the
echoing. On the whole, I felt strongly for that particular application
the line at a time mode was best - presuming, of course, that most
of the real text editing was done off-line with a PC and that the
interaction was mostly for preparation of addressees.

Eventually, PC packages like Lotus Express and Desktop Express for
the IBM PC and Apple Macintosh were produced which largely decoupled
the users from any direct interaction exposing the network. Most users
of these packages prefer not to go back to the direct mode at all,
I believe.

The point of all this is to argue that localizing much of the
interaction which would otherwise require char-by-char network
support seems preferable and in keeping with trends towards more
powerful, local workstations using background processes to handle
network activities.

Vint

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30 Sep 87 17:28:37 SET
From:      Gianfranco Galmacci <GLM%IPGUNIV.BITNET@WISCVM.WISC.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: RCTE
please remove me
Acknowledge-To: <GLM@IPGUNIV>
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Wed, 30-Sep-87 23:53:15 EDT
From:      andrew@mitisft.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: closing half-open connections


	While I dont have any suggestions for closing existing half-open
connections (although I think someone posted something awhile back), I
do have a scenario which I have seen cause this, which can be traced to
an ambiguity in the RFC...

	Scenario:

1) Server sends FIN, gets ACK, enters FIN_WAIT_2.

2) Client sends a bunch of data.

3) Server's window size goes to zero due to normal flow control.

4) Client closes connection.
	At this point, client has data buffered, and needs a window update.
	FIN hasnt been sent since data is pending.

5) Client is now in LAST_ACK.  However, he ignores window updates, looking
	only for ACK of FIN he hasnt sent! The connection is effectively
	idle.

	Now, the RFC says all data should be sent after a close (pgs 49 & 61),
and that when a segment arrives in LAST_ACK state only the ACK of FIN should
be checked for (pg 73).

	4.3 seems to have "fixed" this problem by both flushing data on a close
and putting a timer on FIN_WAIT_2, along with having just about everybody
use "linger mode" where the close delays till the data drains (not the default).
I fixed it by looking at window updates during LAST_ACK; not exactly spec,
but harmless (apparently) in the normal cases....

Andrew

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1-Oct-87 03:22:15 EDT
From:      mkhaw@teknowledge-vaxc.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: closing half-open connections

Here's a /bin/sh driven adb script posted to the net a while back that
forces a socket to close:

<--- cut here --->
#! /bin/sh

# original from cdjohns@NSWC-G.ARPA
#
# TIMETODEATH expressed in decimal instead of hex
#	-- mkhaw@teknowledge-vaxc.arpa

# Use this script to force sockets in FIN_WAIT_2 state to close.
# It works by setting the 2MSL timer in the TCP Protocol Control Block (PCB)
# to a non-zero value.  The kernel then begins to decrement this value until
# it reaches zero, at which point the kernel forces a close on the socket and
# deletes the TCP PCB.  If both sides of the connection are hung, clearing one
# side will possibly clear the other.

# MSLOFFSET is the offset in the tcpcb record for the 2MSL timer.
# <netinet/tcp_var.h> describes the tcpcb record.
# This value is the number of bytes offset, expressed in hexadecimal.

MSLOFFSET=10

# TIMETODEATH is the number of half seconds until the connection is 
# closed.  This value is expressed in decimal and must be greater
# than zero.

TIMETODEATH=06

# Display netstat to get PCB addresses (first column).
echo 'Active connections
PCB      Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)'
netstat -A | fgrep FIN_WAIT_2

echo
echo -n 'PCB address to terminate? '
read addr
echo

# Use adb on kernel to display the PCB of the specified address
adb -k /vmunix /dev/mem << SHAR_EOF
$addr\$<tcpcb
\$q
SHAR_EOF

# Check to see if this was the correct address and PCB. state should be
# 8 for LAST_ACK, 9 for FIN_WAIT_2
echo
echo 'state = 9 = FIN_WAIT_2'
echo -n 'Is this the correct PCB (y/n)? '
read ans
echo
case $ans in
  [Yy]*)
	;;
  *)
	echo 'No Changes.'
	exit
	;;
esac

# Use adb on kernel to set the 2MSL timer for the PCB
adb -k -w /vmunix /dev/mem << SHAR_EOF
$addr+$MSLOFFSET/w 0t$TIMETODEATH
\$q
SHAR_EOF

# Use these lines in place of the above for testing the script.
#adb -k  /vmunix /dev/mem << SHAR_EOF
#$addr+$MSLOFFSET/x 
#\$q
#SHAR_EOF

echo
echo 'Connection will be terminated in `expr $TIMETODEATH / 2` seconds.'
echo 
<--- cut here --->

Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

END OF DOCUMENT