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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Jun 87 11:26:03 -0400
From:      Robert Hinden <hinden@CCV.BBN.COM>
To:        Nick Gimbrone <NJG%CORNELLA.BITNET@WISCVM.WISC.EDU>
Cc:        tcp-ip@SRI-NIC.ARPA, hinden@CCV.BBN.COM
Subject:   Re: IP Datagram sizes
Nick,

In fact most of the networks that make up the Internet have MTU's smaller
than 1500 bytes.  Here is a summary:
     
     Wideband     2048
     Pronet Ring  2040
     Ethernet     1500
     Arpanet      1007
     NSFNET        576
     PDN           512
     Suran         320
     Satnet        256
     Packet Radio  226

Hope this helps.

Bob
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 10:47:22 EDT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   IP datagram sizes



Of course, if you use X.25 you don't have this problem :-). The
switches can use level 2 to support fragment sizes properly
over each hop, and level 3 to get end to end packet sizes
efficient, and a well known transport protocol over that...

Then all you need is to work out how to get CCITT to accept
giant window size and packet size options to make it work well
over a big network.

The strain of hop by hop versus end to end arguments starts to
show when you try and use an underengineered mil-spec net for
heavy duty service.

What Vint says sounds good to me - figure out how to get hop by
hop information back to the end to end protocols so they can be
taught how to behave properly. Real problem here is for short
lived protocol entities - eg query systems running in PCs - who
dont get a chance to used previously cached info...

jon

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 11:00:11 EDT
From:      jon@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Invalidating ARP Caches


I have only had one answer on how to invalidate arp caches in
hosts when i move my IP (proxy arp) subnet router, so here's my
thoughts...

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

Could call this NARP (not arp):

I am considering writing  a service that listens for IP broadcasts
(multicasts when available) and invalidates arp caches on basis
of these. When (before/after) a router moves, it will still
forward these packets so sitting on any host I can (hopefully
only with certain privilages) say:

arpinval {ip addr}*

which will broadcast some packet like

IP header with NARP type + <IP Addr Addr etc)

(has to be IP broadcast, not lower level or the IP subnet routers wont
forward it). When routers get clever, they could send this
packet for me.

Any reason not to do this, apart from the obvious possible
misuses and broadcast traffic (though only one broadcast to fix
a lot of hosts)?

jon

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 11:45:07 EDT
From:      hinden@CCV.BBN.COM (Robert Hinden)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Datagram sizes

Nick,

In fact most of the networks that make up the Internet have MTU's smaller
than 1500 bytes.  Here is a summary:
     
     Wideband     2048
     Pronet Ring  2040
     Ethernet     1500
     Arpanet      1007
     NSFNET        576
     PDN           512
     Suran         320
     Satnet        256
     Packet Radio  226

Hope this helps.

Bob

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 14:22:11 EDT
From:      braden@ISI.EDU (Bob Braden)
To:        comp.protocols.tcp-ip
Subject:   Re:  TN3270


	
	I inquired of a Network Solutions salesperson after one of their
	presentations at the conference in Monterey this past March, and
	he said that their DDN/MVS did not support 3270-mode telnet.
	
There must have been some misunderstanding about the question or the
answer.  DDN/MVS is based on the UCLA MVS code, which certainly does
support 3270-mode Telnet, and always has.  I have a tn3270 icon on my
Sun screen, which I occasionally open to log into TSO on the UCLA 3090
and use PDF in full-screen.  Now that the ARPANET is back from the dead,
it works quite snappily, too.

Bob Braden

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 15:25:50 EDT
From:      boesch@Shasta.STANFORD.EDU (Brian Boesch)
To:        comp.protocols.tcp-ip
Subject:   A question about link performance and TCP


I have a question about studies in performace of TCP over various
networks and data links.

Does anyone know of studies into the performance of TCP over various 
networks especially where different datalink protocols are involved.
The current discussion of TCP segment size selection prompted my interest 
in this.  I have read RFC889 "Internet Delay Experiments".

Please reply to:
	boesch@umunhum.stanford.edu

Thanks
	Brian

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 87 15:23:37 GMT-0:00
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   IP datagram sizes


Of course, if you use X.25 you don't have this problem :-). The
switches can use level 2 to support fragment sizes properly
over each hop, and level 3 to get end to end packet sizes
efficient, and a well known transport protocol over that...

Then all you need is to work out how to get CCITT to accept
giant window size and packet size options to make it work well
over a big network.

The strain of hop by hop versus end to end arguments starts to
show when you try and use an underengineered mil-spec net for
heavy duty service.

What Vint says sounds good to me - figure out how to get hop by
hop information back to the end to end protocols so they can be
taught how to behave properly. Real problem here is for short
lived protocol entities - eg query systems running in PCs - who
dont get a chance to used previously cached info...

jon
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 19:41:16 EDT
From:      RAF@NIHCU.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Domain Name Servers

Any recommendations as to what to use for an Internet domain name
server if one doesn't have a VAX Unix machine to use?  Our primary
mainframe is an IBM 3090 running MVS/XA, but none of the IBM MVS
implementations has a domain name server.  I believe that the new
IBM TCP/IP for VM product has one, but we don't run VM.  A domain
name server that could run on a PC, either under DOS or some flavor
of Unix would be real handy for us.

I am sending this to 3 lists, sorry for duplicates that you may
receive.

Roger Fajman
BITNET:    RAF@NIHCU
Internet:  RAF%NIHCU.BITNET@WISCVM.WISC.EDU

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Jun 87  19:41:16 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA, nsfnet@nnsc.nsf.net, IBM-NETS@BITNIC
Subject:   Domain Name Servers
Any recommendations as to what to use for an Internet domain name
server if one doesn't have a VAX Unix machine to use?  Our primary
mainframe is an IBM 3090 running MVS/XA, but none of the IBM MVS
implementations has a domain name server.  I believe that the new
IBM TCP/IP for VM product has one, but we don't run VM.  A domain
name server that could run on a PC, either under DOS or some flavor
of Unix would be real handy for us.

I am sending this to 3 lists, sorry for duplicates that you may
receive.

Roger Fajman
BITNET:    RAF@NIHCU
Internet:  RAF%NIHCU.BITNET@WISCVM.WISC.EDU
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 87 15:51:14 GMT-0:00
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Subject:   Invalidating ARP Caches

I have only had one answer on how to invalidate arp caches in
hosts when i move my IP (proxy arp) subnet router, so here's my
thoughts...

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

Could call this NARP (not arp):

I am considering writing  a service that listens for IP broadcasts
(multicasts when available) and invalidates arp caches on basis
of these. When (before/after) a router moves, it will still
forward these packets so sitting on any host I can (hopefully
only with certain privilages) say:

arpinval {ip addr}*

which will broadcast some packet like

IP header with NARP type + <IP Addr Addr etc)

(has to be IP broadcast, not lower level or the IP subnet routers wont
forward it). When routers get clever, they could send this
packet for me.

Any reason not to do this, apart from the obvious possible
misuses and broadcast traffic (though only one broadcast to fix
a lot of hosts)?

jon
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1-Jun-87 23:11:40 EDT
From:      JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen")
To:        comp.protocols.tcp-ip
Subject:   Re:  TN3270


    	I inquired of a Network Solutions salesperson ... and
    	he said that their DDN/MVS did not support 3270-mode telnet.
    	
    There must have been some misunderstanding about the question or the
    answer.  DDN/MVS is based on the UCLA MVS code, which certainly does
    support 3270-mode Telnet, and always has....

    Bob Braden

This is what I get for answering my mail while far from my references.
I know that one of the mainframe packages doesn't have TN3270.  Is it
C.I.S.C.O. (not the Bay area gateway people) that doesn't?

jbvb

BTW: I'm still not on the list.  Has there been any further discussion of
the RFC issue?  Also, am I simply not aware of an official MIT redistribution
point?  If so, could someone inform me whom to contact?

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jun-87 00:56:13 EDT
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  IP datagram sizes

Jon,

THe X.25 model requires X.75 gateways to handle M-bit repacketizing between
two networks with different packet sizes. This requires route-binding between
the gateways, which runs completely contrary to the basic Internet architecure.
If we are to accept your suggestion we would have to drop this fundamental
cornerstone in the model. Is the increment in performance possibly achieved
by route-binding justify the loss in robustness and flexibility inherent in
the present model? I'm not looking for a debate, just refining the perspective.

Dave

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jun 87 10:22:03 EDT
From:      Ross Patterson <A024012%RUTVM1.BITNET@wiscvm.wisc.edu>
To:        Bob Braden <BRADEN@ISI.EDU>, JBVB@AI.AI.MIT.EDU, TCP-IP@SRI-NIC.ARPA
Subject:   Re:  TN3270
>
>
>    I inquired of a Network Solutions salesperson after one of their
>    presentations at the conference in Monterey this past March, and
>    he said that their DDN/MVS did not support 3270-mode telnet.
>
>There must have been some misunderstanding about the question or the
>answer.  DDN/MVS is based on the UCLA MVS code, which certainly does
>support 3270-mode Telnet, and always has.  I have a tn3270 icon on my
>Sun screen, which I occasionally open to log into TSO on the UCLA 3090
>and use PDF in full-screen.  Now that the ARPANET is back from the dead,
>it works quite snappily, too.
>
>Bob Braden
>

    Not to  question an authority in  the field (and an  author of the
code), but couldn't NSI have simply recompiled the modules affected by
the TN3270 support,  and thus turned it off?  UCLA  ships this support
in object code, not in source, and it is very nicely compartmentalized
to allow one  to turn it off.  In fact,  the installation manual warns
that recompiling these  modules will have exactly that  effect.  I can
see  where vendors  might  not want  to offer  code  that they  cannot
support, and might therefore excise it.

Ross Patterson
Rutgers University
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jun-87 10:54:11 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  TN3270

The Maryland CISCO, is a hardware implementation.  It is a box that
plugs into your MVS machine's channel and plugs into ethernet/DDN on
the other side.  While I've received glossy literature on these things
in the past, I've never heard of someone that had one.  Does anybody
have one of these things?

-Ron

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jun-87 11:37:54 EDT
From:      LYNCH@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  TN3270

Oh yeah, Bob,  you brought up a point that I have ignored lately:
the Arpanet is back from the dead lately.  Why?  Was something
wonderful discovered or done?  Or did some evil packet
sprayer die in silence?

Dan
-------

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1987 11:37:54 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        Bob Braden <braden@VENERA.ISI.EDU>
Cc:        JBVB@AI.AI.MIT.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU
Subject:   Re:  TN3270
Oh yeah, Bob,  you brought up a point that I have ignored lately:
the Arpanet is back from the dead lately.  Why?  Was something
wonderful discovered or done?  Or did some evil packet
sprayer die in silence?

Dan
-------
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jun 87 16:36:00 -0500
From:      Frederick E Serr BBNCC 19/415 x2474 <fserr@ALEXANDER.BBN.COM>
To:        Dan Lynch <LYNCH@A.ISI.EDU>
Cc:        Bob Braden <braden@VENERA.ISI.EDU>, tcp-ip@SRI-NIC.ARPA
Subject:   Re: TN3270
The ARPANET had severe performance problems last October, and again 
during late January and February.  In both cases we think the major
culprit was oversubscribed network trunks.  The network routing
algorithm started thrashing about, looking for less congested routes.
This sometimes led to less efficient use of the existing bandwidth,
compounding the performance problems. 

Last fall the problems were triggered by trunk rehomings that were 
done in the wrong order.  The most important "fix" was simply getting
all the rehomings done, restoring the bandwidth that had been there
before.  

The congestion in February was alleviated by adjustments to the 
parameters used in the network routing calculations.  We lessened the
ability of the network to route around congestion, but made it more
stable in the face of limited bandwidth on important routes.  Upgrading
several key nodes to a more powerful hardware version may have had a
small role in keeping performance at acceptable levels.  

Though things seem OK now, the network is still sensitive to increased
traffic on key paths.  (Transcontinental bandwidth seems to be the
critical resource here.) Sometime very soon (perhaps this week), a new
link will be added to the ARPANET between New England and northern
California.  This new cross-country trunk should improve performance
still further, and start to provide some room for expansion beyond
current traffic levels. 

Fred Serr
Network Analysis Department
BBN Communications
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jun-87 13:28:19 EDT
From:      jon@CS.UCL.AC.UK.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: IP datagram sizes

Dave,

 I agree X.75 cgoes contrary to internet philosophy. My
suggestion is that something between the current route binding
in X.25/X.75, and the fully dynamic routing of IP is required
plus some.

I think You need some kind of weak resource reservation scheme,
combined with some means for end to end protocols to find out what the
resources out there are, since pure feedback from the end to
end protocol will give you information too late to adjust mtu's,
rtx times etc, and will always give you unstable algorithms.

Jon

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jun-87 13:41:34 EDT
From:      braden@ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  TN3270

Nothing wonderful. Just good old BBN grunt work ("tuning") plus some
criminally-delayed line upgrades.

   Bob
   

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jun 87 09:54:45 +0100
From:      Jon Crowcroft <jon@Cs.Ucl.AC.UK>
To:        Mills@louie.udel.edu
Cc:        Jon Crowcroft <jon@Cs.Ucl.AC.UK>, tcp-ip@sri-nic.arpa, jon@Cs.Ucl.AC.UK
Subject:   Re: IP datagram sizes
Dave,

 I agree X.75 cgoes contrary to internet philosophy. My
suggestion is that something between the current route binding
in X.25/X.75, and the fully dynamic routing of IP is required
plus some.

I think You need some kind of weak resource reservation scheme,
combined with some means for end to end protocols to find out what the
resources out there are, since pure feedback from the end to
end protocol will give you information too late to adjust mtu's,
rtx times etc, and will always give you unstable algorithms.

Jon
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2-Jun-87 22:09:33 EDT
From:      fserr@ALEXANDER.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270

The ARPANET had severe performance problems last October, and again 
during late January and February.  In both cases we think the major
culprit was oversubscribed network trunks.  The network routing
algorithm started thrashing about, looking for less congested routes.
This sometimes led to less efficient use of the existing bandwidth,
compounding the performance problems. 

Last fall the problems were triggered by trunk rehomings that were 
done in the wrong order.  The most important "fix" was simply getting
all the rehomings done, restoring the bandwidth that had been there
before.  

The congestion in February was alleviated by adjustments to the 
parameters used in the network routing calculations.  We lessened the
ability of the network to route around congestion, but made it more
stable in the face of limited bandwidth on important routes.  Upgrading
several key nodes to a more powerful hardware version may have had a
small role in keeping performance at acceptable levels.  

Though things seem OK now, the network is still sensitive to increased
traffic on key paths.  (Transcontinental bandwidth seems to be the
critical resource here.) Sometime very soon (perhaps this week), a new
link will be added to the ARPANET between New England and northern
California.  This new cross-country trunk should improve performance
still further, and start to provide some room for expansion beyond
current traffic levels. 

Fred Serr
Network Analysis Department
BBN Communications

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 09:43:26 EDT
From:      YAKOV@IBM.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   tn3270


We (group of people at T.J. Watson Research Center, IBM Corp.)
are working on a draft proposal which will attempt to
standardize 3270 emulation over the Telnet.
Any ideas/comments/suggestions are welcomed.
Jacob Rekhter (yakov@ibm.com).

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 13:02:28 EDT
From:      narten@PURDUE.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TN3270

>Though things seem OK now, the network is still sensitive to increased
>traffic on key paths.  (Transcontinental bandwidth seems to be the
>critical resource here.) 

Has anyone ever looked into the way EGP traffic (and the "extra hop"
problem that goes with it) effects this? For instance, on the ARPANET,
there are only 3 EGP servers sites publicly available. They are
presumably located on the east coast (10.7.0.63
bnnet2-arpanet-gw.arpa), midwest (10.2.0.37 purdue-cs-gw.arpa), and on
the west coast (10.3.0.27 gateway.isi.edu).

Does anyone have any information on numbers and locations of sites
peering with each server?  Would it help to skew the peering so that
sites on the east peered with bbnnet2, and so on, even if it means
that the percentages of the total sites each server peers with is
unequal? 

In looking at routing tables gotten via EGP from purdue-cs-gw.arpa,
only a handful (less than 40 out of 240) of the routes actually go
through those gateways. The rest go to specific (and presumably
correct) gateways. Is this because everyone else peers with Purdue
(and hence its EGP updates have the correct info) or because the
"extra hop" problem really isn't a problem since ICMP redirects get
things straightened out?

Thomas

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 13:27:49 EDT
From:      jcollas@XN.LL.MIT.EDU (Juan Collas)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 draft proposal


Jacob,

About time, too.  I did the Fibronics KNET tn3270 over telnet server.  For
documentation on the protocols I relied on a few telnet option RFCs and
Greg Minshall's BSD TN3270 client telnet program.

The lack of a spec caused some minor problems that are probably still 
uncorrected (ie negotiating for EOR).

Have you thought about standardising for 3279s?  color over telnet could
be very nice.  (I hear the groans of disgust already ...)  How about dealing
with graphics over 3279s?  Differences in MVS vs VM SBAs?  (I think that's
a moot point, though).

I'm sure you've already had these ideas.  I'd be interested in getting a copy
of the proposal.

	-Juan Collas, MIT Lincoln Labs

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 17:02:04 EDT
From:      utkey@ORNL-MSR.ARPA (Ken Key)
To:        comp.protocols.tcp-ip
Subject:   Looking for an X.409 parser...


HI,
I'm working on a networking project and have a need for an X.409
parser.  I just need octet strings and integers.  Anything to
keep from reinventing the wheel.
Thanks,
Ken Key

utkey@ornl-msr.arpa
KEY@UTKVX1.BITNET

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 18:11:13 EDT
From:      MAB@CORNELLC.BITNET (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: IEN documents

>
>All the IEN's are on line and available via anonymous FTP from SRI-NIC.ARPA.

Not so.  I FTP'd IEN193 and got the following:

      This note is not available online.  Please request copies from
      the NIC via message to NIC@SRI-NIC.ARPA.

         IEN 193

         Title:    Timer-Based Mechanisms in Reliable Transport Protocol
         Connection Management

         Author:   Dick Watson

As I recall, the NIC said they would supply a printed copy for a nominal fee.

Mark

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jun 1987 18:11:13 EDT
From:      Mark Bodenstein <MAB%CORNELLC.BITNET@wiscvm.wisc.edu>
To:        Patrick Barron <pdb%sei.cmu.edu@crnlvax2.BITNET>
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re: IEN documents
>
>All the IEN's are on line and available via anonymous FTP from SRI-NIC.ARPA.

Not so.  I FTP'd IEN193 and got the following:

      This note is not available online.  Please request copies from
      the NIC via message to NIC@SRI-NIC.ARPA.

         IEN 193

         Title:    Timer-Based Mechanisms in Reliable Transport Protocol
         Connection Management

         Author:   Dick Watson

As I recall, the NIC said they would supply a printed copy for a nominal fee.

Mark
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 19:17:31 EDT
From:      steve@teletron.UUCP (Steve Tse)
To:        comp.protocols.misc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   StarLAN ?


Has anyone had experience with AT&T's StarLAN network?

I was wondering how good is the performance of this 1 Mb/s,
twisted pair, CSMA/CD network in terms of utilization, throughput,
latency, end to end delay and capacity.

Since the StarLAN using an inverted tree hierarchical star topology,
each message sent by a node has to propagate to the HHUB through all
the imtermediate levels and back to the node through the same route.
Will this cause tremendous of delay and lower the throughput of
the system ?

Hence IEEE 802.3 designation of type 1BASE5, 1 stands for 1 Mb/s and
BASE for baseband. What does 5 stand for? Does it stand for the
maximun node-to-node distance 0.5 km ?

I also would like to know how easy it is to get networking hardware
and software (especially for TCP/IP-based systems) and what it all
costs.

I would appreciate any information anyone has on this network.

Thanks,

Steve Tse

alberta!ncc!teletron!stolo/

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 87 17:07:55 GMT
From:      pioneer!lamaster@ames.arpa  (Hugh LaMaster)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: TCP/IP ETHERNET DECNET VAX
In article <2033@a.cs.okstate.edu> keith@a.cs.okstate.edu (Keith Lovelace) writes:
>Help!!!
>
>We here at OSU have just recently decided that we would purchase a VAX 8350 and
>run ULTRIX on it.  We currently are running a VAX 11/780 with VMS.  We would
>like to run DECNet to the two machines for file transferr, mail, etc. (our
>first attempt at DECNetting anything).  We would then like to run a TCP/IP
>link on the 8350 to do the terminal interface.  The first problem arises in
>the fact that there are very few DEC people who know anything about ULTRIX,
>much less TCP/IP.  This is also our first attempt at providing a campus wide
>UNIX (at least a derivative) system, and also our first attempt at TCP/IP
>networking.  In other words, we are stepping into unknown and previously
>untouched areas.  To get on with it, my questions may be simple to you but
>are still confusing to me.
>
>Problem one.  Can ULTRIX, or 4.2 BSD (since it is supposedly not changed by
>DEC) support both a DECNet link and a TCP/IP link at the same time without
>problems?
>

Here at Ames, we are running both TCP/IP and DECNET on an 11/780 using 
Ultrix.  There have been no problems that I am aware of.

>Problem two.  Does ULTRIX do very well talking to terminal servers such as
>the ANNEX UX on TCP/IP?
>

Yes, it works fine.  We have tested Ultrix with the Annex.  No problems.

>The reason for going to the TCP/IP connection for terminals is based on the
>fact that we don't want to lock ourselves into $'s of DEC hardware for

This is good reasoning in my opinion.

I have no experience with the 8350. Sorry.  We do have an 8650 running VMS, and
I have been impressed by its speed.


  Hugh LaMaster, m/s 233-9,  UUCP {seismo,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

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3-Jun-87 21:37:04 EDT
From:      swb@DEVVAX.TN.CORNELL.EDU (Scott Brim)
To:        comp.protocols.tcp-ip
Subject:   tn3270 draft proposal


   Date: Wed, 3 Jun 87 13:27:49 EDT
   From: jcollas@XN.LL.MIT.EDU (Juan Collas)

   Have you thought about standardising for 3279s?  color over telnet
   could be very nice. ....  How about dealing with graphics over
   3279s?

We have a real requirement for this and I think the RFC would be
incomplete without it.  I too look forward to it.
							Scott

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Jun-87 01:31:48 EDT
From:      robert@psych.psy.uq.oz (Robert Dal Santo)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Help Wanted - TCP/IP -> Sys V


	We are running System V.2 on a Perkin Elmer 3210. PE's port
of Sys V is called Xelos.

	We have just purchased a Micro Vax II and want to get the two talking
over an ethernet.

	PROBLEM.

	The PE doesnt talk TCP/IP, and we have sources for Xelos, but not
for Ultrix, so we want to get pseudo TCP/IP on the PE under Sys V (Xelos).
The easiest would be to get an intelligent TCP/IP ethernet board, but thats
unlikely. The other possibility is to 'graft' TCP/IP into our Sys V kernel.
This looks to be no minor task.

	Is there anyone out there who has grafted TCP/IP into a Sys V
kernel ? Even a partial graft, as we would be quite happy if we could just
copy files between the two machines, and we could build from there.

	Please respond by E-mail.

Thanks,

Robert Dal Santo		Phone:	+61 7 377 4285	(International)

Department of Psychology,	ACSnet:	robert@psych.psy.uq.oz
University of Queensland,	ARPA:	robert%psych.psy.uq.oz@seismo.css.gov
St Lucia, Brisbane, 4067	UUCP:	..!seismo!munnari!psych.psy.uq.oz!robert
AUSTRALIA.			JANET:	psych.psy.uq.oz!robert@ukc

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Jun 87 10:32:01 -0400
From:      Mike Brescia <brescia@CCV.BBN.COM>
To:        narten@PURDUE.EDU
Cc:        tcp-ip@SRI-NIC.ARPA, egp-people@CCV.BBN.COM
Subject:   EGP, extra hop, and peers (was: TN3270)
     >the network is still sensitive to increased traffic on key paths.
     Has anyone ever looked into the way EGP traffic (and the "extra hop"
     problem that goes with it) effects this?

There are two factors Tom asks about.  1) the EGP protocol routing overhead
2) the "extra hop problem"

For the first, yes, every gateway is pinging 2 or 3 egp core servers every 30
or 60 seconds, and polling for routing information every 2 (or more) minutes.
We recommended earlier that implementers lengthen the times to 60 seconds and
3 minutes.  This suggestion was sent out to 'egp-people' list on March 3 and
again on May 18.

For the extra hop problem, we have been recommending that EGP connections be
maintained with 2 of the 3 servers, so that for any net you try to reach will
be known directly to you because both parties are likely to be doing EGP with
the same core server, and the direct route to the other net will be advertized
to you in the EGP net-reachability (NR) message.  While your gateway is
not doing EGP with that other gateway, the information is relayed by the core,
and the user traffic is not expected to pass through the core gateway.

There is an extra hop problem when you are trying to reach a local (EGP
advertized) net on the MILNET (or if you are on the MILNET side, you are
trying to reach a local net attaced to the ARPANET).  This is more properly
described as a GGP extra hop problem, rather than an EGP one.


     Does anyone have any information on numbers and locations of sites
     peering with each server?

I am sending a snapshot of the routing to Tom Narten.  If you want a copy too,
send me a note.  It's about 4 pages.

     Would it help to skew the peering so that sites on the east peered with
     bbnnet2, and so on...

This only helps distribute the EGP protocol traffic.  We think we can handle
the 60 packets a minute.

     In looking at routing tables gotten via EGP from purdue-cs-gw.arpa,
     only a handful (less than 40 out of 240) of the routes actually go
     through those [core] gateways.

You should be able to get good (ARPANET) routes directly from the EGP.  ICMP
redirect will not help unless you are a host instead of (in addition to) a
gateway.

Mike

p.s.: Apologies to those on EGP-PEOPLE mailing list who get two copies.  The
distributed mail data base is not yet capable of doing
( TCP-IP | EGP-PEOPLE )    /* c syntax instead of sql :-*/
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Jun-87 10:46:14 EDT
From:      brescia@CCV.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   EGP, extra hop, and peers (was: TN3270)


     >the network is still sensitive to increased traffic on key paths.
     Has anyone ever looked into the way EGP traffic (and the "extra hop"
     problem that goes with it) effects this?

There are two factors Tom asks about.  1) the EGP protocol routing overhead
2) the "extra hop problem"

For the first, yes, every gateway is pinging 2 or 3 egp core servers every 30
or 60 seconds, and polling for routing information every 2 (or more) minutes.
We recommended earlier that implementers lengthen the times to 60 seconds and
3 minutes.  This suggestion was sent out to 'egp-people' list on March 3 and
again on May 18.

For the extra hop problem, we have been recommending that EGP connections be
maintained with 2 of the 3 servers, so that for any net you try to reach will
be known directly to you because both parties are likely to be doing EGP with
the same core server, and the direct route to the other net will be advertized
to you in the EGP net-reachability (NR) message.  While your gateway is
not doing EGP with that other gateway, the information is relayed by the core,
and the user traffic is not expected to pass through the core gateway.

There is an extra hop problem when you are trying to reach a local (EGP
advertized) net on the MILNET (or if you are on the MILNET side, you are
trying to reach a local net attaced to the ARPANET).  This is more properly
described as a GGP extra hop problem, rather than an EGP one.


     Does anyone have any information on numbers and locations of sites
     peering with each server?

I am sending a snapshot of the routing to Tom Narten.  If you want a copy too,
send me a note.  It's about 4 pages.

     Would it help to skew the peering so that sites on the east peered with
     bbnnet2, and so on...

This only helps distribute the EGP protocol traffic.  We think we can handle
the 60 packets a minute.

     In looking at routing tables gotten via EGP from purdue-cs-gw.arpa,
     only a handful (less than 40 out of 240) of the routes actually go
     through those [core] gateways.

You should be able to get good (ARPANET) routes directly from the EGP.  ICMP
redirect will not help unless you are a host instead of (in addition to) a
gateway.

Mike

p.s.: Apologies to those on EGP-PEOPLE mailing list who get two copies.  The
distributed mail data base is not yet capable of doing
( TCP-IP | EGP-PEOPLE )    /* c syntax instead of sql :-*/

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Jun 87 11:03:16 EDT
From:      jqj@gvax.cs.cornell.edu (J Q Johnson)
To:        arpa.tcp-ip
Subject:   Re: ARPAnet congestion (was TN3270)
One of the troubling things many of us learned last fall was that most of
the long distance Internet trunks are logical trunks leased from the various
phone companies without much regard to the physical path they take.  Has
any progress been made in determining the physical paths that the long distance
ARPAnet (and more importantly Milnet) links take?  Has progress been made in
insuring the survivability of Internet communications if a backhoe cuts
through a major AT&T fiber on the NY Thruway?
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Jun-87 12:29:22 EDT
From:      CMSMAINT@BROWNVM.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   tn3270 draft proposal: 3270 graphics

I think the best way to support graphics in tn3270 would be to use
3179 vector graphics instead of 3279 programmed symbols.  The 3179
data streams are much shorter, and are fairly easy to map to calls to
a graphics package such as QuickDraw on a Macintosh.  Also, the host
programs which support the 3179 can adapt to different screen sizes.
I've had some experience with this, having written a Macintosh 3270
emulation program which includes 3179 support.
                                                 Peter

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Jun 87 12:29:22 EDT
From:      Peter DiCamillo <CMSMAINT%BROWNVM.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   tn3270 draft proposal: 3270 graphics
I think the best way to support graphics in tn3270 would be to use
3179 vector graphics instead of 3279 programmed symbols.  The 3179
data streams are much shorter, and are fairly easy to map to calls to
a graphics package such as QuickDraw on a Macintosh.  Also, the host
programs which support the 3179 can adapt to different screen sizes.
I've had some experience with this, having written a Macintosh 3270
emulation program which includes 3179 support.
                                                 Peter
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4-Jun-87 17:43:01 EDT
From:      ntm1569@dsacg3.UUCP
To:        comp.protocols.tcp-ip
Subject:   MVS TCP-IP Implementations


We need to run TCP/IP over an ethernet LAN between superminis running
(essentially) 4.3BSD and IBM/compatible mainframes running MVS.
Currently evaluating Network Solutions' DDN/MVS and Simware's SIM3278.
Any comments, suggestions etc. regarding these products or alternatives
would be much appreciated. Particularly interested in performance;
we may end up using FTP to transfer some sizeable files on a regular
basis. Read this newsgroup religiously but if you'd rather mail send to
seismo!gould!dsacg1!jroth 
and if there are sufficient replies I will summarize.
-- 
Jeff Roth             {seismo!gould,cbatt!osu-eddie}!dsacg1!jroth 
Defense Logistics Agency Systems Automation Center | 614-238-9421
DSAC-TMP, P.O. Box 1605, Columbus, OH 43216        | Autovon 850-
All  views  expressed  are  mine,  not  necessarily anyone else's

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 03:21:52 EDT
From:      jaw@jpl-mil.jpl.nasa.GOV.UUCP
To:        comp.protocols.tcp-ip
Subject:   sendmail problem

I have been having trouble sending mail from our SUNs to several hosts
(timeout after HELLO) including sri-nic.arpa. Using Eric Fair's
sendmail.cf file (@sri-nic.arpa <netinfo>sendmail-internet-generic.txt)
fixed the problem. When I find out the difference from what we were
using, I will pass it on.


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

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 11:30:27 EDT
From:      mike@BRL.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  routing restrictions and routing consistencies.

Can anyone tell me (a) precisely what the changes to the "mail bridges"
are going to be, and (b) what the implementation timetable is?

I have heard a lot of speculation.  About 85% of the speculation
outlines configurations that are unacceptable to Army/AMC (which is
1/5th of the Army), and probably unacceptable to significant portions of
the other services.

Before I start shooting my mouth off in Washington, I need some hard
facts.  All help will be much appreciated.
	Best,
	 -Mike Muuss

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 11:45:00 EDT
From:      VTTTELTY@FINFUN.BITNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Netbioses and VT100-Telnet



A few weeks ago I sent the following request to PC-IP and TCP-IP
mailing lists:

>Where can I find the following products:
>
>1. Netbios on TCP/IP for IBM PC/AT and 3Com Ethernet controllers.
>
>2. VT100-Telnet (supporting function keys) for IBM PC/AT.
>
>3. Netbios on TCP/IP for VAX/VMS.
>

Here are the most interesting responses I got:


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

From:     <BEAME@MCMASTER>

Santtu,

       Beame & Whiteside Software Ltd. have a VT100/VT52 - Telnet program
that runs on IBM PC/XT/AT machines using a 3Com EtherLink board. This
emulator includes a fully definable keyboard (every letter, function key).
The emulator also uses hardware scrolling for fast no-snow output (EGA
support also).

        This program comes with TCP/IP but NOT NetBios. More information
can be obtained from me or :

Beame & Whiteside Software Ltd.
259 Fiddler's Green Road
Ancaster, Ontario
Canada L9G 1W9

        - Carl Beame

P.S: I wrote the program, so notice the bias.
---------------------------------------------------------------

From: minshall%opal.Berkeley.EDU@BERKELEY.EDU

Hi.  Your items 1 and 2 can probably be gotten from Ungermann-Bass.
Possibly from Excelan and 3COM also (though I don't know for sure).

Greg Minshall
---------------------------------------------------------------

From: CLYNN@G.BBN.COM

    I am not sure about documents for the specific implementations
that you mentioned, but RFC1001 and RFC1002 specify how to do NETBIOS
over TCP/IP networks.  They are available via anonymous FTP from
SRI-NIC.ARPA.
---------------------------------------------------------------

From:     Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>

You might try contacting Lantec, for all of your needs.

Their postal address is:

    Postboks 171 Olavsgt. 39B
    3601 Kongsberg
    NORWAY

    Phone is +47-3-73-6880

Dave
----------------------------------------------------------------

From: cmcl2!aecom.yu.edu!cucard!naftoli%harvard@husc6.BITNET

Excelan makes a netbios over TCP/IP which works ok.  We have
run the IBM PC network over it with no apprarent problems.
---
Robert N. Berlinger
Supervisor of Systems Support                           Compuserve: 73047,741
Albert Einstein College of Medicine                     Easylink:   62956067
UUCP: ...$philabs,cucard,pegasus,rocky2!aecom!naftoli  GEnie:      R.Berlinger
----------------------------------------------------------------

From: John Romkey <ROMKEY@XX.LCS.MIT.EDU>

Try getting in touch with FTP Software. (617) 868-4878. The address
is:
    FTP Software, Inc.
    PO Box 150
    Kendall Square Branch
    Boston, MA  02140
    USA

FTP will be releasing a NetBIOS on TCP this summer, and already has a VT100
telnet available.

I am associated with FTP, so I do have some interest in these matters...
                - john romkey
-------------------------------------------------------------------

From:         RITCV!ROCKSVAX!ROCKSANNE!SUNYBCS!CANISIUS!ITECH1!SIA
              @CS.ROCHESTER.EDU

A rather complete TCP/IP package for IBM PC/XT/AT's that includes
a VT100 Telnet is available from:

FTP Software, Inc.
P.O. BOX 150
Kendall Square Branch
Boston, MA 02142
(617) 864-1711

The stuff for the VAX running under VMS is available from:

The Wollongong Group, Inc.
1129 San Antonio Road
P.O. Box 51860
Palo Alto, CA 94303
(415)962-7100

Wollongong also has a TCP/IP for the PC.

Another source for these packages would be:

Network Research Corp.
2380 North Rose Avenue
Oxnard, CA 93030
(805)485-2700


********************************************************************************
Stewart I. Alpert @ Ingram Software, Inc.  Department of Technical Services
UUCP:        {ihnp4,sco,mwc,canisius}!itech1!sia
            {allegra,decvax,watmath}!sunybcs!canisius!itech1!sia
ARPA/CSNET: itech1!sia%canisius@csnet-relay.ARPA
AT&T:       1-716-874-1874 or 1-800-828-7250 or 1-800-464-8488 (in NYS)
USnail:     2128 Elmwood Avenue, Buffalo, NY 14215
------------------------------------------------------------------------



Santtu M{ki
Technical Research Centre of Finland
Telecommunications laboratory

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 13:50:56 EDT
From:      jaw@sesun.Jpl.Nasa.GOV (Joe Wieclawek)
To:        comp.protocols.tcp-ip
Subject:   sendmail problem


 >I have been having trouble sending mail from our SUNs to several hosts
 >(timeout after HELLO) including sri-nic.arpa. Using Eric Fair's
 >sendmail.cf file (@sri-nic.arpa <netinfo>sendmail-internet-generic.txt)
 >fixed the problem. When I find out the difference from what we were
 >using, I will pass it on.

I changed our old sendmail.cf to include "E=\r\n" in the M record:
Mether, P=[IPC], F=msDFMuCX, S=11, R=21, A=IPC $h, E=\r\n
and this makes it work.

Thanks to :
	scott@gateway.mitre.org
	dupuy@amsterdam.columbia.edu
	dplatt@teknowledge-vaxc.arpa

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

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 13:58:14 EDT
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   A fuzzy proposal

Folks,

This is a proposal for a modification to the data base used by the NIC and
other organizations which identifies hosts and gateways. The modification is
suggested by certain routing configurations that commonly occur in the NSFNET 
community and also elsewhere. These configurations involve cases where the
internal structure of an autonomous system is to be hidden from outside the
system for various good reasons.

The issues involved are best raised by an example involving a gateway/host
called the fuzzball and used in the NSFNET Backbone system, as well in other
systems. First a few words on fuzzballs and routing. In order to minimize
consumption of network numbers and local-net addresses, a peculiar addressing
model is enjoyed by the fuzzies. Each one is assigned a "home address,"
usually on the local Ether, which represents its entity title in ISOspeak.
This address is unique, so that unambiguous routes can always be computed.

When two fuzzies are spliced together by a serial line, each sends the other a
hello message with its home address in the IP source-address field. The other
one saves this address and uses it to update its local-entity routing tables
and network-entity routing tables (if both are on different networks). Thus,
fuzzies automatically build routing tables for not only the local routes, but
routes to adjacent networks. Additional data in the hello message is used to
construct routes to other than adjacent networks.

In order to reduce consumption of net numbers and local-net addresses, two
fuzzies connected as above do not need to know their address (if any) on the
adjacent network. This avoids the "null net" problem sometimes encountered
when two gateways belonging to different autonomous systems are connected by a
point-to-point line. Nevertheless, if necessary for other reasons, fuzzy
addresses can be assigned with appropriate handcrafted entries in the routing
data base (this is in fact done sometimes to create a "tunnel" where a host
physically connected to one network is assigned an address on some other
network). However, this defeats a very desirable self-configuration
characteristic and considerably complicates configuration control and
management.

Following is an example scenario involving UMICHNET (35) and MACOMNET
(192.5.8). The 35.1.1.1 fuzzy is connected to the 192.5.8.6 fuzzy by a serial
line. To the 35.1.1.1 fuzzy its end of the line appears an extension of net
192.5.8 while, to the 192.5.8.6 fuzzy its end of the line appears an extension
of net 35; however, neither fuzzy knows or cares about its specific address on
the other network (in fact no such address is used). However, each fuzzy
determines from the source address of received hello messages the specific net
number and updates its tables accordingly.

		     +---------------+		  ARPANET
		     |192.5.8.x	     |35.x.x.x	     |
+---------+	+----+----+	+----+----+	+----+----+
| net 35  |	|35.1.1.1 |	|192.5.8.6|	|192.5.8.1|
|  host   |	| umich1  |	|swamprat |	| macom1  |
+----+----+	+----+----+	+----+----+	+----+----+
     |		     |		     |		     |
=====O===============O====	=====O===============O=====
       net 35 Ether		     net 192.5.8 Ether

Although attractive in these aspects, the fuzzball scheme does create some
problems. For instance, it is not possible to determine an unambiguous return
route, since a fuzzy may not know its address on the previous network. Also,
it is not possible to produce an unambiguous interface list suitable for
recording in the NIC or similar data bases. In fact, it is not possible to
contact either the 35.1.1.1 or 192.5.8.6 fuzzies using addresses on their
respective adjacent nets, since such addresses do not exist.

Comes now a proposal to deal with this problem. Henceforth, gateways in this
embarrasing situation shall be assigned synthetic addresses in the form
<net>*, where * indicates unknown or unassigned. For example, the
fuzzies above would be recorded as

	GATEWAY : 35.1.1.1, 192.5.8.* : UMICH1
	GATEWAY : 192,5,8,6 35.*.*.* : SWAMPRAT .

It is possible in the case of subnets to indicate finer granularity by
replacing * fields with assigned numbers; however, the subnet mask can only be
inferred and then only if it corresponds to octet fields.

The above notation can also be used when two or more gateways are operated as
a single autonomous system and where the internal structure of that system is
to be hidden. For instance, assume the ARPANET gateway 192.5.8.1 above wishes
to hide the other two gateays. This could be done by

	GATEWAY : 10.0.0.111, 192.5.8.*, 35.*.*.* : MACOM1 .

The implication is that routing computations are to be done under the
assumption that MACOM1 has in fact direct interfaces to the nets listed and
that it will take responsibility for all traffic to those nets received at
10.0.0.111.

How might this proposal affect global routing schemes such as proposed for
the Dissimilar Gateway Protocol (DGP)? The DGP routing algorithm synthesizes
routes directly from interface lists in the form

			<gate> <net1> <net2> ... ,

where <gate> is a unique gateway identifier and <net1>, etc., are the
interface addresses assigned to it. The algorithm constructs a path between
desginated endpoint addresses <source> and <destination> in the form

   <source> <gate1> <net1> <gate2> <net2> ... <gaten> <destination> .

The particular algorithm used is a variant of the Dijkstra (SPF) algorithm
modified for a hierarchical data base, but this is not important for the
present discussion. However, note that the Dijkstra algorithm (and many other
ones similar to it) operate by extending paths from a given node to each of
several possible successor nodes. Say the algorithm is currently extending
paths from <gate1>, for example. It then adds to the path ending in <gate1>
new edges for each interface address, which according to the proposal above
could involve an incompletely specified address.

In some following step the incompletely specified node will be found. When
extending the path from that node the set of interface lists will be searched
for interface addresses on the same network and for each one found the
associated gateway will be added to the path. There are two cases:

1. The interface address on the next hop is completely specified. In this case
   a complete source route can be constructed in the usual way.

3. The interface address on the next hop is not completely specified. A source
   route must then be constructed to the previous-hop gateway, which then
   has the responsibility to determine the remainder of the route.

Your advice and comment on this proposal will be appreciated.

Dave

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 14:54:12 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  Help Wanted - TCP/IP -> Sys V

I thought PE was now selling TCP/IP as an option for both their
System V and older operating system.

-Ron

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 17:58:17 EDT
From:      minshall@OPAL.BERKELEY.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270

Jacob,
	Needless to say, a standard would be very welcome.  It should
be planned to be released as an RFC.

	Many people have asked about 3279, 3179, etc.  I think the point
is that the standard needs to address "3270 over telnet", where all of
the above are in the class "3270".  Peter is right that in general the 3179
G graphics are nice; but sometimes programmed symbols are nice.  The point
is we should allow "everything".

	I think the model (continues to be) how the IBM "PVM" (IBM's
telnet-style program for VM systems) does it.  I think that someone with
PVM devleopment experience (and thus an IBMer) would be very useful
in this endeavour.

	Anyway, I'm very interested in contributing to such a standard.

Greg

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5-Jun-87 21:21:34 EDT
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Netbioses and VT100-Telnet

A couple of notes on Santtu ?Miki?'s posting:

Excelan and Ungermann/Bass have TCP/IP NETBIOSs for the PC available now,
but neither conforms to the RFCs, and because of this, they don't
interoperate.  I have heard rumors that Excelan will upgrade theirs to
conform to the RFCs by early 4th quarter.  I have no idea what U/B
is up to, although I assume they're hard at work as well.  When FTP
Software's NETBIOS is available, it will conform to the RFCs.

I have seen postings that suggested that Excelan either had a VMS NETBIOS
(non-RFC-compatible), or was working on one (which could be planned for
compatibility).  I have no more facts, except that I am quite sure that
neither MICOM-Interlan, The Wollongong Group, Network Research Corp.,
nor SRI (all vendors of VMS packages, see the Vendors Guide) have any
NETBIOS support for VMS as of this date.

I know that Telnets with VT100 emulators for the PC are available from
Beame & Whiteside, Bridge, Excelan, FTP Software, The Wollongong Group
Sun, and U/B, either separately, or as part of a larger TCP/IP package
for the PC.  U/B and Excelan require the use of the manufacturer's Ethernet
board, and Bridge & TWG only support the 3Com dumb interface.  Last I
knew, NRC's package didn't have terminal emulation as such (their Telnet
relied on ANSI.SYS), but that could have changed recently.  FTP is the
only company that offers a VT100 Rlogin, but that doesn't cut much ice
against a VMS...

The only one I've worked with is the one I maintain (FTPs).  It does a
straight VT100, less smooth scroll, 132 column mode, and double height/
double width.  The release due out July 1 has no-snow CGA operation added.
All function keys are handled, and the keypad layout works fairly well
with EDT on VMS.  Last I knew, Excelan had roughly the same layout, but
I've never actually used it against a VMS.

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 87 21:07:05 GMT
From:      pioneer!lamaster@ames.arpa  (Hugh LaMaster)
To:        tcp-ip@sri-nic.arpa
Subject:   Re:  comp.protocols.iso
I note that there is now a newgroup for discussing iso protocols:

comp.protocols.iso





  Hugh LaMaster, m/s 233-9,  UUCP {seismo,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

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 87 17:45 O
From:      <VTTTELTY%FINFUN.BITNET@wiscvm.wisc.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Netbioses and VT100-Telnet


A few weeks ago I sent the following request to PC-IP and TCP-IP
mailing lists:

>Where can I find the following products:
>
>1. Netbios on TCP/IP for IBM PC/AT and 3Com Ethernet controllers.
>
>2. VT100-Telnet (supporting function keys) for IBM PC/AT.
>
>3. Netbios on TCP/IP for VAX/VMS.
>

Here are the most interesting responses I got:


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

From:     <BEAME@MCMASTER>

Santtu,

       Beame & Whiteside Software Ltd. have a VT100/VT52 - Telnet program
that runs on IBM PC/XT/AT machines using a 3Com EtherLink board. This
emulator includes a fully definable keyboard (every letter, function key).
The emulator also uses hardware scrolling for fast no-snow output (EGA
support also).

        This program comes with TCP/IP but NOT NetBios. More information
can be obtained from me or :

Beame & Whiteside Software Ltd.
259 Fiddler's Green Road
Ancaster, Ontario
Canada L9G 1W9

        - Carl Beame

P.S: I wrote the program, so notice the bias.
---------------------------------------------------------------

From: minshall%opal.Berkeley.EDU@BERKELEY.EDU

Hi.  Your items 1 and 2 can probably be gotten from Ungermann-Bass.
Possibly from Excelan and 3COM also (though I don't know for sure).

Greg Minshall
---------------------------------------------------------------

From: CLYNN@G.BBN.COM

    I am not sure about documents for the specific implementations
that you mentioned, but RFC1001 and RFC1002 specify how to do NETBIOS
over TCP/IP networks.  They are available via anonymous FTP from
SRI-NIC.ARPA.
---------------------------------------------------------------

From:     Dave Crocker <dcrocker%engr.ub.com@RELAY.CS.NET>

You might try contacting Lantec, for all of your needs.

Their postal address is:

    Postboks 171 Olavsgt. 39B
    3601 Kongsberg
    NORWAY

    Phone is +47-3-73-6880

Dave
----------------------------------------------------------------

From: cmcl2!aecom.yu.edu!cucard!naftoli%harvard@husc6.BITNET

Excelan makes a netbios over TCP/IP which works ok.  We have
run the IBM PC network over it with no apprarent problems.
---
Robert N. Berlinger
Supervisor of Systems Support                           Compuserve: 73047,741
Albert Einstein College of Medicine                     Easylink:   62956067
UUCP: ...$philabs,cucard,pegasus,rocky2!aecom!naftoli  GEnie:      R.Berlinger
----------------------------------------------------------------

From: John Romkey <ROMKEY@XX.LCS.MIT.EDU>

Try getting in touch with FTP Software. (617) 868-4878. The address
is:
    FTP Software, Inc.
    PO Box 150
    Kendall Square Branch
    Boston, MA  02140
    USA

FTP will be releasing a NetBIOS on TCP this summer, and already has a VT100
telnet available.

I am associated with FTP, so I do have some interest in these matters...
                - john romkey
-------------------------------------------------------------------

From:         RITCV!ROCKSVAX!ROCKSANNE!SUNYBCS!CANISIUS!ITECH1!SIA
              @CS.ROCHESTER.EDU

A rather complete TCP/IP package for IBM PC/XT/AT's that includes
a VT100 Telnet is available from:

FTP Software, Inc.
P.O. BOX 150
Kendall Square Branch
Boston, MA 02142
(617) 864-1711

The stuff for the VAX running under VMS is available from:

The Wollongong Group, Inc.
1129 San Antonio Road
P.O. Box 51860
Palo Alto, CA 94303
(415)962-7100

Wollongong also has a TCP/IP for the PC.

Another source for these packages would be:

Network Research Corp.
2380 North Rose Avenue
Oxnard, CA 93030
(805)485-2700


********************************************************************************
Stewart I. Alpert @ Ingram Software, Inc.  Department of Technical Services
UUCP:        {ihnp4,sco,mwc,canisius}!itech1!sia
            {allegra,decvax,watmath}!sunybcs!canisius!itech1!sia
ARPA/CSNET: itech1!sia%canisius@csnet-relay.ARPA
AT&T:       1-716-874-1874 or 1-800-828-7250 or 1-800-464-8488 (in NYS)
USnail:     2128 Elmwood Avenue, Buffalo, NY 14215
------------------------------------------------------------------------



Santtu M{ki
Technical Research Centre of Finland
Telecommunications laboratory
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Sat, 06 Jun 87 11:41 PDT
From:      Michael Stein                               <CSYSMAS@UCLA-CCN.ARPA>
To:        tcp-ip@sri-nic.arpa
Subject:   Re: tn3270 model
>        I think the model (continues to be) how the IBM "PVM" (IBM's
> telnet-style program for VM systems) does it.  I think that someone with
> PVM devleopment experience (and thus an IBMer) would be very useful
> in this endeavour.

I think that this is the wrong model.  A better model is IBM/VTAM.

This does NOT require VTAM experience, VTAM transmits 3270 data
streams transparently.  (Once you get to transparent mode there
is nothing to do!)

The 3270 data stream has it's own internal "terminal type" query
support, why not just use it.  It would be simple to require all
network "3270"s to support query even if the query response is
just a pre-canned "dumb" response.

Note that at least some tn3270 type programs will have to
support query anyway for graphics or other special features.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Jun-87 10:08:48 EDT
From:      hwb@MCR.UMICH.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   Re:  A fuzzy proposal

Dave:

Why don't you leave the *'s out, as they seem redundant. All you are asking
for is to leave host parts out to allow for net and subnet connections.
It's obvious without marking explicit *'s. In fact, may be addresses not
fully qualified (like 192.5.8) should be followed by a bit mask, to allow
for subnets. E.g.:

 GATEWAY : 35.1.1.4, (35.128 : 255.128.0.0) : MERIT-DIRECT
 GATEWAY : 35.1.1.4, (35.1.128 : 255.255.224.0) : CITI

Another possibility would be to use zeroes instead:

 GATEWAY : 35.1.1.4, (35.128.0.0 : 255.128.0.0) : MERIT-DIRECT
 GATEWAY : 35.1.1.4, (35.1.128.0 : 255.255.224.0) : CITI

Note that the Merit packet switching nodes allow for the same addressing
flexibility Fuzzballs do. However due to some of the limitations you outlined
we will soon be able to "let devices know (additionally) what address they
should use." This is important for, e.g., ARPs if you have more then one
Ethernet interface.

	-- Hans-Werner

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Jun-87 11:51:53 EDT
From:      Mills@UDEL.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  A fuzzy proposal

HW,

Well, I like the idea of including bitmasks to indicate address ranges, but
I thought that a bit radical to propose at this time. In fact, I have a whole
bunch of really radical things to propose, all in good time. Meanwhile, I
suggest using zeros instead of * might break something somewhere, like
(old) local-net brodcasts.

Dave

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Jun-87 14:41:00 EDT
From:      CSYSMAS@OAC.UCLA.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 model

>        I think the model (continues to be) how the IBM "PVM" (IBM's
> telnet-style program for VM systems) does it.  I think that someone with
> PVM devleopment experience (and thus an IBMer) would be very useful
> in this endeavour.

I think that this is the wrong model.  A better model is IBM/VTAM.

This does NOT require VTAM experience, VTAM transmits 3270 data
streams transparently.  (Once you get to transparent mode there
is nothing to do!)

The 3270 data stream has it's own internal "terminal type" query
support, why not just use it.  It would be simple to require all
network "3270"s to support query even if the query response is
just a pre-canned "dumb" response.

Note that at least some tn3270 type programs will have to
support query anyway for graphics or other special features.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6-Jun-87 21:36:00 EDT
From:      WANCHO@SIMTEL20.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Strange problems with VAX/VMS DDN X.25 hosts

Karl Goodloe's machine is a VAX 11/750 running 4.2bsd with some Mt.
Xinu fixes from a couple years back.  The problem he describes below
seems to happen only when VAX/VMS systems running Wollongong TCP/IP
over a DDN X.25 connection attempt to send mail over a certain size to
his host.  If this situation looks familiar to anyone, or you might
have some clue as to what's happening, please contact Karl directly
and copy me in your message.

Here are the details from Karl:

Date: Wednesday, 3 June 1987  10:11-MDT
From: kgoodloe at miser.ARPA (Karl G. Goodloe)
To:   fwancho
Re:   Mail Problem

We really haven't installed any software updates on MISER.  We have
done a lot of work on the sendmail.cf file to accomodate the change in
the host table.  None of the ones that you gave us [Eric Fair's
versions of the sendmail.cf files on SRI-NIC.ARPA] were compatible
with the way that we have set up to exchange mail with our INTEL-310
systems.  We use uucp; however, some changes were made in the normal
way that uucp hosts are taken care of in the configuration file.  When
the problem to appeared, I changed back to the old sendmail.cf just to
make sure that the changes weren't causing the problem.

The problem occurs when we receive mail from a VAX/VMS host.  A
sendmail process is created for the message, and the corresponding
dfAA<PID> file is created.  No corresponding qfAA<PID> file is ever
created, so it is a bit difficult to know where the message is coming
from and more difficult to tell who it was supposed to be addressed
to.  We have always been able to find the addressee from the context
of the message in the df* file, and eventually the host name shows up
in the xfAA<PID> file where some hand shaking between the two machines
is recorded.  Nothing is ever entered into the syslog file.

The worst of the problem is that the df* file just receives about the
first five lines of the message, with the next line repeated millions
of times until the file system is full.  As if this wasn't bad enough,
a few minutes later it will start up another process for the same
message, with a new sendmail process and a new giant dfAA<PID> file.
The file grows at about 100K/minute, so things get pretty bad in a
hurry.  Even if you see what is happening before the file system fills
and other mail is rejected, twenty minutes later the VAX wakes up and
sends it again.  [Perhaps it is fortunate that Karl's machine is
connected to a slow 9.6Kbps line or that growth rate would be even
more dramatic!]

This has gone on for days when it starts on a week-end.  I presently
have a shell script that watches for this to happen, and when the file
gets larger than 100K, the process is killed and the files deleted.

For the moment, I am considering it to be a problem with the new
installations.  They all seem to be VAX/VMS hosts running Wollongong
software and connecting to DDN with X.25 protocol.  Since one of these
is Nuclear Effects [a local host, NEL.ARPA, in Karl's organization],
we have someone nearby with considerable interest in solving the
problem.

Very short messages are not a problem, but they have to be less than
1000 bytes.  The people at Nuclear Effects have also discovered that
they can not FTP large files from NEL.ARPA to MISER.ARPA.  The other
way works fine.  They assume that this is just another manifestation
of the same problem, but this doesn't cause any trouble for MISER when
they try.  It seems to just sit there and do nothing until the job is
killed.  The other two hosts that we have had trouble with are
AFOTEC.ARPA (26.1.0.87) and DPG-MT.ARPA (26.8.0.120).

   If you have any ideas, both I and Dave Watson (dwatson@MISER.ARPA),
the NEL.ARPA system administrator, would be glad to hear from you.

Karl

PS: Overnight we had a similar problem caused by a message from
AMC-4.ARPA, which is apparently a PYRAMID-90X running UNIX.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8-Jun-87 00:28:15 EDT
From:      hedrick@TOPAZ.RUTGERS.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Strange problems with VAX/VMS DDN X.25 hosts

The 4.2 version of sendmail has some places where it should check for
the connection being closed and does not.  This can put it into
infinite loops.  We have also seen the situation where it writes a
file while into this loop.  As far as I know, the 4.3 version of
sendmail does not have this problem.  It is available from Berkeley by
anonymous ftp, because it is part of the MX update.  It will work
under 4.2.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 06:44:51 EDT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Automatic IP address assignment

Does anyone have any experience with either on-the-fly IP
address assignment or automated IP host installation?
Since we started shipping PC-NFS, several people have
expressed concern about using PCs as IP nodes and have asked if there
was any standard way of automating IP address assignment,
either per-session or once-only at first connection. Now
I know that there's nothing in the RFCs, but I seem to remember
some talk at the December '85 PC/IP - MAC/IP Workshop at the
Univ. of Maryland. Can anyone help jog my memory?

-- 
"You want a disclaimer form? Next window, please..."

Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!garnold  ARPA: garnold@sun.com

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 06:49:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A fuzzy proposal

I'm with Dave on zeroes - the syntax should be explicit about intended
"don't cares" as in logic design (0, 1, X).

Vint

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 12:17:09 EDT
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment


	I have been working on and off on a protocol to assign IP
addresses on the fly. The idea being based on a combination of ARP and
an RARP mechanism.  I am putting together a document that I will
submit as an RFC after I have done some coding and made sure it is a
"sane" approach.

	It is a "configurationless" protocol. Ie. you don't preassign
an IP address to some Ethernet address in advance of first use.
Instead the first time a new machine (actually new ethernet address)
shows up on the network it is assigned a semi-permanent IP address WHICH
IT HAS TO DEFEND by responding to ARPS for its address.  The biggest
problem with using it on PCs is that (at least with PC/IP) when a PC
isn't using a network application, it is deaf to the network. Is this
still true with PC-NFS, or is the network software always active?
Ifso then this protocol might work for you.

	I actually have a draft of this document but have been
hesitant to give it much distribution until I test it. However if
there is sufficient interest I can make it available (provided people
respect its draft status).

			-Jeff

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1987 16:21-PDT
From:      Steve Deering <deering@pescadero.stanford.edu>
To:        Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re: Automatic IP address assignment
The other problem with "defended addresses", besides the issue of PCs
not always running their networking software, is that the owner of an
address may not hear a challenge if the network is partitioned.
A local-area network can be partitioned by failure of a MAC-level bridge,
temporary disconnection of a host-to-network cable, etc.

Steve Deering
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 14:48:34 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Automatic IP address assignment

Geoff,

See RFC-891, which among other things describes the scheme used by the
so-called fuzzballs. The idea is that a newcomer squawks his IP address
in a hello packet and then the local-net routing algorithm bumps and
grinds to match. The scheme allows virtual hosts to pop up anywhere
touched by the algorithm, even if a different network. The scheme is
used for many permanently attached hosts, as well as dial-up hosts.

Dave

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 14:54:00 EDT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

This sounds like the IP equivalent of NETBIOS which suffers from the
need for the acquirer of a (name) (IP address) to DEFEND it whenever
someone else tries to take that (name) (address).

Maybe an improvement would be to have a server which does the
assignment? A bit like a name server...

Vint

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 17:30:39 EDT
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment


	My approach is hybrid. The idea is that one host (in our
environment the gateway that connects the Ethernet to the rest of the
world) would maintain a RARP table. A booting machine will transmit an
Ethernet level broadcast requesting information about the
configuration of the Ethernet. This information serving host would
respond immediately with necessary info (network number, subnet mask,
range of assignable addresses etc.) and iff it has a RARP entry, the
IP address to use. Other hosts would respond after a random delay, but
without the IP address to use (in the event the information server is
down).

	If this doesn't get it an address to use, it chooses one in
the allowed range based on some hashing (algorithm yet to be designed)
function. The information server would then note this address (which
it would learn from ARPs) and remember it. However because the
information server might fail, it is necessary that before attempting
to use an IP address, that you ARP to see if it is in use, and yes you
must respond to ARPs in order to DEFEND your address (sigh...).

	The design goal is for a reliable (no single point of
failure), maintenance free system which tends to keep a given IP
address with a given host, but doesn't guarantee this. Ie. the rate at
which a given machine gets assigned a different address is minimized
(so if it was registering its address with a nameserver, the update
traffic would be reduced).

			-Jeff

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 18:16:57 EDT
From:      jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment.

I have placed a *DRAFT* copy of this document in /pub/dyn.doc
on BITSY.MIT.EDU (18.72.0.3) feel free to pick up a copy.

			-Jeff

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9-Jun-87 19:21:00 EDT
From:      deering@PESCADERO.STANFORD.EDU (Steve Deering)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

The other problem with "defended addresses", besides the issue of PCs
not always running their networking software, is that the owner of an
address may not hear a challenge if the network is partitioned.
A local-area network can be partitioned by failure of a MAC-level bridge,
temporary disconnection of a host-to-network cable, etc.

Steve Deering

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jun-87 05:19:52 EDT
From:      csg@pyramid.UUCP
To:        news.groups,comp.protocols.misc,comp.dcom.lans,comp.mail.misc,comp.protocols.tcp-ip
Subject:   Newgroup Proposal: comp.protocols.iso

The group comp.protocols.iso seems to be trickling around the net. There have
been running discussions on ISO in at least three groups (comp.protocols.misc,
comp.mail.misc, comp.dcom.lans). Generally the contributions have been of very
high quality. Seems like about time to make comp.protocols.iso a formal group.

The charter would be:

	comp.protocols.iso  Discussion of ISO, MAP, TOP, and CCITT protocols

This would include the whole stack: X.25, X.213, X.214, X.215, X.400, and all
the appropriate ISO and MAP permutations. Discussions on DARPA/ISO gateways
could be cross-posted to comp.protocols.tcp-ip. I suspect that the group would
be especially interesting to European sites. I see no reason to make the group
moderated. 

Send comments to me, both pro and con. I am not interested in "votes" per se,
since they are not very meaningful. I want to know what people are thinking:
why or why not this should become a regular "comp" group, and whether or not
it would be helpful to you in your work. I'll summarize on the net and to the
backbone site admins.

<csg>

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jun-87 09:50:50 EDT
From:      woody@MACOM3.ARPA (robert a woodburn)
To:        comp.protocols.tcp-ip
Subject:   FUWO (For Unix Wizards Only)...

We're working on an experimental protocol and in the course
of prototype development, decided we needed to add a few 
protocol numbers to the kernel configurations to do our work.

The strange part is that we had already successfully added one
protocol previously.  Trying to add just one more seems to break
our kernel.  The kernel works, but is flaky with the following symptoms:

>[woody@macom3|/usr/macserver/woody]<*> uptime
>  9:28am  up 6369 days, 12:14,  1 user,  load average: 0.00, 7168355.43, 7156480.00
>[woody@macom3|/usr/macserver/woody]<*> ps
>  PID TT STAT  TIME COMMAND
>ps: error reading proc table from /dev/kmem
>[woody@macom3|/usr/macserver/woody]<*> ps -uax
>ps: error reading text table from /dev/kmem
>[woody@macom3|/usr/macserver/woody]<*> 

So as you can see the process table seems corrupt, or at least
applications trying to access kernel memory are confused for
some reason.  The following lines were added to "/usr/sys/netinet/in.h"

#define       IPPROTO_DGP             9               /* dgp */
#define       IPPROTO_DGP1            8               /* dgp */

(Yes, I know, 8 is the number for EGP, but we're not running EGP, 
 so its ok)

and these lines were added to "/usr/sys/netinet/in_proto.c" to the
inetsw structure:

{ SOCK_RAW,   PF_INET,        IPPROTO_DGP,    PR_ATOMIC|PR_ADDR,
  rip_input,  rip_output,     0,              0,
  raw_usrreq,
  0,          0,              0,              0,
},
{ SOCK_RAW,   PF_INET,        IPPROTO_DGP1,   PR_ATOMIC|PR_ADDR,
  rip_input,  rip_output,     0,              0,
  raw_usrreq,
  0,          0,              0,              0,
},

Now, just adding one record is fine, but adding two causes the minor
brain damage described above.  We only have a total of ten protocols
in use total.  After making these changes, all that I do is run
/etc/config, and then make the kernel, and thats it, and it doesn't work.
If anyone out there has had this problem and found a solution, or even
if you haven't found a solutions, please send me mail.

				THANKS!!!!	
						wood  y

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jun-87 14:34:40 EDT
From:      woody@MACOM3.ARPA (robert a woodburn)
To:        comp.protocols.tcp-ip
Subject:   FUWO solution


Thanks to Jim Berets whose suggestion led me to the
solution to my kernel troubles.

					wood y

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 87 16:13:19 EDT
From:      robert a woodburn <woody@MACOM3>
To:        tcp-ip@sri-nic.ARPA
Subject:   FUWO, the real story....
It turns out that, as do many UNIX problems, that my kernel "bug" had
nothing whatsoever to do with compiling or configuring the kernel.  I
did everything right, I just hadn't put the executable in the appropriate
place.  Our configuration at M/A-COM consists of a server and three
clients.  The three diskless clients boot via tftpboot which loads them
up with vmunix.  However, they do NOT boot up with the vmunix located in
the root partition, but rather are configured to boot from a common file
in the public partition (I still haven't found where that is configured, 
but anyway...)  I had done the following on the client I was testing the
kernel on:
  mv /vmunix /vmunix.old
which is just a pointer to the common file in /pub

Now, I copied in the new kernel to /vmunix and rebooted.

What I didn't know is that the client was still booting from /pub/vmunix
since the boot process ignores the clients actual copy of vmunix.

Anyway, to make a long story short, anytime I needed to look at the
vmunix executable (ps, uptime, etc) I was using the offsets specified
in the new kernel, but was still running the old.  It just wasn't real
obvious, since I didn't setup the server and client configuration to
begin with.  Now, before I get the hook for being long winded about a
subject that has absolutely nil to do with tcp-ip...  g'day...

			Thanks again to those who quickly jumped
			to my aid.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jun-87 16:19:39 EDT
From:      woody@MACOM3.ARPA (robert a woodburn)
To:        comp.protocols.tcp-ip
Subject:   FUWO, the real story...

It turns out that, as do many UNIX problems, that my kernel "bug" had
nothing whatsoever to do with compiling or configuring the kernel.  I
did everything right, I just hadn't put the executable in the appropriate
place.  Our configuration at M/A-COM consists of a server and three
clients.  The three diskless clients boot via tftpboot which loads them
up with vmunix.  However, they do NOT boot up with the vmunix located in
the root partition, but rather are configured to boot from a common file
in the public partition (I still haven't found what file sets that
configuration, but anyway...)  I had done the following on the client I was 
testing the kernel on:
  mv /vmunix /vmunix.old
which is just a pointer to the common file in /pub

Now, I copied in the new kernel to /vmunix and rebooted.

What I didn't know is that the client was still booting from /pub/vmunix
since the boot process ignores the clients actual copy of vmunix.

Anyway, to make a long story short, anytime I needed to look at the
vmunix executable (ps, uptime, etc) I was using the offsets specified
in the new kernel, but was still running the old.  It just wasn't real
obvious, since I didn't setup the server and client configuration to
begin with.  Now, before I get the hook for being long winded about a
subject that has absolutely nil to do with tcp-ip...  g'day...

                        Thanks again to those who quickly jumped
                        to my aid.

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jun-87 17:56:33 EDT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

We've had a great deal of success using Bill Croft's BOOTP (RFC 951).  As
currently implemented, a network node's IP address is permanently assigned to
a particular ethernet address and put in a configuration file read by the
bootp server.  Address assignment is done once when the machine is booted,
via a UDP broadcast.  We've extended the protocol to also announce the subnet
mask and default gateway along with a number of server addresses.  There is
really no reason why the BOOTP server could not be extended to dynamically
create new addresses for unknown ethernet addresses.  A scheme similiar to
Jeff's could be used to defend them afterwards, or the server could try to
maintain some sort of database.

Dynamic address assignment is also done for Macintoshes.  I'm not quite sure
how it works (I'm sure someone else can fill in the details), but the
Kinetics gateways are given a range of addresses which they dynamically
assign to new Appletalk nodes.  I think it uses NBP to request an address and
later defend it.

Drew

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10-Jun-87 22:37:31 EDT
From:      geoff@eagle_snax.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment (long)


Thank you to all to replied on this subject. Most copied their 
comments to "tcp-ip@SRI-NIC.ARPA"; let me quote a couple,
for selfish reasons (see below):

>From: Jeffrey I. Schiller <decvax!ucbvax!BITSY.MIT.EDU!jis>
>
>        I have been working on and off on a protocol to assign IP
>addresses on the fly. The idea being based on a combination of ARP and
>an RARP mechanism.  I am putting together a document that I will
>submit as an RFC after I have done some coding and made sure it is a
>"sane" approach.
>
 [...I'll let Jeff speak for himself...]
>
>I have placed a *DRAFT* copy of this document in /pub/dyn.doc
>on BITSY.MIT.EDU (18.72.0.3) feel free to pick up a copy.
>
>                        -Jeff
 -----------------------------------------------------------------------
>
>From: Raman Khanna <decvax!ucbvax!argus.stanford.edu!khanna>
>
>We were using RARP for this purpose - RARP server had a static ethernet
>address to IP address translation table and PCs were assigned IP address
>on connection.  Problem with RARP was that it did not propagate through
>our routers and, therefore, we had to use a RARP server per subnet.
>
>Recently we made a switch to Bootp that overcomes the problem stated
>above.
>
>raman khanna
>Stanford
 -----------------------------------------------------------------------
>From: decvax!ucbvax!UDEL.EDU!Mills
>
>Geoff,
>
>See RFC-891, which among other things describes the scheme used by the
>so-called fuzzballs. The idea is that a newcomer squawks his IP address
>in a hello packet and then the local-net routing algorithm bumps and
>grinds to match. The scheme allows virtual hosts to pop up anywhere
>touched by the algorithm, even if a different network. The scheme is
>used for many permanently attached hosts, as well as dial-up hosts.
>
>Dave
 -----------------------------------------------------------------------
>From: decvax!ucbvax!A.ISI.EDU!CERF
>
>This sounds like the IP equivalent of NETBIOS which suffers from the
>need for the acquirer of a (name) (IP address) to DEFEND it whenever
>someone else tries to take that (name) (address).
>
>Maybe an improvement would be to have a server which does the
>assignment? A bit like a name server...
>
>Vint
>

All of which suggests that the problem of on-the-fly IP address
assignment is in good hands. However, the once-only case didn't
get addressed, and I guess that's where my primary focus lies.

Most of those who replied were clearly concerned with sharing a
limited set of IP addresses among a large but transient population of
clients. This is clearly a major problem, particularly in Universities,
and I don't want to belittle the problem or the proposed solutions.

In contrast, I had been focussing on an ease-of-use question: how
best to help a network-naive user "plug'n'play" a system into a
network in which it will operate for some time. For good ergonomic
reasons it makes sense to focus on making the initial contact with a
system simple and relatively foolproof. If I can get this one right,
I am prepared to accept the overhead of human involvement in
resolving some types of situations which typically occur further up
the user's learning curve:  for example, changing the Ethernet
controller (and thus the Ethernet address) of a system, or changing
its name.  (For anyone who wonders about the extent of this passion
for ease-of-use, come over to Sun ECD and I'll show you the "pizza
movie".)

Although at first sight this problem may seem to be solvable using
the "resource-sharing" techniques described by others, I think there's
a fairly major difference.  I believe that for many users the most
important attribute of the system the work with is consistency; once
a system has been installed they want it to work forever(!). The idea
that one day they power it up and it reports that it can't join the
network because all addresses are in use is alien - a network address
is like a phone number, right?  [If IP addresses had no user
visibility this would be less painful, but.... well, just take a look
at the last line of Jeff's mail above.] Since I'm mainly concerned
with automating the process of making a (relatively) permanent
name-address binding rather than something more transient, many
issues (such as "address defense") are irrelevant.


Let me now describe the kind of model I was thinking of:

(1)        The (client) system RARP's as usual. This is a new node, nobody
        knows about it, so nobody replies.

(2)        The client broadcasts an IARP (Initial Address Resolution Protocol)
        request including its Ethernet address, a suggested hostname and
        a descriptive string (see below).
(3)        If there is an IARP server on the net, it can return any of the
        following responses:

        OK        - This is the first time the node has been connected
                to the net. An Internet address is assigned, the name is
                registered, and the Ethernet-IP address mapping is
                stored for RARP purposes. The client should start over
                by RARPing for its IP address, etc.

        OK-MOVED- the client's Ethernet address was already recorded in
                the RARP tables with an IP address which mapped to the
                required hostname, but the IP address corresponded to
                another network (or subnet). The system assumes that the
                client has been physically moved and connected to a
                new net. The IARP server assigns a new IP address,
                deassigns the old one, and updates all the maps.

        DUPNAME        - the hostname was in use, and there's either no Ethernet
                address associated with the corresponding IP address OR
                the Ethernet address is different from that of the client.

        BADNAME        - the client's Ethernet address was recorded in the RARP
                tables, but the IP address was not on this network AND the
                hostname was wrong. (Assumption: this node has already been
                configured under a different name.)

        NOADDR        - the server was unable to assign an address; a message
                may be provided to further explain the failure (e.g. site
                policy, no addresses available)

(3)        Subsequently the client RARPs, and can then use an inverse name
        lookup to verify that it is who it thinks it is...

(Note that this requires a fix to most versions of RARP, which will
happily return an Internet address even if the network number does not
correspond to the network from which the request originated. I have
seen people's hair go gray overnight with this one.....)

The idea of passing over a string of descriptive information about the
client is that it may help an IARP server in setting up the environment
for the client. For example, if the string read "SUN 3/50 DISKLESS"
a suitable IARP server might construct the necessary network boot
files before replying. This is a slippery slope: imagine having
IARP servers from several competing vendors each of which knows how to
(and is prepared to) set up only its "family" clients.....

There are three obvious problem areas. First, and probably the least
serious, is one of implementation: for Unix we're probably looking at
one more chunk to hack into the kernel, since we're not using IP at
this point. (Raw sockets tend to have rather undesirable performance
side-effects unless some low-level filtering can be specified.)
Second, the IARP server may need some significant amount of time to
set up the environment before it can send an OK or OK-MOVED; to avoid
client time-outs the server may need to send some kind of keepalive
(e.g. a WORKING packet) to prevent the client from giving up. Thirdly
we must address the problem of how we cope with multiple IARP servers
on a single Ethernet. (Just another implementation detail.:-)


Finally I should emphasize that all of this represents my personal
thoughts on how we can get the guru out of the loop for the average
user of these systems, and doesn't reflect the policies, plans or
products of Sun Microsystems Inc.


-- 
"You want a disclaimer form? Next window, please..."

Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!garnold  ARPA: garnold@sun.com

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 87 11:22:00 PST
From:      <art@acc.arpa>
To:        "tcp-ip" <tcp-ip@sri-nic.arpa>
Subject:   Looking for book

I'm trying to obtain a copy of "Data Networks" by Bertsekas and Gallager.
This is a brand new text and none of my local bookstores seem to have
it in stock or on order.  I'd prefer not to wait the 5-6 weeks a special
order would take.

If anyone happens to know of a bookstore that has it (and will take a
charge card purchase over the phone) I'd appreciate getting their phone
number.

I seem to remember hearing about a computer oriented bookstore in the
Silicon Valley area that was highly recommended.  Anyone have their
number?

					Art@acc.arpa

------
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 11:52:48 EDT
From:      robert@SPAM.ISTC.SRI.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Problems with TCP/IP sockets under 4.2.


    I have encountered a problem with TCP sockets under Sun 3.2 OS, and I was
    wondering if anyone on the list has encountered the same problem, or if 
    anyone knows what could be causing the problem.

    I have an application which listens on TCP sockets, in the AF_INET family,
    for connections from other processes.  The listening socket is set to non-
    blocking with ioctl() (FIONBIO) after the call to socket() (AF_INET,
    SOCK_STREAM,0).  After the ioctl, setsockopt() (SOL_SOCKET,SO_REUSEADDR)
    is called, followed by bind(), followed by listen() with a backlog paramater

    of 5.

    When a connection is 'heard', accept is called, and the file-descriptor
    returned from accept is used to establish a 'full' connection to the
    client process.  This file-descriptor too has an ioctl done to it
    (non-blocking = FIONBIO), after which it is read from.

    The problem is this; if the client process goes away abruptly, the server
    socket does not know about it.  Further, if a select() is called on the
    (now supposedly 'dead') file-descriptor for reading, it will indicate
    that there is data there.  If the fd is read, 0 bytes are received;
    no error condition is indicated by the recv.  I have seen upto 600 repeated
    select()'s and recv()'s without getting a -1 from recv.

    My questions: 1. Is this a bug of 4.2BSD networking code (it has been a
    'feature' of the Sun kernel since OS 2.2 or so), or 2. incorrect coding
    on my part in establishing the socket, or 3. a result of the fact that
    exceptfd is not implemented for select on 4.2BSD, or 4. my use of the
    non-blocking socket?

    Currently I close down the socket after 100 0-byte recv()'s, but I'd like
    to have a better idea of why this is happening, and how it can be fixed.
    Any clues will be gratefully accepted.

    Robert Allen,
    robert@spam.istc.sri.com
    415-859-2143

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 14:01:35 EDT
From:      hassler@LOGNET2.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Serial IP



Can anyone direct me to a source (preferably Public Domain) for a
Serial Line IP?

Thanks in Advance,

Barry D. Hassler
Control Data Corp
Professional Services Division
Integrated Information Services

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 14:28:21 EDT
From:      ward@cfa.harvard.EDU (Steve Ward)
To:        comp.protocols.tcp-ip
Subject:   Bridge/Excelan VMS/TCP-IP problem




Help needed from TCP/IP, Telnet protocol experts!!!!!!!!

I have Bridge terminal servers talking to DEC MicroVAXes running VMS with
Excelan TCP/IP protocol/Ethernet interface boards.

Here is my most serious problem:  In order to run CAD/CAE graphics and other
applications, the Telnet session must be in binary mode.  The Excelan board
defaults to 7-bit(ASCII) mode.  The Excelan board is designed to expect the
remote client to request binary mode through some Telnet command/request
mechanism.  The Bridge Terminal Servers can easily be tailored by a user
to operate in binary mode, but have no user or system method to be made to
request binary mode on the part of a host.  This means there is no way for
the Excelan board to operate in binary mode when a Bridge terminal server
is used to interface the terminal or other remote client.

All that is needed is for the Excelan board to provide some host-based
method for configuring binary mode, or the Bridge terminal server must
implement some method for requesting binary mode from the host.  NOW FOR
THE REAL PROBLEM: 

Bridge says that they used to implement client request for host
binary mode, but it caused havoc with SUN workstations, so they
took out the command/request mechanism for host binary mode.
 Bridge further stated that the protocol specs are somewhat
ambiguous on whether the client or host is responsible for requesting
or implementing methods to enter binary mode, but at this point they feel
the host is burdened with this function, though they admit they felt
the opposite was true at an earlier point in time.  Bridge sympathizes
with my problem, but declines to do anything to fix it since their
position is that they are conforming to the TCP/IP/Telnet specs.

Excelan takes the same position, saying that per the specs it is clear
that the Bridge terminal servers must issue the appropriate request
for host binary mode, and their board will respond properly to the
request.  Now it is clear that one of these two products is broken, but
which one???  Bridge and Excelan sympathize, but in essence are saying
"nothing wrong with us or our stuff, go away kid, don't bother me."
What is disturbing is that neither outfit is interested in researching
and resolving the problem.  I would think that both companies would
be interested in helping clarify the situation, even perhaps indulging in
a three way conversation, but this interest was not shown.

I do not have RPC's or specs of any kind.  What I ask is that you network
protocol wizards out there discuss this issue and let's see if their is a
concensus as to whether Bridge or Excelan has a broken product in this case.
If the specs turn out to be truly ambiguous, can we initiate a clarification
to eliminate the confusion?

 Excelan, Bridge, are you listening?  I would appreciate a higher
level of concern and support whether you think your product
is broken or not. This problem will cause malfunctions with most,
if not all graphics terminals connected to Bridge terminal servers talking
to the Excelan TCP/IP board.  Are there other TCP/IP protocol boards out
there that assume that the terminal server or other client must request
binary mode?  If so, then using the Bridge terminal server is not wise
since it won't request the binary mode.  If the host must provide a
method for entering binary mode, then clearly the Excelan product is
broken and these problems could be encountered using the Excelan board
with any terminal server or other client.  This should concern all
present and potential customers for these two product lines.

Bridge and Excelan, if you are listening, replies to myself or Roger
Hauck should be e-mailed to me at:  {seismo|ihnp4}!harvard!cfa!ward
                                    or  ward@cfa.harvard.EDU (ARPA)

This topic should be of broad interest and concern, so replies to the
net are also appropriate, in my view.


Steven Ward, Harvard-Smithsonian Astrophysical Observatory
{seismo|ihnp4}!harvard!cfa!ward

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 15:22:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Looking for book


I'm trying to obtain a copy of "Data Networks" by Bertsekas and Gallager.
This is a brand new text and none of my local bookstores seem to have
it in stock or on order.  I'd prefer not to wait the 5-6 weeks a special
order would take.

If anyone happens to know of a bookstore that has it (and will take a
charge card purchase over the phone) I'd appreciate getting their phone
number.

I seem to remember hearing about a computer oriented bookstore in the
Silicon Valley area that was highly recommended.  Anyone have their
number?

					Art@acc.arpa

------

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 21:12:36 EDT
From:      LYNCH@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for book

Art, The computer bookstore you are probably referring to is the
Computer Literacy Bookstore at Techmart in Santa Clara.  I just
called them and snagged the last one in stock (a hot mover?)
and had it shipped to you.  Should arrive MOnday or Tuesday.
The pnone number, anyway, is 408-562-5799.  That bookstore (actually
a collection of three stores up here) does a great job of stocking
stuff we all can use (from time to time).

Cheers,
Dan
-------

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1987 21:12:36 EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        <art@ACC.ARPA>
Cc:        "tcp-ip" <tcp-ip@SRI-NIC.ARPA>, LYNCH@A.ISI.EDU
Subject:   Re: Looking for book
Art, The computer bookstore you are probably referring to is the
Computer Literacy Bookstore at Techmart in Santa Clara.  I just
called them and snagged the last one in stock (a hot mover?)
and had it shipped to you.  Should arrive MOnday or Tuesday.
The pnone number, anyway, is 408-562-5799.  That bookstore (actually
a collection of three stores up here) does a great job of stocking
stuff we all can use (from time to time).

Cheers,
Dan
-------
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 21:25:29 EDT
From:      BUDDENBERGRA@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   SAFENET LAN protocol

Folks on the net might be interested in a sitrep on our work with
a survivable LAN for shipboard use...

Start with an IEEE-802.5 (or ISO 8802/5) token ring.  Add a second,
contra-rotating ring for redundancy.  If the first ring fails,
traffic shifts to the second.  If a double cut or loos of node  
occurs, each last surviving node wraps data from one ring to another
and, voila, self-healing.  As ring is damaged further, partitioning
occurs (cut up a starfish, get multiple starfish), but it keeps on
trucking.

The SAFENET philosophy is to specify a superset of the 802.5
standard that gains the survivability necessary for operational
tactical purposes on ships (to replace a number of point-to-point
links).  Objective is to eventually influence the industry standard
adequately so that no separate MilStd is required.

The initial objective of providing service to computers within the
ship appears within reach fairly quickly.  The goal is something
quotable by October.

Other problems are cropping up that, in my estimation, will be
nowhere near a standards solution this fall.  Leading is the
inability of the ISO stack to provide 'real-time' service.  Since
most of the issues are at higher layers, they are beyond the
scope of a group formed to work on a specific LAN.  Ditto for
network management and multi-level security.

This week we worked over revision 0 which was a 'very first draft'.
Three subcommittees got their components 1) down in writing and
2) all in the same manuscript for the first time, so things were
a bit rough.  But things seem to be moving along; I'll try and
post another report after the next meeting in July.

[All above is personal appraisal and opinion]
Rex Buddenberg
-------

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 1987 21:25:29 EDT
From:      Rex Buddenberg <BUDDENBERGRA@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        BUDDENBERGRA@A.ISI.EDU
Subject:   SAFENET LAN protocol
Folks on the net might be interested in a sitrep on our work with
a survivable LAN for shipboard use...

Start with an IEEE-802.5 (or ISO 8802/5) token ring.  Add a second,
contra-rotating ring for redundancy.  If the first ring fails,
traffic shifts to the second.  If a double cut or loos of node  
occurs, each last surviving node wraps data from one ring to another
and, voila, self-healing.  As ring is damaged further, partitioning
occurs (cut up a starfish, get multiple starfish), but it keeps on
trucking.

The SAFENET philosophy is to specify a superset of the 802.5
standard that gains the survivability necessary for operational
tactical purposes on ships (to replace a number of point-to-point
links).  Objective is to eventually influence the industry standard
adequately so that no separate MilStd is required.

The initial objective of providing service to computers within the
ship appears within reach fairly quickly.  The goal is something
quotable by October.

Other problems are cropping up that, in my estimation, will be
nowhere near a standards solution this fall.  Leading is the
inability of the ISO stack to provide 'real-time' service.  Since
most of the issues are at higher layers, they are beyond the
scope of a group formed to work on a specific LAN.  Ditto for
network management and multi-level security.

This week we worked over revision 0 which was a 'very first draft'.
Three subcommittees got their components 1) down in writing and
2) all in the same manuscript for the first time, so things were
a bit rough.  But things seem to be moving along; I'll try and
post another report after the next meeting in July.

[All above is personal appraisal and opinion]
Rex Buddenberg
-------
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11-Jun-87 22:36:36 EDT
From:      ief@geocub.UUCP
To:        comp.protocols.tcp-ip
Subject:   NSC HyperchannelB - Ethernet TCP/IP gateway

In our lab, we have a TCP/IP Ethernet network and a Network System Corp.
HyperchannelB network. Thus we are naturally leaded to imagine a gateway
between them : this gateway seems a rather difficult problem.

More precisely, people are interested in file transfer between their
minicompiters and mainframes on Hyperchannel (IBM 3090 and Sperry 1100).

Has anybody tried to have something work, or does anybody know of some
experience elsewhere ?

	P.Garda

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jun-87 08:23:04 EDT
From:      mckenzie@J.BBN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  Bridge/Excelan VMS/TCP-IP problem

Steve,

The Telnet protocol was specifically designed to be symmetric; EITHER party to
a Telnet connection is permitted to suggest a shift to binary mode, although
both parties must agree before the shift takes place.  On the other hand,
Telnet is a specification of the PROTOCOL which takes place between two
systems; it is NOT a spec of the interface to the user of Telnet on either
system.  What you are asking for is provision, in the local interface, for one
Telnet user (the terminal user on the Bridge box, or the program on the uVAX)
to ask the local Telnet to suggest the use of binary mode, and for the other
user to agree that this is acceptable.

I do not think you will find anything in the Telnet specs on which to base a
claim that either interface MUST supply this functionality.  In fact, binary
mode is a Telnet OPTION, and by definition is not required.  So in my opinion,
neither of the Telnet implementations is "broken" in the sense you suggest.  [I
do believe Excelan is wrong if they told you the spec forbids them from
suggesting binary mode, but that's not, I think, the main point.] Rather, the
user community needs to convince one or both of these manufacturers that their
implementation would be much more useful if it provided the additional
functionality.  One way to do this is to switch from purchases of the less
useful product to a more useful product, although this may not be feasible in
your case.  Another way is to just keep up the pressure on the manufacturer.

Regards,
Alex McKenzie
 

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jun 87 8:23:04 EDT
From:      Alex McKenzie <mckenzie@j.bbn.com>
To:        Steve Ward <cfa!ward@husc6.harvard.edu>
Cc:        tcp-ip@sri-nic.ARPA
Subject:   Re:  Bridge/Excelan VMS/TCP-IP problem
Steve,

The Telnet protocol was specifically designed to be symmetric; EITHER party to
a Telnet connection is permitted to suggest a shift to binary mode, although
both parties must agree before the shift takes place.  On the other hand,
Telnet is a specification of the PROTOCOL which takes place between two
systems; it is NOT a spec of the interface to the user of Telnet on either
system.  What you are asking for is provision, in the local interface, for one
Telnet user (the terminal user on the Bridge box, or the program on the uVAX)
to ask the local Telnet to suggest the use of binary mode, and for the other
user to agree that this is acceptable.

I do not think you will find anything in the Telnet specs on which to base a
claim that either interface MUST supply this functionality.  In fact, binary
mode is a Telnet OPTION, and by definition is not required.  So in my opinion,
neither of the Telnet implementations is "broken" in the sense you suggest.  [I
do believe Excelan is wrong if they told you the spec forbids them from
suggesting binary mode, but that's not, I think, the main point.] Rather, the
user community needs to convince one or both of these manufacturers that their
implementation would be much more useful if it provided the additional
functionality.  One way to do this is to switch from purchases of the less
useful product to a more useful product, although this may not be feasible in
your case.  Another way is to just keep up the pressure on the manufacturer.

Regards,
Alex McKenzie
 
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jun-87 12:17:39 EDT
From:      MRC@PANDA.COM (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Telnet binary mode

All Telnet servers should have a command that a network user can issue
that puts the network terminal in binary mode.  PANDA TOPS-20's have
the command TERMINAL [NO] NETWORK-BINARY [INPUT | OUTPUT | BOTH].

All Telnet clients should have a command that a Telnet user can issue
that puts the Telnet connection in binary mode.  TOPS-20 TELNET has
an escape sequence and a command to put the connection into so-called
"transparent mode."

Binary mode should never, ever, be done automatically by either a
host or a client unless it is damned sure that 8-bit I/O is what is
wanted.  It must never, ever, be a side effect of some data that a
user outputs (e.g. an FFh character output by a user program must be
doubled by the operating system and not allowed to be interpreted as
a Telnet protocol command).

Binary mode should never, ever, be tied to the host's concept of a
terminal in binary mode (Unix calls this "raw" as opposed to "cooked"
mode).  Certain inferior losing versions of Unix and TOPS-20 both do
this -- most of the turkey TOPS-20 implementations have been exterminated
but there are still many turkey Unix implementations out there.  Being a
turkey leads to the infamous "new Telnet rubout performance problem" of
the late 1970's plus confusion Unix newline confusion.

Implementation details of the TOPS-20 code on request; I wrote it.  The
only TOPS-20's with correct servers are SIMTEL20, STL-HOST1, and DREA-XX;
all other TOPS-20's have either completely broken servers or servers with
half-assed fixes (e.g. Stanford TOPS-20's).
-------

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jun-87 14:31:36 EDT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

Geoff,
	I am surprised nobody has mentioned the issue of how does
someone off-net ever address anything to the PC-host?  There has
been no notion of updating a name server to be able to tell remote
systems the PC's address (what if the remote system caches it?).
I think this impacts the duration of the IP/PC binding, since re-
using an IP address means former associations are now void implicitly.

	Maybe I don't understand the environment enough.  I guess the
highly transient association of PC and IP address is OK if the PC
always initiates the communication.  Perhaps this is to download files
for local work, perhaps just to act as a terminal emulator (where the
user logs in at the mainframe across the net).  The issue of positively
identifying that this PC is who it says it is gets lost if IP address
is floating each time the PC is turned on.  Perhaps the mainframe (as
I characterize non-PC hosts) has no need to contact the PC or try to
deliver datagrams to it until the PC comes up and announces itself?

	Walt Lazear

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jun-87 14:33:30 EDT
From:      weiser.pa@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Serial IP

Serial IP code: The machine mimsy.umd.edu has the two files
'seismo.sl.shar' and 'sunsl.shar' available.
The first is just a copy of the code available from Rick Adams at
Seismo, the second is a version
I fiddled with for use on Suns.

-mark weiser

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12-Jun-87 16:38:29 EDT
From:      braden@BRADEN.ISI.EDU (Bob Braden)
To:        comp.protocols.tcp-ip
Subject:   Re:  SAFENET LAN protocol


	
	Other problems are cropping up that, in my estimation, will be
	nowhere near a standards solution this fall.  Leading is the
	inability of the ISO stack to provide 'real-time' service. 
	
Can you explain/amplify that last comment??  What do you mean by
"'real-time' service"? 

Thanks.

    Bob Braden

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13-Jun-87 20:12:04 EDT
From:      ravi@ubc.CSNET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

Hi,

	Dynamic address assignment has been employed in some experimental
distributed operating systems. Though the host addresses thus assigned are
not IP addresses, the techniques may be adapted to assigning IP addresses
dynamically. For example, the V distributed operating system developed at
the Stanford University uses a dynamic address assignment protocol similar
to that of your "defended addresses". The system has a large pool of
assignable addresses from which a booting machine picks up one (based on
random number generation) and solicits any objections to its usage of the
address. A machine that may already use the address "defends" the address by
raising an objection. If no objection is received by the booting machine, it
starts using the address. Otherwise, it picks up another one and tries
again. We at the University of British Columbia have designed a variant of
the protocol to make sure that the addresses are non-reusable in the "near
future". Both schemes are distributed and do not suffer from single-point
failures. Our protocol additionally guarantees non-reusability of addresses
if reliability is a concern.

	We have a technical report which describes the implications of such
dynamic bindings between host and network addresses, how cached bindings are
invalidated/corrected in a dynamic environment such as when machines fail
and come up later, resolving multiply assigned addresses (because of network
failures), etc. The report is awaiting publication in "Computer Networks and
the ISDN" journal. If any one wants the report, send me an e-mail.

				Ravindran
				Dept. of Computer Science,
				Univ. of British Columbia,
				Vancouver B.C. V6T 1W5, Canada.
				Ph: (604) 228-5485

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14-Jun-87 14:34:05 EDT
From:      dpk@BRL.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re:  NSC HyperchannelB - Ethernet TCP/IP gateway

I know of no gateway that one can plug in and run between
a TCP/IP network and a Hyperchannel.  If you can obtain
TCP/IP for the IBM and/or the Sperry (they do exist), then
you could make one minicomputer a gateway by giving it an
interface on both the Hyperchannel and the other TCP/IP
networks.  Here at BRL, we have a Hyperchannel connecting our
CRAY to a Gould PN6000 which is in turn connected to the
building Ethernet.  The Gould runs UTX2.0 (4.3BSD) and acts
as the IP gateway between the Hyperchannel and the Ether.
The key is getting the same protocol suite on both machines.

-Doug-

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Jun-87 09:08:01 EDT
From:      van@LBL-CSAM.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: interpacket arrival variance and mean

Mark -

I'm working on long paper about transport protocol timers (models,
estimation, implementations, common implementation mistakes, etc.).
This has me all primed on the subject so attached is a long-winded
explanation and example C code for estimating the mean and variance
of a series of measurements.

Though I know your application isn't tcp, I'm going to use a new
tcp retransmit timer algorithm as an example.  The algorithm
illustrates the method and, based on 3 months of experiment, is
much better than the algorithm in rfc793 (though it isn't as good
as the algorithm I talked about at IETF and am currently debugging). 

Theory
------
You're probably familiar with the rfc793 algorithm for estimating
the mean round trip time.  This is the simplest example of a
class of estimators called "recursive prediction error" or
"stochastic gradient" algorithms.  In the past 20 years these
algorithms have revolutionized estimation and control theory so
it's probably worth while to look at the rfc793 estimator in some
detail. 

Given a new measurement, Meas, of the rtt, tcp updates an
estimate of the average rtt, Avg, by

	Avg <- (1 - g) Avg  +  g Meas

where g is a "gain" (0 < g < 1) that should be related to the
signal- to-noise ratio (or, equivalently, variance) of Meas. 
This makes a bit more sense (and computes faster) if we rearrange
and collect terms multiplied by g to get

	Avg <- Avg + g (Meas - Avg)

We can think of "Avg" as a prediction of the next measurement. 
So "Meas - Avg" is the error in that prediction and the
expression above says we make a new prediction based on the old
prediction plus some fraction of the prediction error.  The
prediction error is the sum of two components: (1) error due to
"noise" in the measurement (i.e., random, unpredictable effects
like fluctuations in competing traffic) and (2) error due to a
bad choice of "Avg".  Calling the random error RE and the
predictor error PE,

	Avg <- Avg + g RE + g PE

The "g PE" term gives Avg a kick in the right direction while the
"g RE" term gives it a kick in a random direction.  Over a number
of samples, the random kicks cancel each other out so this
algorithm tends to converge to the correct average.  But g
represents a compromise: We want a large g to get mileage out of
the PE term but a small g to minimize the damage from the RE
term.  Since the PE terms move Avg toward the real average no
matter what value we use for g, it's almost always better to use
a gain that's too small rather than one that's too large. 
Typical gain choices are .1 - .2 (though it's always a good
idea to take long look at your raw data before picking a gain). 

It's probably obvious that Avg will oscillate randomly around
the true average and the standard deviation of Avg will be
something like g sdev(Meas).  Also that Avg converges to the
true average exponentially with time constant 1/g.  So
making g smaller gives a stabler Avg at the expense of taking
a much longer time to get to the true average.

[My paper makes the preceding hand-waving a bit more rigorous
but I assume no one cares about rigor.  If you do care, check
out almost any text on digital filtering or estimation theory.]

If we want some measure of the variation in Meas, say to compute
a good value for the tcp retransmit timer, there are lots of
choices.  Statisticians love variance because it has some nice
mathematical properties.  But variance requires squaring (Meas -
Avg) so an estimator for it will contain two multiplies and a
large chance of integer overflow.  Also, most of the applications
I can think of want variation in the same units as Avg and Meas,
so we'll be forced to take the square root of the variance to use
it (i.e., probably at least a divide, multiply and two adds). 

A variation measure that's easy to compute, and has a nice,
intuitive justification, is the mean prediction error or mean
deviation.  This is just the average of abs(Meas - Avg). 
Intuitively, this is an estimate of how badly we've blown our
recent predictions (which seems like just the thing we'd want to
set up a retransmit timer).  Statistically, standard deviation
(= sqrt variance) goes like sqrt(sum((Meas - Avg)^2)) while mean
deviation goes like sum(sqrt((Meas - Avg)^2)).  Thus, by the
triangle inequality, mean deviation should be a more "conservative"
estimate of variation. 

If you really want standard deviation for some obscure reason,
there's usually a simple relation between mdev and sdev.  Eg.,
if the prediction errors are normally distributed, mdev =
sqrt(pi/2) sdev.  For most common distributions the factor
to go from sdev to mdev is near one (sqrt(pi/2) ~= 1.25).  Ie.,
mdev is a good approximation of sdev (and is much easier to
compute).

Practice
--------
So let's do estimators for Avg and mean deviation, Mdev.  Both
estimators compute means so we get two instances of the rfc793
algorithm:

	Err = abs (Meas - Avg)
	Avg <- Avg + g (Meas - Avg)
	Mdev <- Mdev + g (Err - Mdev)

If we want to do the above fast, it should probably be done in
integer arithmetic.  But the expressions contain fractions (g < 1)
so we'll have to do some scaling to keep everything integer.  If
we chose g so that 1/g is an integer, the scaling is easy.  A
particularly good choice for g is a reciprocal power of 2 
(ie., g = 1/2^n for some n).  Multiplying through by 1/g gives

	2^n Avg <- 2^n Avg + (Meas - Avg)
	2^n Mdev <- 2^n Mdev + (Err - Mdev)

To minimize round-off error, we probably want to keep the scaled
versions of Avg and Mdev rather than the unscaled versions.  If
we pick g = .125 = 1/8 (close to the .1 that rfc793 suggests) and
express all the above in C:

	Meas -= (Avg >> 3);
	Avg += Meas;
	if (Meas < 0)
		Meas = -Meas;
	Meas -= (Mdev >> 3);
	Mdev += Meas;

I've been using a variant of this to compute the retransmit timer
for my tcp.  It's clearly faster than the two floating point
multiplies that 4.3bsd uses and gives you twice as much information.
Since the variation is estimated dynamically rather than using
the wired-in beta of rfc793, the retransmit performance is also
much better: faster retransmissions on low variance links and
fewer spurious retransmissions on high variance links. 

It's not necessary to use the same gain for Avg and Mdev. 
Empirically, it looks like a retransmit timer estimate works
better if there's more gain (bigger g) in the Mdev estimator. 
This forces the timer to go up quickly in response to changes in
the rtt.  (Although it may not be obvious, the absolute value in
the calculation of Mdev introduces an asymmetry in the timer:
Because Mdev has the same sign as an increase and the opposite
sign of a decrease, more gain in Mdev makes the timer go up fast
and come down slow, "automatically" giving the behavior Dave
Mills suggests in rfc889.)

Using a gain of .25 on the deviation and computing the retransmit
timer, rto, as Avg + 2 Mdev, my tcp timer code looks like:

	Meas -= (Avg >> 3);
	Avg += Meas;
	if (Meas < 0)
		Meas = -Meas;
	Meas -= (Mdev >> 2);
	Mdev += Meas;
	rto = (Avg >> 3) + (Mdev >> 1);

Hope this helps.

  - Van

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Jun-87 14:05:49 EDT
From:      robert@SPAM.ISTC.SRI.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Final Report on 0-byte recv()'s on 4.2 TCP sockets. (LONG)


	Here is a summary of replies regarding my problem with
0-byte recv()'s on TCP sockets.  As a capsule review, all of the
answers I received were of the opinion that reading 0 bytes was a
UNIX-like indication of EOF.  My reply to this is twofold;

    First, in my humble opinion a socket is not *really* a file.  The
    file descriptor interface is a UNIX-ism for the TCP connection
    abstraction, but shouldn't necessarily follow all the rules for
    file I/O.  In particular, I believe that since the TCP socket is
    a logical connection, the concept of a socket 'going bad' is more
    apt than 'reaching EOF'.  Of course, my dispensation of file status
    on a socket is somewhat hypocritical, as I have in the past complained
    that non-blocking sockets *don't* act like files in regards to read()
    and write() (> 2k byte transfers fail;  it's a 4.2 bug according to Mike
    Karrels).

    Second, select() is still indicating data as being there, so the
    claim that EOF is encountered seem's rather bogus to me.  As I
    mentioned, this will occur for quite a while, if not forever; I've
    watched upto 600 consecutive read()s produce 0, even though
    select() claimed that data was there.  I now close and restart
    the socket after 100 0-byte read()s, and will probably close
    and restart after even 1 based on what I've read on the net.
    This feature of select may be the result of 'exceptfds' not
    being implemented under 4.2.

Many thanks to everyone who provided input,

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

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

::::::::::::::
 tcp_mail/1
::::::::::::::
From: Steve Schoch <schoch@ames.arpa>
To: robert@spam.istc.sri.com
Subject: Re: Problems with TCP/IP sockets under 4.2.

In article <8706111552.AA08325@spam.istc.sri.com> you write:
>    The problem is this; if the client process goes away abruptly, the server
>    socket does not know about it.  Further, if a select() is called on the
>    (now supposedly 'dead') file-descriptor for reading, it will indicate
>    that there is data there.  If the fd is read, 0 bytes are received;

This is correct.  The way I interpret select() is that it returns whenever
a read will return without blocking.  In unix, a read of 0 bytes always
indicates EOF and you should not continue to read from it.  Exceptions are
files that are growing, in which case you should sleep before the next read,
and ttys, which are kind of special in that you can read past EOF and get the
next character typed after the ^D.

>    no error condition is indicated by the recv.  I have seen upto 600 repeated
>    select()'s and recv()'s without getting a -1 from recv.

That's because it's not an error for the client process to exit, it's an
end-of-file, i.e., no more data is available.  When your program reads an
EOF it should not attempt to read any more data as there will never be
any more.

::::::::::::::
 tcp_mail/3
::::::::::::::
From: mankin@gateway.mitre.org (Allison J. Mankin)
To: robert@spam.istc.sri.com
Subject: Re:  Problems with TCP/IP sockets under 4.2.

Robert,

You are having a problem because the server's socket registers the
client's change of status (closed or gone, whatever) with its read
bit.  The zero recv instead of an error is offered *on purpose* by
the system to indicate that the change of status was due to a proper
close, that is, a TCP FIN was received from the client.

So, it is a undocumented feature that's causing you trouble, rather
than a bug.  It is this way in both 4.2 and 4.3 derived systems.

One way to deal with it is to keep track of the state of sockets
and take them off of select the first time that the zero recv 
indicates the peer closed--there can be no more data to recv anyway.

			Allison
::::::::::::::
 tcp_mail/4
::::::::::::::
To: Robert Allen <robert@spam.istc.sri.com>
Subject: Re: Problems with TCP/IP sockets under 4.2. 
From: John Hight <hight@tsca.istc.sri.com>


Robert,

I can't help with your problem, however, I think I might have experienced
similar problems some time back, so I would be interested in any
meaningful responses you get back that perhaps are sent out over the
tcp/ip list.

John
::::::::::::::
 tcp_mail/6
::::::::::::::
From: brd@sun.com (Bill Danielson)
To: robert@spam.istc.sri.com
Subject: Problems with TCP/IP sockets under 4.2

In Unix, any read returning zero bytes means "end of file".  This is way
you can tell when "end-of-file" occurs when, say, reading a disk file.
Unix does not use the -1 return to indicate "end-of-file".

When you are reading from a TCP connection, end-of-file is signalled if
the other side closes the connection.  

If you had done a non-blocking read and no data had been received,
read would have returned -1 and errno = EWOULDBLOCK.  Thus, you can
distinguish between "no data" and "end-of-file".

Bill Danielson

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Jun-87 15:28:54 EDT
From:      cdjohns@NSWC-G.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   FIN_WAIT_2 problem ?


	The problem in question is that of a TCP session left in limbo
due to the unusual termination of the matching socket on the remote host.
This condition is usually characterized by a TCP session dangling in the
FIN_WAIT_2 or LAST_ACK states.  This indicates that the session is awaiting
the arrival of a final FIN or ACK of FIN.  The sessions will never see these
messages because the matching side of the connection is either dead or awaiting
a similiar message.

	We finally decided to look in to the problem seriously and have come up
with the following observations and (apparently) reasonable solution.

When a TCP session is hung, it's usually in FIN_WAIT_2 or LAST_ACK.

Normally, a session in FIN_WAIT_2 will receive a FIN, send ACK and transition to
TIME_WAIT.  In this state, the session waits a default amount of time 
(suggested 1 minute) and then assumes the matching side of the connection
received the ACK of FIN. Then the TCP Protocol Control Block (PCB) is deleted
and the session is closed. (the PCB is the internal representation of the 
TCP connection)

The timer mentioned above is referred to as the 2MSL timer and is apparantly
only used in the TIME_WAIT state.  This timer is simple in operation.  The
current value of the timer is stored in the PCB for that session. (the 
structure of a TCP PCB can be found in <netinet/in_pcb.h> ) The kernel
decrements this counter every 500ms until it reaches zero, then the session
is internally deleted.

The solution we have found to the dangling session is to fake the kernel into
thinking the session is in the TIME_WAIT state, ready to die.  This is done by
setting the 2MSL timer to a non-zero value.  The kernel then takes over, 
decrementing the timer until it reaches zero and ZAP! the TCP session is gone.
This setting of the timer is easily done with adb.

It is sometimes the case that both sides of the connection are hung, one in FIN_WAIT_2, the other in LAST_ACK.  It appears that clearing the FIN_WAIT_2 using
the above method will also clear the matching LAST_ACK.

If this appears to be a reasonable solution, a permanent solution might be 
achieved in the following way:
Upon entering the FIN_WAIT_2 state, set the 2MSL timer to a large enough 
default time to give the remote host adequate time to send the FIN.  If the FIN
never shows up, eventually the PCB will be deleted.

We would appreciate any comments about this solution.  The following script
should demonstrate setting the 2MSL timer.

------------------- adb script starts here ------------------

#!/bin/sh
#  This script is designed to aid in eliminating lingering TCP
#  connections without having to reboot the host kernel.
#  It is intended to be used on TCP connections stuck in the
#  FIN_WAIT_2 state.  Elimination of the connection is done 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 reachs 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 (FIN_WAIT_2 should be cleared as a first try).


# MSLOFFSET is the offset in the tcpcb record for the 2MSL timer.
# The tcpcb record is found in <netinet/in_pcb.h>
# This value is the number of bytes offset, expressed in hexidecimal.

MSLOFFSET=10

# TIMETODEATH is the number of half seconds until the connection is 
# closed.  This value is expressed in hexidecimal and must be greater
# than zero.

TIMETODEATH=06

# Display netstat.  Addresess for PCB's are found in first column.

netstat -A

echo
echo 'PCB address to terminate ? '
read addr
echo

# Perform adb on kernel and 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 'Is this the correct PCB (y/n) ?     (state = 9 = FIN_WAIT_2) '
read ans
echo
if test $ans != 'y'
  then echo 'No Changes.'
       exit
fi

# Perform adb on kernel and set the 2MSL timer for the PCB

adb -k -w /vmunix /dev/mem << SHAR_EOF
$addr+$MSLOFFSET/w $TIMETODEATH
\$q
SHAR_EOF

# These lines are used 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 0x'$TIMETODEATH'/2 seconds.'
echo 
echo 'netmod done.'



=============================================================================

Chuck     --  Naval Surface Weapons Center
Johnson       Code K33 (Systems Integration and Networking)
              Dahlgren, Va  22448
              DDN Mail -  cdjohns@nswc-g.arpa
		   or     cdjohns@nswc-oas.arpa
              phone - (703) 663 - 7745

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 87 15:28:54 edt
From:      cdjohns@nswc-g.ARPA
To:        tcp-ip@sri-nic.arpa, unix-wizards@brl.arpa
Cc:        cdjohns
Subject:   FIN_WAIT_2 problem ?

	The problem in question is that of a TCP session left in limbo
due to the unusual termination of the matching socket on the remote host.
This condition is usually characterized by a TCP session dangling in the
FIN_WAIT_2 or LAST_ACK states.  This indicates that the session is awaiting
the arrival of a final FIN or ACK of FIN.  The sessions will never see these
messages because the matching side of the connection is either dead or awaiting
a similiar message.

	We finally decided to look in to the problem seriously and have come up
with the following observations and (apparently) reasonable solution.

When a TCP session is hung, it's usually in FIN_WAIT_2 or LAST_ACK.

Normally, a session in FIN_WAIT_2 will receive a FIN, send ACK and transition to
TIME_WAIT.  In this state, the session waits a default amount of time 
(suggested 1 minute) and then assumes the matching side of the connection
received the ACK of FIN. Then the TCP Protocol Control Block (PCB) is deleted
and the session is closed. (the PCB is the internal representation of the 
TCP connection)

The timer mentioned above is referred to as the 2MSL timer and is apparantly
only used in the TIME_WAIT state.  This timer is simple in operation.  The
current value of the timer is stored in the PCB for that session. (the 
structure of a TCP PCB can be found in <netinet/in_pcb.h> ) The kernel
decrements this counter every 500ms until it reaches zero, then the session
is internally deleted.

The solution we have found to the dangling session is to fake the kernel into
thinking the session is in the TIME_WAIT state, ready to die.  This is done by
setting the 2MSL timer to a non-zero value.  The kernel then takes over, 
decrementing the timer until it reaches zero and ZAP! the TCP session is gone.
This setting of the timer is easily done with adb.

It is sometimes the case that both sides of the connection are hung, one in FIN_WAIT_2, the other in LAST_ACK.  It appears that clearing the FIN_WAIT_2 using
the above method will also clear the matching LAST_ACK.

If this appears to be a reasonable solution, a permanent solution might be 
achieved in the following way:
Upon entering the FIN_WAIT_2 state, set the 2MSL timer to a large enough 
default time to give the remote host adequate time to send the FIN.  If the FIN
never shows up, eventually the PCB will be deleted.

We would appreciate any comments about this solution.  The following script
should demonstrate setting the 2MSL timer.

------------------- adb script starts here ------------------

#!/bin/sh
#  This script is designed to aid in eliminating lingering TCP
#  connections without having to reboot the host kernel.
#  It is intended to be used on TCP connections stuck in the
#  FIN_WAIT_2 state.  Elimination of the connection is done 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 reachs 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 (FIN_WAIT_2 should be cleared as a first try).


# MSLOFFSET is the offset in the tcpcb record for the 2MSL timer.
# The tcpcb record is found in <netinet/in_pcb.h>
# This value is the number of bytes offset, expressed in hexidecimal.

MSLOFFSET=10

# TIMETODEATH is the number of half seconds until the connection is 
# closed.  This value is expressed in hexidecimal and must be greater
# than zero.

TIMETODEATH=06

# Display netstat.  Addresess for PCB's are found in first column.

netstat -A

echo
echo 'PCB address to terminate ? '
read addr
echo

# Perform adb on kernel and 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 'Is this the correct PCB (y/n) ?     (state = 9 = FIN_WAIT_2) '
read ans
echo
if test $ans != 'y'
  then echo 'No Changes.'
       exit
fi

# Perform adb on kernel and set the 2MSL timer for the PCB

adb -k -w /vmunix /dev/mem << SHAR_EOF
$addr+$MSLOFFSET/w $TIMETODEATH
\$q
SHAR_EOF

# These lines are used 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 0x'$TIMETODEATH'/2 seconds.'
echo 
echo 'netmod done.'



=============================================================================

Chuck     --  Naval Surface Weapons Center
Johnson       Code K33 (Systems Integration and Networking)
              Dahlgren, Va  22448
              DDN Mail -  cdjohns@nswc-g.arpa
		   or     cdjohns@nswc-oas.arpa
              phone - (703) 663 - 7745


-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15-Jun-87 17:51:26 EDT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   SLIP

Folks,

I need information on SLIP.  What kind of hardware supports it? 
Implementations?  Any body working on it?

Any help is greatly appreciated.


				-- Sergio

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 09:03:47 EDT
From:      howard@COS.COM (Howard C. Berkowitz)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: OSI-model software

In article <920@bloom-beacon.MIT.EDU>, martillo@athena.mit.edu (Yakim Martillo) writes:
> Personally, I have always found this confusing because I have
> read the ISO documents and have never seen anything which implies
> there must be only one protocol at every layer.  Further, I thought
> swap in and swap out of protocol layers should be possible.

It is emphatically true that there need not be one protocol per layer;
examples are given below.  The ISO OSI Reference Model is a context
for defining specific layer services and protocols; Implementors'
Agreements and Functional Profiles details the options to be used
if interoperability is the goal.  The Corporation for Open Systems
(COS) currently has a number "protocol stacks" defined for future
conformance certification; these stacks have a fair variation of
lower-layer protocols( i.e., various LAN and WAN technologies)
 supporting upper-layer messaging (MHS/X.400)
and file transfer, access, and management (FTAM).  More stacks
are being defined.
> 
> TCP and IP are tailored to each other but I have seen nothing
> which implies that TCP could not run over ISO IP or which implies
> TP4 could not run over IP.
> 
> In fact there might be reason to tailor a transport protocol for
> certain classes of protocols.
To some extent, this is being done now.  ISO defines five classes
of the transport protocol, Class 0 having minimum functionality
and Class 4 maximum (essentially that of TCP).  COS uses Class 4
for most applications, but allows Class 0 for certain modes of
operation over X.25 networks, which provide lower-layer error
recovery not offered by LANs.
> 
> In any case I don't quite understand why IP and ISO IP can't be
> coresident in the network. 

This should be possible.  Note, however, that their functionality
is quite similar, and DoD has stated a policy of migration to ISO.

>The communications subnet protocol will
> have some way of indentifying the level 3 protocol to the host level 3
> layer software (like the type field in ethernet 2.0 or like ssap/dsap
> tuples in IEEE 802.2)
> 
> IEEE 802.2 and ISO level 2 puzzle me as well.  These are protocols for
> the communications subnet and I don't quite understand why IEEE and
> ISO are trying to define communications subnet protocols for all time.

Realize first that ISO has split Layer 2 into two sublayers:  the
Logical Link Control (LLC) sublayer, where 802.2 lives, and the Media Access
Control (MAC) Layer, which defines the mechanism used to control access
to the shared medium, as opposed to the medium-dependent Layer 1
mechanisms used to transmit over it.

802.2 is medium independent, and basically provides framing and
limited error detection.  It is practically necessary, in an
implementation context, to shield upper layers from some of the
details of interrupt handling, buffer management, etc.  An 802.2
interface can be convenient at the communications chip level,
to give a relatively constant interface to upper layers using
quite different lower layers.

IEEE and ISO definitely are not trying to define communications
subnet protocols for all applications.  Again, this comment seems
to represent the common misconception that the OSI community 
prescribes one protocol per layer; it simply does not.

At the MAC sublayer, there are three especially common protocols
using different media access control approaches:
802.3 (using Carrier Sense Multiple Access/Collision Detection),
802.4 (using Token Passing Bus), and 802.5 (using Token Passing
Ring).  802.3, essentially equivalent to Phase 2 ETHERNET, is 
a robust technology, rather easy to implement.  It does not offer
deterministic delay, which is needed for process control applications
[note:  there is much theological debate about whether it is;
I leave that to the theologians.].  802.4 is the preferred LAN
protocol of the Manufacturing Automation Protocol (MAP) user group.
802.5 offers high reliability and compatibility with certain non-OSI
protocols as seen in SNA architecture.

MAC and LLC protocols can mix and match on top of specific media.
For example, 802.3 protocols have well-defined physical subtypes
appropriate for different environments, identified as 802.3 XYZ,
where X is the data rate in megabits per second, Y is the medium,
and Z is the maximum physical length in hundreds of meters:

       10Base5 is thickwire "ETHERNET" cable -- 10 MBPS for 500 M
        1Base5 is "STARLAN" type twisted pair
       10Broad36 is a broadband implementation...

Similar variants exist for 802.4 and 802.5.  Other LAN protocols
are emerging for specific communities of interest, such as FDDI
very-high-speed optical fiber with kilometer range.

The key point here is not that there is one protocol, but a whole
family of protocols with standardized interfaces between layers.
Internetworking is a Layer 3 problem, not Layer 2, so, for example,
the goal is to have a common Layer 3 for a variety of quite necessary
LANs.

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

SEMI-DISCLAIMER

   I am a conformance testing system developer for the Corporation
for Open Systems, and primary instructor for the COS seminar.  Information
in this posting are accurate to the best of my knowledge, as a worker
in the field.  Nevertheless, statements here are not necessarily the
final word of the Corporation for Open Systems, ISO, ANSI, IEEE,
CCITT, the Internal Revenue Service, etc.
> Shouldn't communications subnet protocols be medium-dependent?
 MAC and PHY (Layer 1) protocols are, MAC somewhat so and PHY definitely.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 10:05:37 EDT
From:      cdjohns@NSWC-G.ARPA
To:        comp.protocols.tcp-ip
Subject:   FIN_WAIT_2 problem ? (correction)

If you were interested in the adb script I sent yesterday, you will
be interested in this correction
the TCP PCB structure can be found in <netinet/tcp_var.h> rather than
<netinet/in_pcb.h>
sorry for the bad dump.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 11:03:12 EDT
From:      Stevens@A.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   ICMP, tracing, and similar SURAN work


Several messages appeared in April and May 87 about ICMP echo,
suggestions for new ICMP options, need for echoes at all protocol
layers, etc.  I just wanted to pass on an overview from similar work
in the DARPA Survivable Adaptable Networks (SURAN) program.  (A SURAN
network is made up packet radios (PRs) and lies below the internet.)

This message describes the Journey and Route Tracing protocol designed
for SURAN.  (Note that only part has been implemented to date.)  The
protocol tells the PRs how to make a packet travel a particular journey
and optionally tells the PRs how to make a packet travel a particular
route on one leg of the journey, what trace data to capture along the
journey, and/or what trace data to capture along one leg of the journey.

A leg is equivalent to an end-to-end path or route which is made up of
one or more hops, while a journey is made up of one or more legs.  A
leg is equivalent to sending an IP packet on a path from a source to a
destination and a journey then is the concatenation of several legs.
For example, an ICMP echo and associated ICMP echo reply are equivalent
to a journey of 2 legs.

An example of the use of the journey and route protocol is:

    Suppose that a network monitor at node A wants to record the
    route from node B to C.  Well the network monitor would build
    a journey packet which contains the following commands:
         (1)  journey destination #1 = B
              route command for B = perform route tracing to
                   next journey destination (node)
         (2)  journey destination #2 = C
              no route command for C
         (3)  journey destination #3 = A
    Thus the packet will be routed from A to B.  Next the packet
    will be routed from B to C and the route will be recorded
    (in a fashion similar to IP record route option).  Finally,
    the packet will be routed from C to A with the desired recorded
    route from B to C.

The journey and route trace protocol is designed to lie above (or
within) either the SURAN network or transport protocols.  Note that the
internet contains similar type processing above both layers as well (IP
options and ICMP within Internet Protocol and the echo port above TCP &
UDP).  Basically, the journey processing is performed above (or within)
the transport protocol while the optional leg processing is performed
above (or within) the network protocol.  

For further information:

    On SURAN Protocols in general - John Jubin & Janet Tornow, "The
    DARPA Packet Radio Network Protocols", IEEE Proceedings, Jan 1987.

    On Journey and Route Tracing in particular - Jim Stevens, SRNTN
    #49, "Journey and Route Tracing".  (SRNTN stands for SURAN
    Technical Note (SRNTN) and is similar to an RFC).  DARPA has
    declared that the distribution of SRNTN #49 is limited to U.S.
    Government agencies and their contractors and that SRNTN #49
    contains technical data whose export is restricted by the Arms
    Export Control Act.  SRNTN #49 should soon be available from the
    Defense Technical Information Center (DTIC), Cameron Center,
    Alexandria, Virginia 22314.  
-------

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 1987 11:03:12 EDT
From:      Jim Stevens <Stevens@A.ISI.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        SRN-MGMT@A.ISI.EDU, Jubin@A.ISI.EDU, Stevens@A.ISI.EDU
Subject:   ICMP, tracing, and similar SURAN work

Several messages appeared in April and May 87 about ICMP echo,
suggestions for new ICMP options, need for echoes at all protocol
layers, etc.  I just wanted to pass on an overview from similar work
in the DARPA Survivable Adaptable Networks (SURAN) program.  (A SURAN
network is made up packet radios (PRs) and lies below the internet.)

This message describes the Journey and Route Tracing protocol designed
for SURAN.  (Note that only part has been implemented to date.)  The
protocol tells the PRs how to make a packet travel a particular journey
and optionally tells the PRs how to make a packet travel a particular
route on one leg of the journey, what trace data to capture along the
journey, and/or what trace data to capture along one leg of the journey.

A leg is equivalent to an end-to-end path or route which is made up of
one or more hops, while a journey is made up of one or more legs.  A
leg is equivalent to sending an IP packet on a path from a source to a
destination and a journey then is the concatenation of several legs.
For example, an ICMP echo and associated ICMP echo reply are equivalent
to a journey of 2 legs.

An example of the use of the journey and route protocol is:

    Suppose that a network monitor at node A wants to record the
    route from node B to C.  Well the network monitor would build
    a journey packet which contains the following commands:
         (1)  journey destination #1 = B
              route command for B = perform route tracing to
                   next journey destination (node)
         (2)  journey destination #2 = C
              no route command for C
         (3)  journey destination #3 = A
    Thus the packet will be routed from A to B.  Next the packet
    will be routed from B to C and the route will be recorded
    (in a fashion similar to IP record route option).  Finally,
    the packet will be routed from C to A with the desired recorded
    route from B to C.

The journey and route trace protocol is designed to lie above (or
within) either the SURAN network or transport protocols.  Note that the
internet contains similar type processing above both layers as well (IP
options and ICMP within Internet Protocol and the echo port above TCP &
UDP).  Basically, the journey processing is performed above (or within)
the transport protocol while the optional leg processing is performed
above (or within) the network protocol.  

For further information:

    On SURAN Protocols in general - John Jubin & Janet Tornow, "The
    DARPA Packet Radio Network Protocols", IEEE Proceedings, Jan 1987.

    On Journey and Route Tracing in particular - Jim Stevens, SRNTN
    #49, "Journey and Route Tracing".  (SRNTN stands for SURAN
    Technical Note (SRNTN) and is similar to an RFC).  DARPA has
    declared that the distribution of SRNTN #49 is limited to U.S.
    Government agencies and their contractors and that SRNTN #49
    contains technical data whose export is restricted by the Arms
    Export Control Act.  SRNTN #49 should soon be available from the
    Defense Technical Information Center (DTIC), Cameron Center,
    Alexandria, Virginia 22314.  
-------
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 11:06:11 EDT
From:      weiser.pa@XEROX.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP

Some public domain slip implementations can be found via anonymous ftp
on host mimsy.umd.edu in files sun-sl.shar and seismo-slip.shar (or
names very close to that.)
-mark

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 11:52:51 EDT
From:      minshall@OPAL.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: FIN_WAIT_2 problem ?

Chuck Johnson,

	If you have connections hanging in FIN_WAIT_2 and LAST_ACK
then there is a bug somewhere.  There was a bug in the 4.2 TCP
implementation (in tcp_input.c) which would cause connections to
hang in this state.  The fix, which is in the Mt. Xinu bug list
(among other places), involved repositioning a block of code
(though I can't remember which block where).

Greg Minshall

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 13:59:39 EDT
From:      pete@NCSC.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Virtual Disk


Does anyone out there know of a commercially available software
product that supports DEC VMS virtual disk over Ungermann-Bass
Net/One Ethernet?

-Pete-

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 14:09:05 EDT
From:      karn@FALINE.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re:  FIN_WAIT_2 problem ?

No! FIN_WAIT_2 state is supposed to be a "stable" state in TCP. That is, one
end of the connection may close while the other end may continue to send for
as long as it likes. In this situation, the end that closed first will be
in FIN_WAIT_2 state (assuming its FIN has been ACKed) and the other end will
be in CLOSE_WAIT state.

As for connections getting hung up in LAST_ACK state, this must be a bug
in the TCP implementation (I've noticed it myself on BSD machines). In that
state you are waiting for an ACK to your FIN; since there is "data" (the
FIN is considered to be data for sequence numbering and acknowledgement
purposes) the retransmission timer should be running.  Enough
unsuccessful attempts to get an ACK for the last FIN will eventually cause
TCP to go to the closed state -- if the TCP is working properly.  There
is no need to make incompatible changes to the protocol -- fix the bugs
instead!

Phil

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 15:53:00 EDT
From:      heker@JVNCA.CSC.ORG (Sergio Heker)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP


Thanks everybody.

-----------------------------------------------------------------------------
Sergio Heker				tel:	(609) 520-2000
ARPA:	"heker@jvnca.csc.org"		BITNET:	"heker@jvnc"
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER, JVNCnet Network Manager
-----------------------------------------------------------------------------

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 22:45:57 EDT
From:      JBVB@MX.LCS.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: sendmail problem

We ran into the same problem (4BSD sendmail defaults to terminating
SMTP 'lines of text' with <lf> only), and after spending more time than
we really liked explaining to people how to fix sendmail.cf, we
made our parser more generous.

jbvb

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16-Jun-87 22:49:20 EDT
From:      JBVB@MX.LCS.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   SLIP

FTP Software sells a SLIP implementation for the IBM PC under MS/DOS.  There
is also Rick Adams' public domain driver for Vax and Sun Unix (4.2 and Sun
1.0/2.0).  I have heard of it being used by Dave Mills' fuzzball gateways.

jbvb

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 00:06:07 EDT
From:      JBVB@MX.LCS.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Telnet binary mode


    All Telnet servers should have a command that a network user can issue
    that puts the network terminal in binary mode....

    All Telnet clients should have a command that a Telnet user can issue
    that puts the Telnet connection in binary mode....

I do not think this is the right approach.  In particular, given the
current state of the TN3270 world, there are a number of implementations
in the field that would automatically respond by switching to EBCDIC.
This is not sacred, but it is no more sacred than the tradition of
various clients and servers generating parity over Telnet.

What I want is RFC 854, with a clarification of the sentence:
"All remaining codes do not cause the NVT printer to take any action."

I would prefer a reading which guarantees that all 8-bit codes can be
transmitted over a Telnet connection without any negotiation (with
appropriate IAC stuffing and removal), but does not guarantee that
the receiver (client or server) will do anything in particular with
them.  As I see it, this allows a simple TT_TYPE negotiation (or manual
terminal-type control) to open up 8-bit extended functionality on a
case-by-case basis.  I feel this is appropriate, since there isn't any
universal interpretation of the codes above 128.

In most of the operating environments I know, a character can have 8
bits.  Here, implementing my recommendation is trivial.  The host software
has some mechanism for determining what sort of device to generate output
for, and if the user doesn't want to care what kind of terminal he is
using (or emulating), he should be using supdup anyway.  Automatically,
or manually, the terminal type is agreed upon, and if that implies 8-bit
I/O, so be it.  IAC stuffing continues, but no masking occurs, and the
8th bit is never set unintentionally.

In cases where the OS treats the sign bit as out-of-band data, masking is
required by default.  I don't know the history of the "rubout performance
problem", but I can see that a special call is needed for programs that
want only the masking disabled, without the other side effects of 'raw'.

Requiring 'binary' be negotiated before 8-bit data can be passed over the
connection smacks of the 'telnet-randomly-lose' option:  This uses 'binary'
to indicate "I am a conforming implementation, and I won't send you any
parity or the like".   This ought to be dealt with by fixing the offenders,
and leaving the user something like a "4BSD/RFC-959 switch" in an FTP
client, so he can request masking during the transition period.

The one widely-implemented use of 'binary' as of this date is as an
indication that "we are in EBCDIC now".  I submit that there is a
worthwhile distinction between "NVT ascii with possible extensions",
and "something completely different" (16-bit chars?), and that this
distinction ought to be preserved, whether by my proposal, or at least by
using 'option a' to differentiate between "NVT" and "extended NVT", and
'option b' for larger distinctions (TN3270).

jbvb
James B. VanBokkelen
FTP Software Inc..

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 00:16:56 EDT
From:      medin@ORION.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Recent AMES Internet outage


Something here at Ames happened recently and I thought it of enough worth that
I should bring it up here for some comments.  Last week we at Ames had a
MILNET PSN upgraded and moved to a new location.  We are now a standard 
configuration PSN site.  In the process of the move, the gateway on port 0
(ames-gw.arpa - also known as ames-viking.arpa) was removed from port 0.
That machine is a Vax, and the new facility is out of easy 1822DH 
range of that machine (we were replacing it with a dedicated gateway
anyways).  We had 2 other gateways up however and running EGP and 
advertising the local net to the Core.  We normally have 3 gateways
running (including viking), but 2 seemed to be quite adequate for
an interim configuration.  

After we brought up the 2 other gateways, we noticed that we couldn't
talk to the NIC.  At first we thought it was down, but later checks
proved it to be up.  We also noticed that we couldn't talk to certain
other sites.  All sites running EGP normally worked fine though (except
for certain UMD machines).  After some checking, it appeared to be
tracked down to those machines using a default route to some core 
gateway that issued a redirect to viking, and even though viking
was dead, still continued to use that route until the system was rebooted.
Thus, even though we had 2 gateways up and talking to the core, several
sites still couldn't talk to us, most notably the NIC.  It seems to
me that if you get a host dead message from the PSN that that
route should be deleted, and probably that all redirected routes
should be timed out after awhile.  I believe 4.3 BSD will delete
a route if TCP sees a connection starting to time out.  

Anyways, the fix was to accelerate the deployment of a dedicated gateway
on port 0, and after bringing up a Proteon p4200 there, we could
suddenly talk to everyone again (the NIC, brilling.umd.edu (where
laser-lovers mail comes from), etc...).  This certainly doesn't strike me
as a very robust system.  Granted EGP has it's problems, but at least
it doesn't suffer from this one...  Now all we need to do is to file
a TSR to get rid of ames-viking.arpa's affliation to PSN port 0 and
we're done...  Sigh.


						Thanks,
						  Milo

PS The old C30/E PSN was bought and paid for by NASA, and has a
NASA property sticker on it.  Since we have no further need for
it, we plan to surplus it eventually.  NASA paid over $70,000
for it some years ago, and if someone who wanted one would be willing
trade us some Sun's (or something similiar) for it we could probably
arrange something.  I normally wouldn't post a want-ad type of message
to the net, but since this is official U.S. Gov't business, it seemed
appropriate.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 02:22:21 EDT
From:      MRC@PANDA.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet binary mode

James -

     Your message leave me quite confused, and I am the author of several
different Telnet client and server programs as well as part of the Telnet
protocol (Logout and Supdup).

     I would assume that any user who issues a command to put the
connection into binary mode would know what the impact of that command will
be, and I would be quite irritated at a Telnet implementation that didn't
leave the choice up to me.  Perhaps in the IBM world Telnet binary mode is
used for EBCDIC, but binary mode sure as hell is used for a helluva lot of
other things than that!

     Telnet is a 7-bit protocol.  Binary is the only general means of
transmitting 8-bit data.  There are other means of transmitting specific
8-bit data (e.g. Supdup).  Binary should not be interpreted as having any
other semantics (e.g. Unix "raw" mode, TOPS-20 terminal binary mode,
EBCDIC).

     It is absolutely not trivial to implement your "recommendation"; there
are a whole slew of issues involved in 8-bit transmission, particularly
with regards to terminals which expect or use parity as opposed to
terminals which do not (or have user control of the 8th bit as in an "EDIT"
or "META" key).

     I for one will firmly resist any attempt to change the semantics of
the Telnet protocol.  EBCDIC is NOT, repeat, NOT the only user of Telnet
binary mode.  If EBCDIC is really getting extensive usage, then it should
be set up as its own option.  Binary mode should be used for EBCDIC only
between consenting hosts!!  I never heard of the TN3270 developers claiming
the right to take over existing protocol!

     There is an ISO recommendation for large character sets; it involves
14-bit characters limited to the characters between 21h and 3Eh (that is,
the printing ASCII characters).  All control characters and delete are
always interpreted as a single bit.  I'm most familiar with their usage in
Japanese kanji terminals; in those, an escape code is used to shift between
ASCII and 14-bits.  This could be a Telnet protocol option, but all
terminals use the same escape code so there doesn't seem to be much of a
point to doing so.

     You refer to the "Telnet Randomly-Lose Option", but do you know what
it was?  I know because I wrote it; it was an April Fool's Joke ten years
ago having to do with user control over system crashes.  It has nothing to
do with your discussion that I can tell.

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

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 10:14:59 EDT
From:      mac@idacrd.UUCP (Bob McGwier)
To:        comp.protocols.tcp-ip
Subject:   Re: NSC HyperchannelB - Ethernet TCP/IP gateway

in article <153@geocub.UUCP>, ief@geocub.UUCP (Didier Demigny ) says:
> 
> In our lab, we have a TCP/IP Ethernet network and a Network System Corp.
> HyperchannelB network. Thus we are naturally leaded to imagine a gateway
> between them : this gateway seems a rather difficult problem.
> 
> More precisely, people are interested in file transfer between their
> minicompiters and mainframes on Hyperchannel (IBM 3090 and Sperry 1100).
> 
> Has anybody tried to have something work, or does anybody know of some
> experience elsewhere ?
> 
> 	P.Garda

We use a sun3 as the gateway between the hyperchannel which talks to
our Cray's and the "rest of our world" on our ethernet.  We even have
NFS running on all.  This is meant as encouragement ONLY this software
will never leave the building.

Bob

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 11:04:11 EDT
From:      almoney@PSUGATE.PSU.EDU (Jeffery C Almoney)
To:        comp.protocols.tcp-ip
Subject:   Serial IP


Where can one get a copy of the code for the a PC running MS-DOS?  I am also 
interested in the RVD code.

Jeff Almoney
Penn State

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 11:46:15 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   Re:  FIN_WAIT_2 problem ?

I should reemphasize to people who would automatically clear FIN_WAIT_2
after some period of time that this will blow away RSH possibly.  RSH
will close one side of the conection (remember TCP sockets are full-duplex)
and hence waiting for small amounts of time (like 30 seconds) will zap
legitimate connections for commands that take longer than 30 seconds to
return their output.

-Ron

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 14:11:19 EDT
From:      woods@hao.UCAR.EDU (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   Re: NSC HyperchannelB - Ethernet TCP/IP gateway

In article <250@idacrd.UUCP> mac@idacrd.UUCP (Bob McGwier) writes:
>in article <153@geocub.UUCP>, ief@geocub.UUCP (Didier Demigny ) says:
>> 
>> In our lab, we have a TCP/IP Ethernet network and a Network System Corp.
>> HyperchannelB network. Thus we are naturally leaded to imagine a gateway
>> between them : this gateway seems a rather difficult problem.

  We have the same situation. I wrote a hyperchannel server that runs on
the gateway VAX 750 (attached to both Ethernet and hyperchannel) for non-
hyperchannel Ethernet machines to submit jobs to the CRAYs (on hyperchannel
only, of course). I created a local "ntwk" port (in /etc/services) and
the hyperchannel gateway server just listens on this port for a connection
in the same manner as any other TCP server and handles submitting the job to
the appropriate CRAY when it comes in. Such a server is not hard to write,
I'd be glad to send you mine if you think it would help (but it might be
easier to write your own; it was not written to be portable and does have
some site-dependent code in it). It turns out that the problem of what to
do with outputs coming back from the CRAY is a LOT harder. I had to modify
our local hyperchannel software to check each returned output file to see
if it belonged to a job that was submitted from an Ethernet host, and if
so, connect to yet another server running on the submitting host (also fairly
easy to write) and send the output across the Ethernet. The hyperchannel
changes were by far the hardest part of this and are COMPLETELY implementation
dependent and therefore useless to anyone else. However, a similar design
could probably be used for those wishing a similar capability.

>This is meant as encouragement ONLY this software
>will never leave the building.

  I'd be happy to mail you any of my software, it is public domain. However,
because it is implementation-dependent, it probably would be useful only
as a guide in designing your own.

--Greg
-- 
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17-Jun-87 18:48:58 EDT
From:      karn@JUPITER.BELLCORE.COM (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   COS goes with TCP/IP

This item appears on page 15 of the June 1987 issue of Data Communications.
It really made my day. Enjoy.

 --Phil

============================================

For Own In-House Network, COS Selects TCP/IP

That's right. The consortium of vendor and user heavyweights, the
Corporation for Open Systems (COS), which exists solely to accelerate the
development and deployment of products based on the Open Systems
Interconnection (OSI) specifications, confirms that its own in-house
computer network will use the renegade transmission control
protocol/internet protocol (TCP/IP) set, and not OSI transport and network
protocols, at least not initially. "I realize it may look bad, but we *do*
plan to migrate [to the OSI protocols]," says Steve Smith, a COS researcher.
COS expects its in-house network -- consisting largely of Unix-based Sun
Microsystem workstations, Unix-based file servers, and Ethernet connections
supplied by Bridge Communications -- to be up and running within the next
few weeks. Aware that charges are likely to fly that COS isn't practicing
what it preaches when it comes to implementing OSI, COS officials declined
further comment. It seems the decision to go with TCP/IP -- even though
several COS members, including IBM, Retix, and Touch Communications, for
example, now offer OSI network/transport-layer products -- was made
reluctantly, because the vendors whose gear COS researchers wanted (Sun,
Bridge) do not offer OSI connections.  There could, however, be another
reason for the interim acceptance of TCP/IP: COS is long overdue in setting
up a test facility for checking out OSI network/transport product
implementations and certifying their intercompatibility. And selecting an
OSI product for use in its own network, which has not passed COS's own
certification muster, might have been viewed as an even bigger political
gaffe than going with TCP/IP.

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 02:14:46 EDT
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet binary mode

Mark:  There is obviously some history I am not familiar with here.  I look
at the Telnet specification, and I see a perfectly good 8-bit transport.
I see global definitions for slightly more than half of the possible
characters.  I see a 'binary' option defined as 'escape to mutually
agreed-upon 8-bit datastream'.  I know of one fairly well-defined use
of 'binary' (TN3270, with 5 different server implementations and 6 or
7 clients).  You indicate there are other uses, but I have no details.
You cite your TOPS-20 implementations as examples of a manually-controllable
'binary' option.

My interest in this is to improve the real-world usability of the Telnet
protocol, and I realize I am  proposing a change.  I respect the interest
of the authors of the original documents (I was referring to them last night,
although I admit I hadn't been checking the authors' names).

The problem: there are a growing number of applications which wish to
exchange extended-ascii data with appropriate display terminals.  In every
case I am aware of, the application, the server O/S, the client O/S and
the display all understand 8-bit, and the terminal type information is
available to all components.

The obstacle: Telnet clients and servers universally mask off the 8th bit
of a received data stream, in spite of the sentence in the RFC which says
that codes above 128 will have no effect.  Why?  Because of a number of
clients and servers which take it upon themselves to generate parity
to send over the network (which appears a total waste of time, but maybe
I'm missing something?).  'Binary' mode was designed to solve the problem,
but few implementations handle it, and yours are the only ones I am
aware of where it is possible to get 'binary' without side effects.

Side issue: Serial-line Parity.  Are tty drivers that pass received parity
to applications programs common?  Are there many OSs where writing 8-bit
data to the tty driver confuses its output parity generation?  As long as
the answers to those questions are 'no', the presence of serial-line parity
seems to be reduced to another kind of terminal-type mismatch peculiar to
8-bit datastreams.

Solution 1: Require that all clients and servers negotiate 'binary' before
passing an 8-bit datastream.

 Advantages:	The feature need only be dealt with on specific systems
		that understand it.  Of course, the rest of the world
		must continue to mask the parity off, anyway...

 Disadvantages:	The user and/or the 8-bit application must request 8-bit
		mode, (presumably the user, manually), and the client
		and server programs both need hooks, and some more code.

		Any useful automatic operation (which you don't seem to like)
		requires 'binary' and 'xx', so extended ascii can be
		differentiated from 3270, etc.  TN3270 has this, although
		not all implementations conform completely.  TN3270 is
		already fully automatic in most implementations.  Do the
		other 'binary' dialects have similar behavior?

Solution 2: Require the elimination of implementations that generate
meaningless 8-bit, and allow clients and servers to pass all 8 bits
between the application and the tty driver by default.

 Advantages:	In the best case (possibly a PC client), implementation
		consists of removal of 1 line of code.  This is the case
		wherever the applications and the tty driver can take care
		of themselves (no more bothered by 8-bit than by random
		control characters).  If the OS can't hack it, then leave
		the existing masking code in, and write a hook to bypass it
		when requested by the application or user.

		Amenable to integration with automatic or semi-automatic
		terminal type selection, which can take place in the
		client and server OS, without hooks into the Telnet (which
		is likely to be a layered product, not always available
		from the OS vendor).  The 8-bit application is less likely to
		have to understand about networks, too.

Disadvantages:	Everybody needs the mask operation, and the hook to bypass
		it, until the parity-senders get upgraded.  Of course, by
		my reading, they're already in violation of the RFC.

		Requires issuance of new RFC and Mil-Std.

		Tinkers with something that's already working (except for
		people like the original poster).

Axe-to-grind: I want to provide better functionality so more people will
use TCP/IP and give me more money.  Better functionality is nothing without
interoperability, so I am motivated to push for what looks to me like the
solution that requires less work from the average developer or vendor.  I
recognize that you've already done your part of your solution, but your
posting implied that few others have done it (or done it right, anyway).

I wish to become better informed, in part because I am participating in the
effort to standardize 3270-mode.  I would like to know details of other uses
of 'binary' mode, and options used in conjunction with 'binary' mode.  I would
also like to hear other implementors' approaches to solving the original
poster's problem, and if I have misunderstood yours (request binary manually,
whereupon client and server do some checking, and agree upon it, and then
the user can start the 8-bit application), please clarify.

jbvb
James B. VanBokkelen
FTP Software Inc.

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 03:16:54 EDT
From:      melohn@SUN.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: COS goes with TCP/IP

In article <8706172248.AA21271@jupiter.bellcore.com> karn@JUPITER.BELLCORE.COM (Phil R. Karn) writes:
>This item appears on page 15 of the June 1987 issue of Data Communications.
>... It seems the decision to go with TCP/IP -- even though
>several COS members, including IBM, Retix, and Touch Communications, for
>example, now offer OSI network/transport-layer products -- was made
>reluctantly, because the vendors whose gear COS researchers wanted (Sun,
>Bridge) do not offer OSI connections.

The article is amusing, but grossly inaccurate, since Sun currently
has a broader offering of OSI products than IBM, Retix, or Touch. Even
so, with many protocols yet to be fully defined, OSI as it stands today
is not complete enough to replace a fully designed and implemented
family of protocols like TCP/IP.

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 03:36:17 EDT
From:      woods@hao.UCAR.EDU (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   socket states

For us beginners with TCP and sockets, and after reading the recent discussion
here about LAST_ACK and FIN_WAIT_2 states, I would be very interested (and
I suspect I'm not the only one) in reading an explanation of what the various
socket states are and exactly what they mean. I'm the site admin for a machine
that is very new on the Internet, and due to the cost difference, I've had
to shift from phone line uucp links to NNTP/SMTP internet links as much as
I can, which now accounts for 80+% of our traffic, but I still don't understand
how this stuff really works, nor is there any good information from a system
administrator's point of view on it (I'm NOT a kernel hacker).

--Greg
-- 
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 03:58:22 EDT
From:      MRC@PANDA.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet binary mode

James -

     There are several uses of Telnet binary mode, all of which
predate TN3270.  Here are some I can think of off the top of my
head, at half past midnight after a long long work day:
1) many terminals have an EDIT key which allows applying the high
   order bit to a character, and several display editors, most
   notably various implementations of EMACS, use this facility to
   have commands (e.g. CTRL/F means move forward character, but
   EDIT/F means move forward word) way up there.  At least two
   display editors, TVEDIT and E, are severely crippled without
   this facility.
2) some terminals have an 8-bit character set, most notably DEC
   VT220's, and there are a helluva lot of people who use the
   characters up there!
3) from time to time, many users want to transmit 8-bit data as
   part of a download or upload sequence, e.g. using the Kermit
   or Modem protocols running the Kermit/Modem server on a remote
   host.
4) from time to time, users want to run other 8-bit protocols
   such as UUCP over a Telnet link (don't laugh, in a US/Japan
   link I am quite familiar with two Unix systems mail to each
   other through a DEC-20, and two DEC-20's mail to each other
   through a Unix, for various ugly technical reasons I won't go
   into here).
5) from time to time, users want to experiment with enhanced
   protocols at a level above Telnet, and use Telnet as a base to
   support these protocols.  TN3270 probably had its start in
   this fashion.

     However!!  There are many terminals which generate (or
require) parity when dealing with a host.  A user who wants to
send 8-bit data over a Telnet link generally knows what he's
doing and can give a command (whether it's CTRL/^ T, TRANSPARENT,
@ B I S, or whatever is unimportant).  A user who has problems
with parity on his terminal generally doesn't know WHAT the hell
is going on!

     I don't know what you are talking about when you say "a
number of clients and servers which take it upon themselves to
generate parity to send over the network."  Parity is NOT sent
over the network.  That is what the whole point of requiring
7-bit ASCII in non-binary mode is all about!  If you put your
Telnet connection into binary mode, you're essentially saying
that you are NOT using parity on that direction(s) of the
connection, and that the high order bit is a meaningful data bit.

     Telnet binary mode has nothing whatsoever to do with any
host OS software concept of "binary."  Implementation that have
such a binding without the consent of the user are in error.
Telnet binary mode only impacts the transmission of 8-bit data.

     Let me also re-emphasize that you can do everything you want
in Telnet WITHOUT making incompatible changes to the existing
protocol or implementations.  All you have to do is define a new
option.  For example, you can add a TN3270 option.  Nothing in
the protocol says that binary mode is the *only* way to transmit
8-bit data.  Already there are two options, Supdup and Supdup
Output, which cause 8-bit I/O independently of binary mode.
Think of binary mode as "untyped 8-bit I/O" as opposed to
whatever other options you define as being "typed 8-bit I/O."
This also has the advantage of making damn sure both sides agree
to the interpretation of the I/O mode you are proposing.

     I suspect this conversation is boring a lot of people, so I
suggest it be taken off-line from TCP-IP unless people want to
hear it.

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

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jun 87 08:44:51 PDT
From:      braden@braden.isi.edu (Bob Braden)
To:        JBVB%MX.LCS.MIT.EDU@mc.lcs.mit.edu
Cc:        TCP-IP@sri-nic.arpa
Subject:   Re:  Telnet binary mode
	
	The one widely-implemented use of 'binary' as of this date is as an
	indication that "we are in EBCDIC now". 
	
Sorry, but I don't think this is true.  The one widely-implemented use of
binary is tn3278, which is NOT (I recall saying this, I think on this
same mailing list within the last 6 months!) repeat, NOT, EBCDIC.  It
is a structured glop containing bit fields and (yes) some character
strings encoded in EBCDIC.  But the only reasonable representation
is BINARY.

   Bob Braden
   	
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Thu 18 Jun 87 19:18:55-PDT
From:      Karl Auerbach <AUERBACH@CSL.SRI.COM>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   COS uses TCP
Since I'm sort of an ISO proponent, I guess that I can post this
without getting too much flak...

Did any of you notice the article "Practicing What It Preaches Is Aim
of Standards Group's LAN" on page C/7 (Connectivity section) of the
June 16 issue of PC Week?

For those of you who didn't, here are some excerpts:

     To implement the actual seven protocol layers COS [Corporation
     for Open Systems] is taking the approach it recommends to its
     members.  Since few products that implement upper-layer
     standards are available, COS is utilizing established ISO
     standards at the lower levels, with close approximations -- in
     this case, the TCP/IP protocol suite -- at the top.

     ...

     The interim approach that COS uses and recommends is the set of
     protocols used by the Department of Defense on its Defense Data
     Network (DDN), also called Arpanet.  The DDN employs the TCP/IP
     protocol suite.  TCP/IP most closely resembles the ISO standard,
     and is migrating toward it, Mr. Berkowitz said.  For example,
     the DDN internet protocol, used at layer 3 of the ISO model
     (network layer) is evolving toward the ISO 8473 standard, while
     the DDN transport protocol, TP 4 [sic], is moving toward the ISO
     8073 standard at the transport layer.

     Up at layers 5, 6, and 7, things get even more complex,
     according to Mr. Berkowitz.  Currently, COS is using the DDN's
     FTP (file transfer protocol), which covers all of these top
     layers.  ...

 --karl--
-------
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 16:25:45 EDT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   4.3bsd tcp code for Sun available

A port of the 4.3bsd tcp code to Sun OS v3.3 is available
for anonymous ftp from host lbl-rtsg.arpa as compressed
tar file 4.3tcp4sun.tar.Z (~ 50KB).  This code reflects
what Berkeley is presently running (as of June 6th) and
includes all the bug fixes and performance enhancements
made since the 4.3bsd release.

In limitted testing we have found that the 4.3 code improves
local net performance by about a factor of two over the
code that came with Sun v3.3.  E.g., throughput on an ftp
between two Sun 3/50s went from 100KByte/sec to 190KByte/sec.

Most of the post-distribution changes in 4.3 have had to do
with performance over congested links (like the Arpanet).
We expected, and observed, a large performance improvement
over the Sun (nee 4.2bsd) code.  Unfortunately we couldn't
quantify the change:  In six file transfer trials over
the Arpanet at midday, the 4.3 code delivered an average of
1.2KB/sec.  The original Sun code timed out without completing
a transfer on all six trials.  Thus, we are postulating an
infinite improvement.

The tarchive contains objects for a 68020.  Since the tcp
code is Berkeley's and not in any way derived from Sun's
code, all the source is included.  Note that this is only
the 4.3 tcp and doesn't include the 4.3 fixes made to ip,
icmp or udp (this 4.3 tcp does not depend on any of these
fixes and will run in a Sun v3.3 system as-is).  

  - Van

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 16:39:00 EDT
From:      roger@celtics.UUCP (Roger B.A. Klorese)
To:        comp.protocols.tcp-ip
Subject:   Re: Serial IP

Serial-line IP discipline (SLIPDISC) is standard on Celerity systems
beginning with release 3.4, to be shipped within two weeks.

-- 
 ///==\\   (No disclaimer - nobody's listening anyway.)
///        Roger B.A. Klorese, CELERITY (Northeast Area)
\\\        40 Speen St., Framingham, MA 01701  +1 617 872-1552
 \\\==//   celtics!roger@seismo.CSS.GOV - seismo!celtics!roger

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 18:31:28 EDT
From:      lamaster@pioneer.arpa (Hugh LaMaster)
To:        comp.protocols.tcp-ip
Subject:   Re: Tek terminal emulation on PC TCP/IP

In article <1736@ames.UUCP> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) 
writes:

>Does anyone know of any version of PC TCP/IP that includes a Tektronix
>4010/4014 terminal emulation version?  [The current version from ftp software
>seems to include only vt100 and tn3270, although in other respects I like
>their version.]
>
>[If anyone does know of one, what graphics boards and ethernet boards are
>supported?  Which combinations on which pc's?]
>

I have been able to find one source of TCP/IP Tektronix emulation.  The name
of the package is TNET.  The source is:

Grafpoint
1485 Saratoga Ave.
San Jose, CA 95129-4934
(408) 249-7951

The package is available in three versions: 4105, 4107, and 4115, which cost
$395, $995, and $1495.  As I understand it, it is based on ftp software pc-tcp.
It runs on an Interlan NI5010 ("preferably?") and also 3COM 3C501, and whatever
other boards are supported by ftp s/w (BICC??).  The sales literature does not
say if the complete set of pc-tcp software comes with it.

Many graphics boards are supported, including the standard IBM CGA and EGA
boards and compatibles, but also Adage, BNW, Ctrl Systems, Galagraph,
Imagraph, Matrox, Metheus, Microfield, Number Nine, Vermont Micro, Verticom,
Video-7, and others.

Has anyone had any experience with this product?  Previous experience with
pc-tcp on the Interlan NI5010 gives me confidence in the networking part.



  Hugh LaMaster, m/s 233-9,  UUCP {seismo,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

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 18:58:29 EDT
From:      lamaster@pioneer.arpa (Hugh LaMaster)
To:        comp.protocols.tcp-ip,comp.graphics
Subject:   Re: Tek terminal emulation on PC TCP/IP

In article <1736@ames.UUCP> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) 
writes:

>Does anyone know of any version of PC TCP/IP that includes a Tektronix
>4010/4014 terminal emulation version?  [The current version from ftp software
>seems to include only vt100 and tn3270, although in other respects I like
>their version.]
>
>[If anyone does know of one, what graphics boards and ethernet boards are
>supported?  Which combinations on which pc's?]
>

I have been able to find one source of TCP/IP Tektronix emulation.  The name
of the package is TNET.  The source is:

Grafpoint
1485 Saratoga Ave.
San Jose, CA 95129-4934
(408) 249-7951

The package is available in three versions: 4105, 4107, and 4115, which cost
$395, $995, and $1495.  As I understand it, it is based on ftp software pc-tcp.
It runs on an Interlan NI5010 ("preferably?") and also 3COM 3C501, and whatever
other boards are supported by ftp s/w (BICC??).  The sales literature does not
say if the complete set of pc-tcp software comes with it.

Many graphics boards are supported, including the standard IBM CGA and EGA
boards and compatibles, but also Adage, BNW, Ctrl Systems, Galagraph,
Imagraph, Matrox, Metheus, Microfield, Number Nine, Vermont Micro, Verticom,
Video-7, and others.

Has anyone had any experience with this product?  Previous experience with
pc-tcp on the Interlan NI5010 gives me confidence in the networking part.



  Hugh LaMaster, m/s 233-9,  UUCP {seismo,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

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")



  Hugh LaMaster, m/s 233-9,  UUCP {seismo,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

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 21:05:47 EDT
From:      ROODE@BIONET-20.ARPA (David Roode)
To:        comp.protocols.tcp-ip
Subject:   relay problems

When we get mail from JANET sites that is relayed via BITNET, using
your host UKACRL.BITNET, reaching us on the Internet, we get a routing
through a pseudo host known as AC.UK .  This is not a valid Internet
host.  People have difficulty replying, and we have to tell them how
to compose a routing style of message.  However, when the JANET mail
flows through CS.UCL.AC.UK, we have no problem.

Questions:

What determines which type of routing a JANET host uses to reach U.S.
Internet hosts?  Which type of routing is the best use of resources?

Is AC.UK a valid BITNET hostname?  If so, we would recognize it as
such and route appropriately if it displayed as AC.UK.BITNET or
AC.UK.EARN .   This would not solve the problem for other
Internet hosts getting relayed messages from WISCVM.WISC.EDU
though.

The best thing would be if AC.UK were a valid Internet host name.
Many Internet domains register the domain itself as the name
of a host.  It seems like CS.UCL.AC.UK could be pointed to by
AC.UK, registered as a nickname.  This would be accomplished
by a CNAME record in the domain system and a listing in the NIC
host table.
know t'r

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18-Jun-87 22:18:55 EDT
From:      AUERBACH@CSL.SRI.COM (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   COS uses TCP

Since I'm sort of an ISO proponent, I guess that I can post this
without getting too much flak...

Did any of you notice the article "Practicing What It Preaches Is Aim
of Standards Group's LAN" on page C/7 (Connectivity section) of the
June 16 issue of PC Week?

For those of you who didn't, here are some excerpts:

     To implement the actual seven protocol layers COS [Corporation
     for Open Systems] is taking the approach it recommends to its
     members.  Since few products that implement upper-layer
     standards are available, COS is utilizing established ISO
     standards at the lower levels, with close approximations -- in
     this case, the TCP/IP protocol suite -- at the top.

     ...

     The interim approach that COS uses and recommends is the set of
     protocols used by the Department of Defense on its Defense Data
     Network (DDN), also called Arpanet.  The DDN employs the TCP/IP
     protocol suite.  TCP/IP most closely resembles the ISO standard,
     and is migrating toward it, Mr. Berkowitz said.  For example,
     the DDN internet protocol, used at layer 3 of the ISO model
     (network layer) is evolving toward the ISO 8473 standard, while
     the DDN transport protocol, TP 4 [sic], is moving toward the ISO
     8073 standard at the transport layer.

     Up at layers 5, 6, and 7, things get even more complex,
     according to Mr. Berkowitz.  Currently, COS is using the DDN's
     FTP (file transfer protocol), which covers all of these top
     layers.  ...

 --karl--
-------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 02:14:42 EDT
From:      rms@ACC-SB-UNIX.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Say What?

The EUREKA! award for this month should go to COS (Corporation for
Open Systems) for choosing TCP/IP as their internal networking
protocols.  An appropriate prize might be a complimentary copy of
the TCP/IP Vendors Guide which lists hundreds of off-the-shelf
TCP/IP products.  Hats off to COS!

Ron Stoughton

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 13:39:00 EDT
From:      braden@BRADEN.ISI.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: A fuzzy proposal


Dave Mills,

This is a delayed reply to your "fuzzy proposal" for a way to represent
in HOSTS.TXT the Fuzzballs and other gateways which follow the
gateway-half model. We too have been grappling with this problem, in the
process of gathering a database specifying the connectivity of NSFnet. We
have arrived at a scheme which differs from yours.

We think that your scheme does not make the topology readily
apparent. Consider your example:  
    
        GATEWAY : 35.1.1.1, 192.5.8.* : UMICH1
        GATEWAY : 192.5.8.6, 35.*.*.* : SWAMPRAT 

Now, it may be possible to infer from this pair of entries that UMICH1 is
connected to SWAMPRAT.  One can construct more complex cases where this
is ambiguous. For example, suppose we have two parallel connections:
    
        GATEWAY : 35.1.1.1, 192.5.8.* : UMICH1
        GATEWAY : 192,5,8,6, 35.*.*.* : SWAMPRAT1 
        GATEWAY : 35.1.1.1, 192.5.8.* : UMICH2
        GATEWAY : 192.5.8.6, 35.*.*.* : SWAMPRAT2 
        
Which one is connected to which? Another example, with two serial
lines from UMICH1 to two different gateway-halves on 192.5.8, might
be:
    
        GATEWAY : 35.1.1.1, 192.5.8.*, 192.5.8.* : UMICH1
        GATEWAY : 192.5.8.6, 35.*.*.* : SWAMPRAT1 
        GATEWAY : 192.5.8.6, 35.*.*.* : SWAMPRAT2 

We suggest that the primary purpose for the databases like the NIC
HOSTS.TXT is to show how things are connected together; derivation
of routing rules would be a secondary activity.  Your scheme, which
is based on routing rules rather than actual connectivity, may
hide what we most want to be explicit. 

The scheme which we adopted is to use symbolic interface addresses for
the un-numbered serial lines between gateway-halves.  Specifically, we
chose names of the form:

    <Network name>-<GWhalf 1>-<GWhalf 2>
    
between two gateway halves with names <GWhalf 1> and <GWhalf 2>. For
consistency, the two GWhalf names are always written in alphabetical
order.  We believe, by the way, that for consistency every network ought
to have both a name and a number assigned, even if the number is never
explicitly used because the network is comprised of half gateways
connected with serial lines.  In the absence of a network name, you
may think of the first component as an Autonomous System name.

For example, we might list your first example as:

    GATEWAY: 35.1.1.1, SWAMP-SWAMPRAT-UMICH1 : UMICH1
    GATEWAY:  192.5.8.6, SWAMP-SWAMPRAT-UMICH1 : SWAMPRAT
  
    
Suppose one tries to draw a network map based on your entries, without
doing the implied telescoping of entries; one ends up with a
set of two one-way connections between each network pair.  For
example:

                                                          -------
   -------          |----------------------------------->(       )
  (       )      --------                  --------      ( net   )
  (  net  )<----| umich1 |                |swamprat|---->(192.5.8)
  (  35   )      --------                  --------      (       )
  (       )<----------------------------------|           -------
   -------          


Using our symbolic names, one gets directly the correct topology,
without any telescoping:

   ------- 
  (       )     --------    
  ( net 35)<---| umich1 |
  (       )     -------- 
   -------         |       -------
                   |----> ( SWAMP )  <----|             -------
                           --------       |            (       )
                                        ---------      ( net   )
                                       | swamprat|---->(192.5.8)
                                        ---------      (       )
                                                        -------


In short, HOSTS.TXT is one of the main sources of information on network
configuration that is generally available, and we would like to see it
contain clear connectivity information on the fuzzballs and any other
gateway-halves.
   
By the way, your discussion of the use of the notation for hiding the
internal structure of an autonmous system should not be relevant to
databases such as HOSTS.TXT.  We want this to contain as much information
as possible, not to hide information.

Neither scheme, yours or ours, seems quite right. Maybe we are solving
the wrong problem?
  
    Bob Braden
    Annette DeSchon

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 15:02:34 EDT
From:      David.Waitzman@GALLEY.ECE.CMU.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Telnet Subnegotiations

Hi,

	Does anyone know of a telnet implementation available through the
arpanet that uses the NAOP or NAOL options (page length or line width,
numbers 9 and 8)?  I just added support to CMU-ECE's telnet and telnetd for
this, to handle adjusting to different screen sizes in X under 4.3, and
would like to talk to another implementation for testing.

	Please send responses directly to me.
						thanx,
						-david

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 16:00:42 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  A fuzzy proposal

Bob and Annette,

Thanks for your thoughtful reply. There are merits in your scheme that
would indeed by appropriate in some cases; however, I have reservations.
First, your suggestion on using synthetic meta-entities (!?) would
be appropriate for the half-gateway model, where the halves are separated
by a featureless transmission line or tunnel. I have no problem with that
and would support your suggestion over mine when such is the case.

My problem is the more general one. In addition to the cases I presented,
consider one even more bizarre. In some of the NSFNET swamps there are
multi-homed fuzzballs which respond to both local-net and ARPANET (!)
addresses. It's all done with logical tunneling, which is possible
because the routing algorithm can be configured for arbitrary address
ranges. Thus, in point of real fact, udel1.udel.edu appears as directly
connected to nets 128.4, 192.5.39 and 10. If I indicate the real truth
HOSTS.TXT would be cluttered up with a lot of confusing and strange
entries which, even if looking straightforward, would be actual lies.

Returning to our example case with linkabit-gw and swamprat, which may
be less controversial and move common than the above, I don't see how
the connectivity could be accurately recorded with your scheme unless
every intervening local-net node were recorded. In my last example I
wanted to hide the internals of the swamp, but offered to take responsibility
for the delivery of traffic to three nets, some of which are also connected
via other gateways. You take exception on the basis that HOSTS.TXT should
accurately reflect physical connectivity, not necessarily logical
connectivity.

I take the strongest objection. If in my autonomous system I refuse to
publish every detail that, in my opinion, policy or prescriptive fiat
is private and not to be revealed, then thus it verily be so. There is
a whole lot of precedent in this policy, not only in the common-carrier
community, but in many places in the Internet community as well. If the
price to be paid to carry third-party traffic between two POPs is to
reveal all the switches in between, then HOSTS.TXT is wholly inadequate
and inappropriate.

I submit there is room for both your scheme and mine. As you see, it is
not possible for me to accurately reflect the connectivity of the cases
I submit in either the existing HOSTS.TXT or your scheme.

Dave

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 17:00:13 EDT
From:      smith@cos.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: COS goes with TCP/IP


Phil - 

Thanks for posting the Data Communications article.  I got a good
laugh out of it.

As the "COS researcher" quoted in the article, perhaps I should
respond.  For starters, the "quote" is, in fact, a rather clumsy
paraphrase.  In general, the author of the article seems to be more
concerned with being clever than with getting his facts right.
("renegade transmission control protocol/internet protocol (TCP/IP)
set", forsooth!)  He is right that we are using TCP/IP now.  A
"political gaffe"?  No.

The key fact, which I think most everybody will agree on, is that if
you want something *now*, you have to go with what you can get *now*.
There's *always* something better due out in six months.  Right *now*,
you can buy off the shelf TCP/IP products from a large number of
vendors that usually work together most of the time.  The fact that a
few vendors have "OSI transport/internet" products is a good start,
but you can't make a network with two layers.  Without all seven
layers, you simply don't have an OSI network.

Within a year, however, you will be seeing a large number of *real*
OSI products (not "conformant with OSI model" or "IEEE 802.3/Ethernet
compatible" but full seven layer OSI) appearing.  There are also a
couple of "full OSI" products available *now*.  (Sorry, guys, no free
advertising.)

A couple of other items.  This is being posted through the COS
internal network, which has been running for a couple of weeks now
(not "within the next few weeks").  COS officials didn't "decline
further comment", they weren't asked.  It seems that the reporter
wasn't listening too well to my discussion on migration strategies.
Our internal network is designed for the easiest possible migration,
as soon as the appropriate OSI software is available.

Ah, well.  Such is journalism, especially when the reporter is feeling
sarcastic.

                        -- Steve
                           smith@cos.com

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 19:42:34 EDT
From:      schoff@NIC.NYSER.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: COS goes with TCP/IP

>...OSI protocols...
>not complete enough to replace a fully designed and implemnted
>family of protocols like TCP/IP.

AND whose velocity AND acceleration despite all 9 of those pregnant
women trying to do the job in one month is LESS than the INTERNET
"experienced mother".

Marty

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19-Jun-87 19:57:16 EDT
From:      Rudy.Nedved@H.CS.CMU.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet binary mode

James,

There are enough popular programs that assume the top bit is off that by
assuming otherwise will put you in trouble. On the other hand, if you can
write off those people or can get the software "fixed" then you win.

CMU CS/RI cheats and uses the 8-bit. We have been yelled at several times but
because the people involved are using wimpy IBM PCs, we win since we do not
care about PCs (and the software people use is locally distributed with CMU
mods). We have lost in our situations where the specification did not
define who was right and who was wrong...and making the world continue to
work was a higher priority then cleaner and faster local functionality.

However there are lots of PCs out there and they do not hang off of a network
like CMU, Stanford or MIT's. Therefore, if you go the way you are doing...you
will find lots of unhappy people....these are the people that recomend your
software (and they hate changing software that seems to work so changing the
spec in retrospec is not going to get the software fixed).

The result is still the same as what Mark Crispin says. You should have a
command that gives them the option of a full 8-bit connection and then you
allow them to have a work-around. People will complain that it is not
automatic....but they can still get their work done and your customer service
people can actually still give them an answer. If you force binary on the
sly....well, you will hit implementations that also do weird binary action on
the sly....different then yours....and you can not complain since you are
wrong too (and they will undoubtedly have the same type of arguments as
you since the speicfication in the long term was a design judgement).

All and all the end is still the same, the TOPS-20 implementation is the best
one around (in terms of correctness, I will argue about performance) and you
can not change the specificatiion....too many installed bases of software that
obey it close enough. You should use the TOPS-20 telnet server as part of your
certification process...and you should provide work arounds for the clients
who are talking to systems that are not quite on the ball.

-Rudy

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20-Jun-87 11:12:25 EDT
From:      mel1@houxa.UUCP (M.HAAS)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Higher speed LANs ?

Is anyone working on higher speed LANs?  We have lots of conversation
here on ISO, TCP/IP, and ISO vs. TCP/IP, but they all seem to be
content with the same old (what, 12 years now?) speed.  Ethernet at
10Meg, twisted pair stuff at 1 or 2Meg, fiber backbones at 80 and
100Meg.  But, disk to disk rates are still down at 20K to 100K bytes
per second.

What are the issues that keep us down at such low rates?  The disks
themselves are now in the 500K to 2Meg bytes per second range. 
Backplanes and memory are up in that range.  Certainly, interface
logic can go that fast (it does to disks, why can't it to LANs?).

In theory one can stuff bits down an Ethernet at 1,500K bytes per
second.  Why is it such a struggle to get 200K bytes per second
onto it?

It seems to me that diskless workstations, bitmapped terminals with
windows, cartograpy, medical and satellite image processing, weather
map transmission, video/music/speech processing, and lots of other
applications need high speed transfer of individual files.  Rather,
than the large number of users sending small items of data that the
current LANs handle so nicely.

Are there fundamental problems with TCP/IP that limit its application
to higher speed use?  Are the new ISO protocols better for high speed
file transfer?  Or, is the problem in the operating systems or
interface to the computer bus?  Can the high speed backbone fiber
networks be made to handle individual computer to computer or
computer to terminal traffic?  Or, it there some fundamental issue
that keeps them in the LAN to LAN bridging application?

I know that there are propritary protocols and links that go much
faster, but is it necessary to throw out the standards and ability
to internet and use diverse equipment and applications to get the
higher speed?

   Mel Haas  ,  odyssey!mel

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20-Jun-87 16:15:50 EDT
From:      bzs@BU-CS.BU.EDU (Barry Shein)
To:        comp.protocols.tcp-ip
Subject:   socket states


>For us beginners with TCP and sockets, and after reading the recent discussion
>here about LAST_ACK and FIN_WAIT_2 states, I would be very interested (and
>I suspect I'm not the only one) in reading an explanation of what the various
>socket states are and exactly what they mean. I'm the site admin for a machine
>that is very new on the Internet, and due to the cost difference, I've had
>to shift from phone line uucp links to NNTP/SMTP internet links as much as
>I can, which now accounts for 80+% of our traffic, but I still don't understand
>how this stuff really works, nor is there any good information from a system
>administrator's point of view on it (I'm NOT a kernel hacker).
>
>--Greg

Every symbol you see in netstat output (state) from Unix corresponds
exactly to a box in the diagram on page 23 of RFC-793 (Transmission
Control Protocol), same names etc, should be an AHA! when you look
at it.

Although the state diagram is a tad forbidding a few minutes study
should reveal that it is all actually quite clear and provides good
insight into such arcanum.

	-Barry Shein, Boston Universityt

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 87 03:57:22 GMT
From:      hao!woods@husc6.harvard.edu  (Greg Woods)
To:        tcp-ip@sri-nic.arpa
Subject:   Socket States and RFC-793

  In response to my request for an explanation of socket states,
several people have sent me mail suggesting that I check out
RFC-793, and one recommended a place I could send for such
information for $150.00. Well, I don't happen to have a spare
$150.00 right now, so is there any place one can go to get a
copy or even just a look at this exalted document? :-)

--Greg
-- 
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21-Jun-87 13:04:11 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  SLIP

James,

Not quite. The fuzzballs have their own SLIP driver, which is integrated with
the routing system. It's written in (hush) assembly code for the PDP11. These
animals do not C a lot and Unix not at all.

Dave

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21-Jun-87 14:47:26 EDT
From:      Liebschutz@BIONET-20.ARPA (Rob Liebschutz)
To:        comp.protocols.tcp-ip
Subject:   Re: Socket States and RFC-793

You can retrieve the file "rfc:rfc793.txt" via anonymous ftp from
internet host SRI-NIC.ARPA.  "rfc:rfc-index.txt" is an index of all
rfc's.  There is also a "netinfo:" directory with some potentially
useful documentation.

Rob
-------

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21-Jun-87 22:20:45 EDT
From:      root@TOPAZ.RUTGERS.EDU (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Arpanet EGP peers

Several weeks ago, there was an official DDN management bulletin
assigning everybody new core gateways to talk to.  At the time, I
thought we were supposed to change our EGP peer to be the gateways
mentioned there.  I have tried doing this, but neither of the gateways
mentioned in the message will respond to attempts to acquire them.
Just for reference, the ones we were assigned were 10.7.0.20
(dcec-milnet-gw) and 10.2.0.80 (sac-milnet-gw).  The ones we are using
now are 10.7.0.63 (bbn-net2-gateway) and 10.2.0.37 (purdue-cs-gw).  Am
I misinterpreting the request somehow?

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1987 07:25-PDT
From:      STJOHNS@SRI-NIC.ARPA
To:        root@TOPAZ.RUTGERS.EDU
Cc:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: Arpanet EGP peers
Yep!   Charles, the list that came out in the Management bulletin
was just the primary and secondary mailbridges you were  assigned
to.   Your  EGP  peers don't chane.  The LSI 11s don't even speak
EGP (err...  the 7 mail bridge LSIs don't at least, the rest  may
by now.)

Mike
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 05:47:41 EDT
From:      sjl@eagle.ukc.ac.uk (S.J.Leviseur)
To:        comp.protocols.tcp-ip
Subject:   Re: relay problems

Summary:

Expires:

Sender:

Followup-To:


In article <12311604935.33.ROODE@BIONET-20.ARPA> ROODE@BIONET-20.ARPA (David Roode) writes:
>When we get mail from JANET sites that is relayed via BITNET, using
>your host UKACRL.BITNET, reaching us on the Internet, we get a routing
>through a pseudo host known as AC.UK .  This is not a valid Internet
>host.  People have difficulty replying, and we have to tell them how
>to compose a routing style of message.  However, when the JANET mail
>flows through CS.UCL.AC.UK, we have no problem.
>
>Questions:
>
>What determines which type of routing a JANET host uses to reach U.S.
>Internet hosts?  Which type of routing is the best use of resources?

There are three main routes to the U.S. Internet; via CS.UCL.AC.UK
directly onto the Internet, via UKC.AC.UK/UKC.UUCP onto UUCP and then
onto the Internet, and via UKACRL.BITNET/AC.UK/EARN.RL.AC.UK onto
BITNET/EARN and then onto the Internet.

The UKACRL (which we see as EARN.RL.AC.UK) route is the only one which
is unrestricted and free for academic sites (thank you IBM). The U.K.
site needs to be registered to use either of the other routes. To
register they must have a valid reason to use the route in the case of
UCL, or be prepared to pay to use the route to cover the transport
costs in the case of UKC. 

>
>Is AC.UK a valid BITNET hostname?  If so, we would recognize it as
>such and route appropriately if it displayed as AC.UK.BITNET or
>AC.UK.EARN .   This would not solve the problem for other
>Internet hosts getting relayed messages from WISCVM.WISC.EDU
>though.
>
>The best thing would be if AC.UK were a valid Internet host name.
>Many Internet domains register the domain itself as the name
>of a host.  It seems like CS.UCL.AC.UK could be pointed to by
>AC.UK, registered as a nickname.  This would be accomplished
>by a CNAME record in the domain system and a listing in the NIC
>host table.

I don't think UCL would be keen on this, UKACRL is not UCL it is
an IBM machine at Rutherford Labs at Didcot, EARN.RL.AC.UK. If it
was pointed at UCL they would have to find the money to pay for
all the BITNET traffic. It doesn't seem to be generally appreciated
just how expensive it is to receive mail from the U.S.!

>-------

	sean

	postmaster@ukc.ac.uk
	postmaster@ukc.uucp

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 07:52:37 EDT
From:      geoff@eagle_snax.UUCP ( R.H. coast near the top)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

In article <8706121831.AA05760@saturn.mitre.org>, lazear@GATEWAY.MITRE.ORG writes:
> Geoff,
> 	I am surprised nobody has mentioned the issue of how does
> someone off-net ever address anything to the PC-host?  There has
> been no notion of updating a name server to be able to tell remote
> systems the PC's address (what if the remote system caches it?).
> I think this impacts the duration of the IP/PC binding, since re-
> using an IP address means former associations are now void implicitly.

Quite apart from the (not unreasonable) idea of off-net nodes
addressing the PC, an off-net server system may well need to map the
client PC's IP address into a hostname or vice versa. For example, the Sun
NFS mount daemon performs a consistency check on the mount request
by taking the hostname passed in the RPC arguments, doing a 'gethostbyname'
on it, and verifying that the RPC did indeed originate from that
address. It can then confidently use the name to check the 'netgroups'
access control list. As you say, a completely dynamic address assignment
scheme would require that the name-address mapping be propagated to all
servers which might have cached a previous mapping.

> ....  Perhaps the mainframe (as
> I characterize non-PC hosts) has no need to contact the PC or try to
> deliver datagrams to it until the PC comes up and announces itself?
> 	Walt Lazear

As I've indicated, I think this is unduly restrictive. But again, it
all depends which problem you're trying to solve: sharing scarce
resources (IP addresses) or making the installation of network
nodes simpler and less error-prone.
-- 
"You want a disclaimer form? Next window, please..."

Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!garnold  ARPA: garnold@sun.com

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 10:16:00 EDT
From:      Mills@BCO-MULTICS.ARPA
To:        comp.protocols.tcp-ip
Subject:   socket states


          The state diagram on page 23 of RFC793 is a good thing to look
at.  The version of the RFC in the new white DDN Protocol Handbooks
(page 2-207) has an error in it.  The arrow going from the SYN SENT box
to the SYN RCVD box should be labeled rcv SYN/ snd ACK,SYN.  I was
disappointed that this correction was not in the white books since I
discussed this with Jon Postel over a year ago.  I don't know if the
online version of RFC793 has been corrected or not.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 10:25:00 EDT
From:      STJOHNS@SRI-NIC.ARPA
To:        comp.protocols.tcp-ip
Subject:   Re: Arpanet EGP peers

Yep!   Charles, the list that came out in the Management bulletin
was just the primary and secondary mailbridges you were  assigned
to.   Your  EGP  peers don't chane.  The LSI 11s don't even speak
EGP (err...  the 7 mail bridge LSIs don't at least, the rest  may
by now.)

Mike

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 12:25:58 EDT
From:      pdb@sei.cmu.edu (Patrick Barron)
To:        comp.protocols.tcp-ip
Subject:   Re: Arpanet EGP peers


You're misinterpreting.  The DDN Management Bulletin in question was an
updated list of ARPANET and MILNET Mailbridge homings.  (Mailbridges are
the gateways that transfer traffic between the ARPANET and MILNET).
Mailbridges have nothing to do with EGP, so you should continue to use
the same EGP peers you were using.

--Pat.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 17:27:10 EDT
From:      mailer-daemon@MITRE.ARPA
To:        comp.protocols.tcp-ip
Subject:   Returned mail: Host unknown


   ----- Transcript of session follows -----
550 sri-nic.tcp... 550 Host unknown
550 tcp-ip@sri-nic... Host unknown

   ----- Unsent message follows -----
Received: by mitre.arpa (5.54/4.7)
	id AA02536; Mon, 22 Jun 87 17:08:34 EDT
To: tcp-ip@sri-nic
Cc: ramsay@mitre.arpa
Subject: Request for Information.
Date: Mon, 22 Jun 87 17:08:32 EDT
From: ramsay

MITRE is seeking a product to support remote access by 1 to 16 terminals to
an Ethernet LAN and through the LAN to a VAX host running VAX/VMS.  The 
protocols to be supported include TELNET/FTP, TCP, and IP, with terminal
rates of 1200 to 9600 bps.  Need basic technical data and POC for follow-up.
Understand that Communications Machinery Corporation (CMC) has a suitable
device, the CMC serial bridge terminal server; this option is being
investigated presently.  Are there are users of this device out there who
can advise of its reliability, performance, and general goodness?  MITRE
POC Andrew K. Ramsay, comm tel (703) 556-3082, ramsay@mitre.arpa

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 18:00:23 EDT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re: Automatic IP address assignment

I think a lot of the discussion on this is not relevant to the original
request.  People are trying to solve the problems that arise when a
host wants to move around to various networks and "plug in" and just
work.  That's not what was asked for, as far as I recall.

The problem is how to take a new machine and get it on the net.  Not
move it around, just get it on the net in ONE place.  This should not
require superusers to mumble incantations to files in obscure places;
it should not require sending email to Jon Postel; ideally you should
plug in e.g. a diskless workstation and it should tell the net it wants
to boot.  If it is an unknown host, some friendly local site can assign
it a temporary internet address (via a name server with online update),
tell it its address, and offer to boot it with an initialization
program.  This program would display a pretty picture on the screen
(Thanks for buying me, see how easy I am to operate!) and ask what
hostname, username, and password you want, and which file server if
there are several.  These would update the appropriate entries in the
name server database, the system would boot, and you'd be up and
running without following 50 pages of detailed directions in an obscure
manual.

The original question from SunEast seemed to be for the PC world,
so you can substitute "dumb host with generic software on a floppy"
for "diskless workstation" if you like.

I have never understood why we on Unix and/or the Internet seem
content to administer things with humans editing ASCII files and then
converting them to database format with little utility programs, while
commercial systems have been able to apply hundreds of transactions a
second to big online databases for many years.

So to get back to [what I think is] the question, are there any defined
protocols for assigning a new Internet address for a new machine ONLINE
and in REAL TIME?  Note that the boot ROMs (running RARP or BOOTP or
whatever) would not do this; the SERVER which is talking to the new
machine would use this protocol to assign the new address.
-- 
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu
Kudos to Stargate for permitting redistribution.   May the Source be with you!

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 18:23:24 EDT
From:      pzl@hjuxa.UUCP (Mr. Rem)
To:        comp.protocols.tcp-ip
Subject:   needed: good reference on tcp-ip



Could anyone out there refer me to a good source
of documentation on the definition and
implementations on tcp-ip?
I'm interested on documentation written for an
experienced c programmer/ systems person
who wants to get a solid grasp on tcp-ip.
Please mail me, and I will post the replies
id requested.

Thanks in advance.
-- 
--------------------------------------------------------
|Mr. Rem.
|{anywhere}!{clyde,cuuxb,decvax,ihnp4}!hjuxa!pzl
--------------------------------------------------------

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 18:35:51 EDT
From:      nowicki@SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.3bsd tcp code for Sun available

One clarification: the current release of Sun's Operating System, 3.4,
already has TCP code that is based on the 4.3BSD release.  Many people
might want to just get the latest supported release instead of rolling
their own.  SunOS 3.4 also includes ICMP enhancements from 4.3BSD.

On the other hand, Van has done some very good work on the analysis and
tuning of TCP.  At last, some real measured improvements!  Thanks.

        Bill Nowicki
        Sun Micairciscoc.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22-Jun-87 19:36:05 EDT
From:      BUDDENBERGRA@A.ISI.EDU (Rex Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   RFC on network management

Gentlemen,
  Back around March, I seem to remember someone promising an RFC on
network management.  I also remember that it was supposed to
carry a number just under 1000, like 998.  I now need to get my
hands on said RFC and can't find it.  Does it exist?  Anybody
working on it?
  Thanks
Rex Buddenberg
-------

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1987 19:36:05 EDT
From:      Rex Buddenberg <BUDDENBERGRA@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Cc:        BUDDENBERGRA@A.ISI.EDU
Subject:   RFC on network management
Gentlemen,
  Back around March, I seem to remember someone promising an RFC on
network management.  I also remember that it was supposed to
carry a number just under 1000, like 998.  I now need to get my
hands on said RFC and can't find it.  Does it exist?  Anybody
working on it?
  Thanks
Rex Buddenberg
-------
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 87 16:51:02 GMT
From:      hao!woods@husc6.harvard.edu  (Greg Woods)
To:        tcp-ip@sri-nic.arpa
Subject:   Re: Socket States and RFC-793
Thanks to the two dozen or so people who told me that I can FTP the RFC
documents, including 793, from sri-nic.arpa, and to the person who mailed
me the entire thing (thanks, Guy). That was the answer I was looking for.
I hope that by reading through this thing, I can have some of my socket
questions answered.

--Greg
-- 
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet  ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edu
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 01:39:07 EDT
From:      ROODE@BIONET-20.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Domain RFC Draft

You bring up an issue implicitly: Can not a domain be registered
multiply?  Even if you are later forced by policy to use the domain
nprdc.navy.mil, couldn't you easily convert the domain nprdc.mil by
maintaining it in parallel for a time as an identical domain?  In
other words, couldn't you go ahead without fear of penalty, knowing
that you will be able to convert at a later date if need be?
-------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 02:18:45 EDT
From:      yossie@nsta.UUCP (Yossie Silverman )
To:        comp.protocols.tcp-ip
Subject:   KNET programming techniques

I am trying to write a RWHOD server for VM using the KNET K-Routines.  I have
run into the following problem:

  I seem to receive IP-broadcasts (is that the correct term?  My knowledge in
TCP-IP terminology is somewhat limited) without any difficulty but when I try
to send packets the KNET VM ignores them or sends them out as non-broadcast
packets.

  My question is:  Does anyone have experience with the KNET K-routines and
is willing to help a beginner?  

  Please reply by mail and I will summarize to the net if necessary.

I have no fancy .signature file but I can safely state that no one here takes
me seriously so I can say what I wish without consequence.  

- Yossie

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 03:18:39 EDT
From:      vns@mhres.UUCP (Gertjan Vinkesteyn)
To:        comp.protocols.tcp-ip
Subject:   Re: NSC HyperchannelB - Ethernet TCP/IP gateway

In article <8706141434.aa06229@SEM.BRL.ARPA>, dpk@BRL.ARPA (Doug Kingston) writes:
> I know of no gateway that one can plug in and run between
> a TCP/IP network and a Hyperchannel.  If you can obtain
> TCP/IP for the IBM and/or the Sperry (they do exist), then
> you could make one minicomputer a gateway by giving it an
> interface on both the Hyperchannel and the other TCP/IP
> networks.....


Convex has TCP/IP and Hyperchannel, as well as DECNET
in their machines.
-- 
Real-Name: Gertjan Vinkesteyn
UUCP and other network: ..!seismo!mcvax!mhres!vns
This note does not necessarily represent the position of Multihouse NV
Therefore no liability or responsibility for whatever will be accepted.

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 87 08:25:23 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        buddenbergra@a.isi.edu
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: RFC on network management

Rex,

    I seem to recall that you and I talked at Monterey about network
management.  I am working with Glenn Trewitt on a suite of RFCs on
network management -- I can send you the current drafts (4 memos,
total length around 80-100 pages).

    Final drafts expected very very shortly (next couple of weeks?).
We're delaying a bit to try to accomodate a request to make some changes
that would make the specs more compatible with the ISO management
interfaces.

Craig Partridge
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 08:33:01 EDT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: RFC on network management


Rex,

    I seem to recall that you and I talked at Monterey about network
management.  I am working with Glenn Trewitt on a suite of RFCs on
network management -- I can send you the current drafts (4 memos,
total length around 80-100 pages).

    Final drafts expected very very shortly (next couple of weeks?).
We're delaying a bit to try to accomodate a request to make some changes
that would make the specs more compatible with the ISO management
interfaces.

Craig Partridge

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 10:29:55 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: COS goes with TCP/IP

Phil--

My only complaint about the Subj msg is that you neglected to send a
copy directly to me; since I fell behind a bit in my TCP-IP skimming,
it made my day several days later than it could have.  (That you're
having to get this via the list is a different story, having to do with
the fact that my mailsender couldn't pick your address out of what your
mailsender had sent.)

The interesting question your item puts me in mind of is whether it
accounts for the organizationless status of the author of RFCs 1007/8:
do you suppose that "Wayne McCoy" could be a COSsetter who doesn't
want the press to know they're not only using our stuff but also asking
for our help?  (The question is not rhetorical; I really do wonder
why there's no organization/netmail address on those RFCs.  For that
matter, I wonder even more what the basis for 1007's section 1.3's
pronunciamento on the "mandatory" applicability of it all is.)

Another interesting question, triggered by one of the responses to
your item, is whether it's been seven years yet that we've been told
next year is THE year, but that one is rhetorical (unless you have
a really nifty answer, of course, since it's always fair to answer
rhetorical questions if you've got nifty answers to 'em).  Who knows,
maybe seven IS a lucky number....

cheers, map

-------

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1987 10:29:55 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re: COS goes with TCP/IP
Phil--

My only complaint about the Subj msg is that you neglected to send a
copy directly to me; since I fell behind a bit in my TCP-IP skimming,
it made my day several days later than it could have.  (That you're
having to get this via the list is a different story, having to do with
the fact that my mailsender couldn't pick your address out of what your
mailsender had sent.)

The interesting question your item puts me in mind of is whether it
accounts for the organizationless status of the author of RFCs 1007/8:
do you suppose that "Wayne McCoy" could be a COSsetter who doesn't
want the press to know they're not only using our stuff but also asking
for our help?  (The question is not rhetorical; I really do wonder
why there's no organization/netmail address on those RFCs.  For that
matter, I wonder even more what the basis for 1007's section 1.3's
pronunciamento on the "mandatory" applicability of it all is.)

Another interesting question, triggered by one of the responses to
your item, is whether it's been seven years yet that we've been told
next year is THE year, but that one is rhetorical (unless you have
a really nifty answer, of course, since it's always fair to answer
rhetorical questions if you've got nifty answers to 'em).  Who knows,
maybe seven IS a lucky number....

cheers, map

-------
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 87 14:15:09 -0400
From:      Craig Partridge <craig@nnsc.nsf.net>
To:        tcp-ip@sri-nic.ARPA
Subject:   Clarification of "Network Management"

    I'm starting to get a bunch of messages from my last posting, so
let me try to explain the network management situation briefly.

    Since late last year there has been an ongoing effort to develop
network management protocols that could work across all the new
IP boxes which are appearing on the Internet.  The gist of the idea
is that if you are a network manager, and need to change a routing
entry in all the hosts and routers on your network, it should be
possible to do this with one program that works consistently across
all machines.  You should not have to know who made the machine, and
how their proprietary network management system (if any) works.
Most of the work is being done under the auspices of the Internet
Engineering Task Force (IETF).  There is also a very active mailing list
(gwmon-request@sh.cs.net).  Finally, there are currently quarterly meetings
open to all interested parties (the next one is in D.C. at the end of July).

    This effort is not concerned with questions like address assignment
or name space management, although I believe there is work going on in
both these areas.

Craig
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 19:03:41 EDT
From:      ramsay@MITRE.ARPA
To:        comp.protocols.tcp-ip
Subject:   Request for Information.

MITRE is seeking a product to support remote access by 1 to 16 terminals to
an Ethernet LAN and through the LAN to a VAX host running VAX/VMS.  The
protocols to be supported include TELNET/FTP, TCP, and IP, with terminal
rates of 1200 to 9600 bps.  Need basic technical data and POC for follow-up.
Understand the Communications Machinery Corporation (CMC) has a suitable
device, the CMC serial bridge terminal server; this option is being
investigated presently.  Are there users of this device out there in the
ether who can advise of its reliability, performance, and general overall
goodness?  MITRE POC Andrew K. Ramsay, comm tel (703) 556-3082, arpanet
ramsay@mitre.arpa

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23-Jun-87 20:33:47 EDT
From:      ggere@csi.UUCP (Gary M. Gere)
To:        comp.protocols.tcp-ip
Subject:   Possible Bug in 4.3 BSD TCP?

We have run into what is apparently a bug in the 4.3 BSD UNIX tcp_output code,
and I am wondering if anyone else has run into this.

Situation: VAX-11/750 running 4.3 BSD UNIX (with all official Berkeley fixes
applied) and a workstation with a dumb unbuffered ethernet interface. Our
version of tcp_output.c is 7.2.1.1 (Berkeley) 3/28/87.

Observed Problem: A FIN is properly sent by the VAX to the workstation. The FIN
is not received by the workstation (not seen). When the FIN is retransmitted by
the VAX, the sequence number is decremented by one, the urgent bit is set, and
the urgent pointer is set to one. All subsequent retransmissions of this FIN by
the VAX have this same identical damage. The workstation never ACKs the damaged
FIN and never sees the FIN it is expecting; we hang in this state indefinately.

There is code in the tcp_output.c module to handle retransmission of FINs. It
advances the sequence number at first, and then if resending a FIN, it backs
the sequence number off. Further code to set the urgent bit exists if sequence
numbers appear damaged. 

My knowledge of whats going on is limited enough, and this code is complicated
(obscure) enough that before I brain damage our system with "obvious" fixes I
am hoping someone out there has seen this before and can help.

Thanks...
-- 

===============================================================================
Communications Solutions  2125 Hamilton Avenue  San Jose, Calif 95129
Gary M. Gere {bnrmtv,epimass,nsc}!csi!ggere 408/559-1118

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jun-87 08:32:20 EDT
From:      gross@GATEWAY.MITRE.ORG.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: COS goes with TCP/IP

map,

Wayne McCoy works for NBS.

Phill

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jun-87 09:53:25 EDT
From:      craig@NNSC.NSF.NET.UUCP
To:        comp.protocols.tcp-ip
Subject:   Clarification of "Network Management"


    I'm starting to get a bunch of messages from my last posting, so
let me try to explain the network management situation briefly.

    Since late last year there has been an ongoing effort to develop
network management protocols that could work across all the new
IP boxes which are appearing on the Internet.  The gist of the idea
is that if you are a network manager, and need to change a routing
entry in all the hosts and routers on your network, it should be
possible to do this with one program that works consistently across
all machines.  You should not have to know who made the machine, and
how their proprietary network management system (if any) works.
Most of the work is being done under the auspices of the Internet
Engineering Task Force (IETF).  There is also a very active mailing list
(gwmon-request@sh.cs.net).  Finally, there are currently quarterly meetings
open to all interested parties (the next one is in D.C. at the end of July).

    This effort is not concerned with questions like address assignment
or name space management, although I believe there is work going on in
both these areas.

Craig

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jun-87 10:49:01 EDT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: COS goes with TCP/IP

Phill--
  Thanks for the info.  I'll have to assume that anybody who works for
NBS wouldn't advertantly violate a standard, so the reason neither of
his RFCs contained an organization-indicating line below the name must
have something to do with inadvertance rather than a desire to conceal
anything.  Presumably, the Padlipsky's Law that There's Always One More
Typo applies.  Now, do you suppose it also applies in 1.3 and what was
really meant was "scheduled to become mandatory"?
   cheers, map
-------

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 1987 10:49:01 EDT
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        gross@GATEWAY.MITRE.ORG (Phill Gross)
Cc:        PADLIPSKY@A.ISI.EDU, tcp-ip@SRI-NIC.ARPA
Subject:   Re: COS goes with TCP/IP
Phill--
  Thanks for the info.  I'll have to assume that anybody who works for
NBS wouldn't advertantly violate a standard, so the reason neither of
his RFCs contained an organization-indicating line below the name must
have something to do with inadvertance rather than a desire to conceal
anything.  Presumably, the Padlipsky's Law that There's Always One More
Typo applies.  Now, do you suppose it also applies in 1.3 and what was
really meant was "scheduled to become mandatory"?
   cheers, map
-------
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24-Jun-87 12:00:20 EDT
From:      montnaro@sprite.steinmetz (Skip Montanaro)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Higher speed LANs ?

In article <541@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>Is anyone working on higher speed LANs?
>What are the issues that keep us down at such low rates?
>Why is it such a struggle to get 200K bytes per second onto it?
>Are there fundamental problems with TCP/IP that limit its application
>to higher speed use?  Are the new ISO protocols better for high speed
>file transfer?  Or, is the problem in the operating systems or
>interface to the computer bus?  Can the high speed backbone fiber
>networks be made to handle individual computer to computer or
>computer to terminal traffic?  Or, it there some fundamental issue
>that keeps them in the LAN to LAN bridging application?

You (and others interested in such topics) may want to read Greg
Chesson's paper in the recent Summer 1987 USENIX Proceedings, entitled
"Protocol Engine Design". He discusses the reasons for the current
bottlenecks, at least as he sees them. He sees the "software and
system overheads" as a "limiting factor in the 10Mb/s case". Thus
moving to higher speed cabling (i.e., 100 Mb/s fiber optic systems)
will not provide any substantial increase in throughput, since the
software can't punch out the higher level information any faster. The
primary method for increasing throughput has got to come by placing
more and more of the networking protocols in hardware. The protocol
engine he's been working on is just such a beast. 

         Skip|  ARPA:      montanaro@ge-crd.arpa
    Montanaro|  UUCP:      montanaro@desdemona.steinmetz.ge.com
(518)387-7312|  GE DECnet: advax::"montanaro@desdemona.steinmetz.ge.com"

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jun-87 03:34:42 EDT
From:      HANK@BARILVM.BITNET (Henry Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Mac/Ip

Can someone fill me in on the latest on Mac/Ip - does it support Ethernet
directly or does one still need a gateway between an Appletalk LAN to
Ethernet?  Does it support FTP, Telnet and SMTP?

Thanks,
Hank

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 87 10:44:00 PST
From:      <art@acc.arpa>
To:        "iso" <iso@nrtc.arpa>
Cc:        tcp-ip@nic.sri.com
Subject:   ISO government interest group

For those people interested in GOSIP issues, there is a government
interest group forming, apparently associated with the MAP/TOP users
group.  This group appears to oriented at alligning GOSIP with
MAP and TOP 3.0.  This seems to be the appropriate forum for anyone
who wishes to be involved in the future direction of GOSIP.

I just got a brief description and an announcement of a meeting at
NBS in Gaithersburg, Maryland Aug. 3-5.  This is about all I know.

For meeting registration, contact:
	Joan Wywar - NBS
	(301) 975-3643

Sorry, no Email addresses given.

					Art Berggreen
					art@acc.arpa



------
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jun-87 13:23:49 EDT
From:      henry@utzoo.UUCP (Henry Spencer)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Higher speed LANs ?

> Is anyone working on higher speed LANs? ...

The wave of the (near) future is probably FDDI, an impending ANSI (?)
standard 100-Mbit/s fiber network.  There will presumably be interest
in pushing its speed up further as well.

> What are the issues that keep us down at such low [net] rates?  The disks
> themselves are now in the 500K to 2Meg bytes per second range. 
> Backplanes and memory are up in that range.  Certainly, interface
> logic can go that fast (it does to disks, why can't it to LANs?).

The interface hardware, on the whole, does/can go that fast.  However...
Can you say the nasty word "protocols"?  The problem is that neither the
disks nor the other things you mention are contending with the problems
of sending data over long distances on multiple-host unreliable gatewayed
networks.  If you work hard at it and have the right hardware, you can get
a good fraction of the Ethernet bandwidth by using very specialized software
that ignores most of these problems, but the solutions don't generalize
easily.  Many of the issues also either aren't well understood or haven't
been well understood until fairly recently.  To slightly paraphrase an
observation that has been made in other connections:  "networks don't really
pose any fundamentally new problems, they just break all the old kludgey
special-purpose solutions".

It is also worth mentioning that most current protocol implementations,
like most current software in general, really haven't had much attention
paid to performance in their design or implementation.

> Are there fundamental problems with TCP/IP that limit its application
> to higher speed use?

I'm told that the answer is more or less "yes".  Remember that TCP/IP dates
from the Neolithic age of network protocols (which wasn't very long ago).

> Are the new ISO protocols better for high speed file transfer?

Fat chance.

> ...  Can the high speed backbone fiber
> networks be made to handle individual computer to computer or
> computer to terminal traffic?  Or, it there some fundamental issue
> that keeps them in the LAN to LAN bridging application?

No reason why they can't work for more local traffic, but they are relatively
costly and there has been no standard, which has discouraged such use.  The
standardization of FDDI should help.

> I know that there are propritary protocols and links that go much
> faster, but is it necessary to throw out the standards and ability
> to internet and use diverse equipment and applications to get the
> higher speed?

The combination of FDDI hardware and lightweight transport protocols
supported by special hardware -- see Greg Chesson's paper in the latest
Usenix for a very interesting example -- has a reasonable chance of giving
us the speed without sacrificing interconnection and internetworking.  It
*will* take a little while before everybody is set up to do this, though.
-- 
"There is only one spacefaring        Henry Spencer @ U of Toronto Zoology
nation on Earth today, comrade."   {allegra,ihnp4,decvax,pyramid}!utzoo!henry

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25-Jun-87 14:44:00 EDT
From:      art@ACC.ARPA
To:        comp.protocols.tcp-ip
Subject:   ISO government interest group


For those people interested in GOSIP issues, there is a government
interest group forming, apparently associated with the MAP/TOP users
group.  This group appears to oriented at alligning GOSIP with
MAP and TOP 3.0.  This seems to be the appropriate forum for anyone
who wishes to be involved in the future direction of GOSIP.

I just got a brief description and an announcement of a meeting at
NBS in Gaithersburg, Maryland Aug. 3-5.  This is about all I know.

For meeting registration, contact:
	Joan Wywar - NBS
	(301) 975-3643

Sorry, no Email addresses given.

					Art Berggreen
					art@acc.arpa



------

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 87 10:34:42 P
From:      Henry Nussbacher <HANK%BARILVM.BITNET@wiscvm.wisc.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   Mac/Ip
Can someone fill me in on the latest on Mac/Ip - does it support Ethernet
directly or does one still need a gateway between an Appletalk LAN to
Ethernet?  Does it support FTP, Telnet and SMTP?

Thanks,
Hank
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 87 14:37:05 GMT
From:      gatech!dcatla!dnkbj@seismo.css.gov  (Kirby B. Jackson)
To:        tcp-ip@sri-nic.arpa
Subject:   request for info on TN3270
I have recently seen some discussion on this newsgroup on TN3270,
which I suppose to be remote 3270 terminal emulation. 

Could someone please give a more detailed explanation of the 
purpose and uses of this protocol? I would also like to know if
specifications for it exist, and how to obtain copies.

Thanks in advance,
                           Bryan
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 87 15:32:30 GMT
From:      super.upenn.edu!operations.dccs.upenn.edu!shaffer@RUTGERS.EDU  (Earl Shaffer)
To:        tcp-ip@sri-nic.arpa
Subject:   Wollongong

We would like comments from people who have installed Wollongong's
"WIN/TCP" package on a VMS machine.  Particularly the following:
	1) What was the most difficult part of the install
	2) which was easiest
	3) have you done it more than one machine
	4) do you have any suggestions or tips for novice installers

We plan to be installing the sw on many machines and we would like to
know about as many potential problems ahead of time as we can.

Thanks for any help,


==============================================================================
Earl Shaffer - University of Pennsylvania - Data Communications Department
"Time was invented so that everything wouldn't happen at once." Steven Wright
==============================================================================
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jun-87 07:11:49 EDT
From:      schoff@nic.nyser.net (Martin Lee Schoffstall)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Higher speed LANs ?

I understand that AMD has been doing an initial chip set for
the FDDI "spec".  I understand that there have been some
problems, would anyone care to comment?

Marty Schoffstall
schoff@nic.nyser.net

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jun-87 14:19:27 EDT
From:      mac@MONK.PROTEON.COM (Mike Curtis)
To:        comp.protocols.tcp-ip
Subject:   Sperry 5000's


	Is there anybody out there running a Sperry 5000, or know
anyone that is?  In particular, what are you doing for a TFTP daemon?
We were dissapointed to find out that it is not a part of the NET-5000
software.  Any help anyone out there would be greatly appreciated.

Thanks in advance,


Michael A. Curtis
Proteon, Inc.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 87 19:06 PDT
From:      Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>
To:        tcp-ip@sri-nic.ARPA
Subject:   question about berkeley TCP/IP
When a SYN is sent to a Berkeley UNIX TCP/IP implementation (4.3 or 4.2)
it appears that UNIX can send the SYN-ACK without having to ARP for the
host it's ACKing.  Does it indeed add an entry to the ARP table when an
ethernet IP packet comes in?  I'll buy that anything to cut down
on ethernet broadcasts is a good thing...

This may seem like a dumb question, but the code is a little opaque and
I'm not a UNIX kernel hack.  I have a hypothesis which explains some behaviour
I'm seeing with the TCP I maintain (CMU/Tek for VAX/VMS) and UNIX must be
doing this if my theory's any good.

Thanks,

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jun-87 16:21:23 EDT
From:      ron@topaz.rutgers.edu (Ron Natalie)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Higher speed LANs ?

I think you are wrong to indicate that the sole reason for the slow
effective throughputs is protocols.  The two major problems in UNIX
to day (for either networking or disk access) is IMPLEMENTATION rather
than protocol design problems.  First, there is too much memory to
memory copying in UNIX.  Studies show that much of the disk throughput
is lost through this and the implemenation of IP on UNIX is even worse.
Code is copied from memory to memory three times in UNIX.  None of this
is the fault of the protocol design.

Also bringing up TCP/IP for disk to disk through put is not really relevent.
TCP is designed for streams not disk sectors.  Notice that the datagram
protocols in the DOD suite (e.g. UDP) are used for most of the remote
disk/file system approaches.

As I already pointed out, many computer's I/O systems are where the bottleneck
is currently, especially on micros.  They can't achieve anything near
a megabyte/sec throughput on their interfaces.  This more than anything
else is what is the current bottleneck.  New protocols are inevitable,
especially for higher performance applications, but I don't think we've
run out of performance in the IP protocol suite yet.

-Ron

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26-Jun-87 22:06:00 EDT
From:      KVC@ENGVAX.SCG.HAC.COM (Kevin Carosso)
To:        comp.protocols.tcp-ip
Subject:   question about berkeley TCP/IP

When a SYN is sent to a Berkeley UNIX TCP/IP implementation (4.3 or 4.2)
it appears that UNIX can send the SYN-ACK without having to ARP for the
host it's ACKing.  Does it indeed add an entry to the ARP table when an
ethernet IP packet comes in?  I'll buy that anything to cut down
on ethernet broadcasts is a good thing...

This may seem like a dumb question, but the code is a little opaque and
I'm not a UNIX kernel hack.  I have a hypothesis which explains some behaviour
I'm seeing with the TCP I maintain (CMU/Tek for VAX/VMS) and UNIX must be
doing this if my theory's any good.

Thanks,

        /Kevin Carosso                     kvc@engvax.scg.hac.com
         Hughes Aircraft Co.               kvc%engvax@oberon.usc.edu

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jun-87 10:31:44 EDT
From:      JBVB@AI.AI.MIT.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: request for info on TN3270

"TN3270" is a specialized mode of Telnet, entered once receptive hosts
(IBM MVS or VM systems) have negotiated the TERMINAL_TYPE option,
requested and received a terminal type of IBM-3278-2 (or another 3270-type
terminal agreeable to both ends), and negotiated the EOR and BINARY options
(some hosts are satisfied with just BINARY).

Once you are in 3270 mode, the data stream shifts to EBCDIC, and EOR is
used to define the boundaries of of blocks of data (Write commands,
responses to Read & Read-Modified, and AID sequences, with or without
trailing modified fields).  The server disables whatever translation
or emulation it was using initially, and passes the 3270 data stream
to its applications (while still filtering IAC xxx).  The client gets
the 3270 orders, and either translates them into something suitable for
the user's display (and vice versa), or passes them on to a locally-
connected 327x (if the client is another IBM mainframe).  If BINARY
is re-negotiated and turned off, the data stream returns to NVT ascii.

Implementations that I am sure support TN3270 include:

UCLA MVS ACP		client & server
ACC ACCESS/MVS		client & server
Spartacus KNET/MVS	client & server
WISCNET VM		client & server
IBM VM			client & server (old Wiscnet, & recent announcement)
Spartacus KNET/VM	client & server
ACC ACCESS/VM		client & server
4BSD (G. Minshall)	client (source form, usable on most 4BSD derivatives)
FTP Software PC/TCP	client (MS/DOS IBM-compatible PCs only)

In addition, Greg Minshall has mentioned an adaptation of his software to
the Ungermann-Bass NIU card on the PC, and there may be other academic
efforts available.  Other mainframe software vendors *may* be able to
support TN3270, ask them.  IBM has announced an MS/DOS TCP/IP for PCs,
which includes a TN3270 client, sheduled for availability 7/31.

As of this moment, the only written information I am aware of would be
found in the archives of the tcp-ip mailing list, dating from January
through March of this year.  An effort is in progress to write an RFC
on TN3270, organized by Bruce Crabill (bruce@umdd.umd.edu), but I
haven't seen any working documents yet.

jbvb@ai.ai.mit.edu
James B. VanBokkelen
FTP Software Inc.

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jun-87 16:26:31 EDT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   newer (bug fixed) 4.3bsd tcp for Sun OS 3.3 available

Bill Nowicki of Sun kindly sent me a long list of bug fixes for our
Sun version of the 4.3bsd tcp code.  I think I've incorporated all
his fixes in a new version.  At the same time, Mike Karels of Berkeley
fixed four or five minor bugs in the 4.3 code.  I've incorporated
those fixes as well.

Also, you may have noticed that the retransmit timer code was almost
completely broken in the previous version.  We have been using the
new timer algorithm I described on the tcp-ip list a few weeks ago.
Although the new algorithm has been working well in several weeks
of tests at LBL, I didn't want to pass out experimental code.  I
tried to back-fit the original timer code and blew it.  It looks
like the new timer algorithm is about to go into 4.3bsd so we've
left it in the new version of the Sun code.

The new code is compressed tarchive 4.3tcp4sun3.3.tar.Z available
via anonymous ftp from lbl-rtsg.arpa.  Note that this code is for
Sun OS 3.3.  As Bill Nowicki has pointed out, you *DON'T want to
USE IT WITH Sun OS 3.4*: 3.4 already contains the 4.3bsd tcp code
and, since 3.4 has most of the 4.3 icmp fixes as well, several
features that we've ifdef'd out are enabled in Sun's 3.4.

 - Van

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jun-87 22:09:22 EDT
From:      van@LBL-CSAM.ARPA (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: Your TCP timer code

Keith -

I think that rtt algorithms commonly confuse what's being done
with why it's being done.  In tcp, "what" is measuring packet
round trip time but "why" is to determine when packets have been
lost.  A good loss estimator may not be a good rtt estimator. 

The reasoning behind the mean & deviation estimation was that
packets "almost always" get acked within the time interval
RTTmean + 2 * RTTdev (by Chebyshev's inequality).  So you can
set a timer for this interval when you launch a packet and have
fair confidence that the packet has been lost if the timer goes
off before you get an ack.

The algorithm I gave makes bad predictions when rtt goes down
because adding in the absolute value of the prediction error
keeps rto at its old value for four or five samples.  There are
at least a couple of reasons for rtt to go down: (1) the packets
might have found a better route or (2) there might be a mis-match
between the window size & the path delay, creating a large time
gap between the packet at the right edge of a window & the packet
at the left edge of the next window. 

(1) doesn't happen all that often (at least, not to my packets)
and, when it does, the new path is often not as lossy as the old
so keeping rto high for a few samples has a negligible effect on
performance (because the retransmission timeout becomes less
likely). 

(2) is typical Internet conditions and you find that when rtt
goes down it's going to jump back up again in one or two packets.
If you let rto follow rtt down, there's a very high probability
that you will do a spurious retransmission of the next packet
(remember that we are doing one-ahead predictions: we use the
current packet's rtt to predict the loss of the next packet).
Rtt's are jumping up and down because the network path is overloaded
and your retransmission is going to load it more.  It's not hard
to show this is a regenerative feedback that leads to congestive
collapse.

So, by the principle of least damage, you want the loss prediction
to stay high for a short while after rtt goes down.

[Arguments from stochastic control theory can make this
handwaving a bit more rigorous.  I try to make some of these
arguments in my paper.  More importantly, the paper has some
plots of rtt on typical Internet tcp connections that (I think)
make it obvious why you want rto to stay high.  With luck, I'll
finish this paper shortly and find someone interested in
publishing it.]

  - Van

  (for people not into alphabet soup: 
	rtt = Round Trip Time
	rto = Retransmission Timd in'20

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27-Jun-87 22:21:50 EDT
From:      henry@utzoo.UUCP (Henry Spencer)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: Higher speed LANs ?

> I think you are wrong to indicate that the sole reason for the slow
> effective throughputs is protocols...

Well, I should have elaborated that a little.  The reason for low
throughputs (compared to the hardware) is the presence of protocols
between hardware and user.  The biggest problem with protocols on most
current systems is that they are implemented inefficiently.  One can
definitely do better.  Eventually the protocol designs do impose limits
(or rather, obstacles that are increasingly hard to overcome), although
few existing implementations suffer from this yet.
-- 
Mars must wait -- we have un-         Henry Spencer @ U of Toronto Zoology
finished business on the Moon.     {allegra,ihnp4,decvax,pyramid}!utzoo!henry

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Jun-87 03:52:42 EDT
From:      hedrick@topaz.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP introduction


I keep seeing requests on various newsgroups for an introduction to
TCP/IP.  I also get such requests locally.  I believe that the only
appropriate description of TCP/IP is the RFC's.  However I also think
a brief introduction is likely to be helpful before plowing right
into them.  The following document is an attempt to do that.  It also
recommends some RFC's to look at and tells you how to get them.

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

This document is a brief introduction to TCP/IP, followed by advice on
what to read for more information.  This is not intended to be a
complete description, but merely enough of an introduction to allow
you to start reading the RFC's.  At the end of the document there will
be a list of the RFC's that we recommend reading.

TCP/IP is a set of protocols developed to allow cooperating computers
to share resources across a network.  It was developed by a community
of researchers centered around the ARPAnet.  Certainly the ARPAnet is
the best-known TCP/IP network.  However as of June, 87, at least 130
different vendors had products that support TCP/IP, and thousands of
networks of all kinds use it.

First some basic definitions.  Although TCP/IP (or IP/TCP) seems to be
the most common term these days, most of the documentation refers to
the "Internet protocols".  The Internet is a collection of networks,
including the Arpanet, NSFnet, regional networks such as NYsernet,
local networks at a number of University and research institutions,
and a number of military networks.  The term "Internet" applies to
this entire set of networks.  The subset of them which is managed by
the Department of Defense is referred to as the "DDN" (Defense Data
Network).  This includes some research-oriented networks, such as the
Arpanet, as well as more strictly military ones.  (Because much of the
funding for Internet protocol developments is done via the DDN
organization, the terms Internet and DDN can sometimes seem
equivalent.)  All of these networks are connected to each other, and
users can send messages from any of them to any other (except where
security or other policy restrictions control access).  Officially
speaking, the Internet protocol documents are simply standards adopted
by the Internet community for its own use.  More recently, the
Department of Defense issued a MILSPEC definition of TCP/IP.  This was
intended to be a more formal definition, appropriate for use in
purchasing specifications.  However most of the TCP/IP community
continues to use the Internet standards.  The MILSPEC version is
intended to be consistent with it.

Whatever it is called, TCP/IP is a family of protocols.  A few are
basic ones used for many applications.  These include IP, TCP, and
UDP.  Others are protocols for doing specific tasks, e.g. transferring
files between computers, sending mail, or finding out who is logged in
on another computer.  Any real application will use several of these
protocols.  A typical situation is sending mail.  First, there is a
protocol for mail.  This defines a set of commands which one machine
sends to another, e.g. commands to specify who the sender of the
message is, who it is being sent to, and then the text of the message.
However this protocol assumes that there is a way to communicate
reliably between the two computers.  Mail, like other application
protocols, simply defines a set of commands and messages to be sent.
It is designed to be used together with TCP and IP. TCP is responsible
for making sure that the commands get through to the other end.  It
keeps track of what is sent, and retransmitts anything that did not
get through.  If any message is too large for one packet, e.g. the
text of the mail, TCP will split it up into several packets, and make
sure that they all arrive correctly.  Since these functions are needed
for many applications, they are put together into a separate protocol,
rather than being part of the specifications for sending mail.  You
can think of TCP as forming a library of routines that applications
can use when they need reliable network communications with another
computer.  Similarly, TCP calls on the services of IP.  Although the
services that TCP supplies are needed by many applications, there are
still some kinds of applications that don't need them.  However there
are some services that every application needs.  So these services are
put together into IP.  As with TCP, you can think of IP as a library
of routines that TCP calls on, but which is also available to
applications that don't use TCP.  This strategy of building several
levels of protocol is called "layering".  We think of the applications
programs such as mail, TCP, and IP, as being separate "layers", each
of which calls on the services of the layer below it.  Generally,
TCP/IP applications use 4 layers:

  - an application protocol such as mail
  - a protocol such as TCP that provides services need by many applications
  - IP, which provides the basic service of getting packets to their
	destination
  - the protocols needed to manage a specific physical medium, such as
	Ethernet or a point to point line.

TCP/IP is based on the "catenet model".  (This is described in more
detail in ien-48.txt.)  This model assumes that there are a large
number of independent networks connected together by gateways.  The
user should be able to access computers or other resources on any of
these networks.  Packets will often pass through a dozen different
networks before getting to their final destination.  The routing
needed to accomplish this should be completely invisible to the user.
As far as the user is concerned, all he needs to know in order to
access another system is an "Internet address".  This is an address
that looks like 128.6.4.194.  It is actually a 32-bit number.  However
it is normally written as 4 decimal numbers, each representing 8 bits
of the address.  (The term "octet" is used by Internet documentation
for such 8-bit chunks.  The term "byte" is not used, because TCP/IP is
supported by some computers that have byte sizes other than 8 bits.)
Generally the structure of the address gives you some information
about how to get to the system.  For example, 128.6 is a network
number assigned by a central authority to Rutgers University.  Rutgers
uses the next octet to indicate which of the campus Ethernets is
involved.  128.6.4 happens to be an Ethernet used by the Computer
Science Department.  The last octet allows for up to 254 systems on
each Ethernet.  Note that 128.6.4.194 and 128.6.5.194 would be
different systems.  (The structure of an Internet address is described
in a bit more detail later.)

Of course we normally refer to systems by name, rather than by
Internet address.  When we specify a name, the network software looks
it up in a database, and comes up with the corresponding Internet
address.  Most of the network software deals strictly in terms of the
address.  (rfc-882.txt describes the database used to look up names.)

TCP/IP is a "connectionless" protocol.  Information is transfered in
"packets".  Each of these packets is sent through the network
individually.  There are provisions to open connections to systems.
However at some level, information is put into packets, and those
packets are treated by the network as completely separate.  For
example, suppose you want to transfer a 15000 octet file.  Most
networks can't handle a 15000 octet packet.  So the protocols will
break this up into something like 30 500-octet packets.  Each of these
packets will be sent to the other end.  At that point, they will be
put back together into the 15000-octet file.  However while those
packets are in transit, the network doesn't know that there is any
connection between them.  It is perfectly possible that packet 14 will
actually arrive before packet 13.  It is also possible that somewhere
in the network, an error will occur, and a packet won't get through
at all.  In that case, that packet has to be sent again.  In fact,
there are two separate protocols involved in doing this.  TCP (the
"transmission control protocol") is responsible for breaking up the
message into packets, reassembling them at the other end, resending
anything that gets lost, and putting things back in the right order.
IP (the "internet protocol") is responsible for routing individual
packets.  It may seem like TCP is doing all the work.  And in small
networks that is true.  However in the Internet, simply getting a
packet to its destination can be a complex job.  A connection may
require the packet to go through several networks at Rutgers, a serial
line to the John von Neuman Supercomputer Center, a couple of
Ethernets there, a series of 56Kbaud phone lines to another NSFnet
site, and more Ethernets on another campus.  Keeping track of the
routes to all of the destinations and handling incompatibilities among
different transport media turns out to be a complex job.  Note that
the interface between TCP and IP is fairly simple.  TCP simply hands
IP a packet with a destination.  IP doesn't know how this packet
relates to any packet before it or after it.

It may have occured to you that something is missing here.  We have
talked about Internet addresses, but not about how you keep track of
multiple connections to a given system.  Clearly it isn't enough to
get a packet to the right destination.  TCP has to know which
connection this packet is part of.  This task is referred to as
"demultiplexing."  In fact, there are several levels of demultiplexing
going on in TCP/IP.  The information needed to do this demultiplexing
is contained in a series of "headers".  A header is simply a few extra
octets tacked onto the beginning of a packet by some protocol in order
to keep track of it.  It's a lot like putting a letter into an
envelope and putting an address on the outside of the envelope.
Except with modern networks it happens several times.  It's like you
put the letter into a little envelope, your secretary puts that into a
somewhat bigger envelope, the campus mail center puts that envelope
into a still bigger one, etc.  Here is an overview of the headers that
get stuck on a message that passes through a typical TCP/IP network:

We start with a single data stream, say a file you are trying to
send to some other computer:

   ......................................................

TCP breaks it up into managable chunks.  (In order to do this, TCP has
to know how large a packet your network can handle.  Actually, the
TCP's at each end say how big a packet they can handle, and then they
pick the smallest size.)

   ....   ....   ....   ....   ....   ....   ....   ....

TCP puts a header at the front of each packet.  This header actually
contains at least 20 octets, but the most important ones are a source
and destination "port number" and a "sequence number".  The port
numbers are used to keep track of different conversations.  Suppose 3
different people are transferring files.  Your TCP might allocate port
numbers 1000, 1001, and 1002 to these transfers.  When you are sending
a packet, this becomes the "source" port number, since you are the
source of the packet.  Of course the TCP at the other end has assigned
a port number of its own for the conversation.  Your TCP has to know
the port number used by the other end as well.  (It finds out when the
connection starts, as we will explain below.)  It puts this in the
"destination" port field.  Of course if the other end sends a packet
back to you, the source and destination port numbers will be reversed,
since then it will be the source and you will be the destination.
Each packet has a sequence number.  This is used so that the other end
can make sure that it gets the packets in the right order, and that it
hasn't missed any.  (See the TCP specification for details.  TCP
doesn't number the packets, but the octets.  So if there are 500
octets of data in each packet, the first packet might be numbered 0,
the second 500, the next 1000, the next 1500, etc.)  Finally, I will
mention the Checksum.  This is a number that is computed by adding up
all the octets in the packet (more or less - see the TCP spec).  The
result is put in the header.  TCP at the other end computes the
checksum again.  If they disagree, then something bad happened to the
packet in transmission, and it is thrown away.  So here's what the
packet looks like now.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |           other junk          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   your data ... next 500 octets                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ......                                                      |

If we abbreviate the TCP header as "T", the whole file now looks like this:

   T....   T....   T....   T....   T....   T....   T....   T....

TCP now sends each of these packets to IP.  Of course it has to tell
IP the Internet address of the computer at the other end.  Note that
this is all IP is concerned about.  It doesn't care about what is in
the packet, or even in the TCP header.  IP's job is simply to find a
route for the packet and get it to the other end.  In order to allow
gateways or other intermediate systems to forward the packet, it adds
its own header.  The main things in this header are the source and
destination Internet address (32-bit addresses, like 128.6.4.194), the
protocol number, and another checksum.  The source Internet address is
simply the address of your machine.  (This is necessary so the other
end knows where the packet came from.)  The destination Internet
address is the address of the other machine.  (This is necessary so
any gateways in the middle know where you want the packet to go.)  The
protocol number tells IP at the other end to send the packet to TCP.
Although most IP traffic uses TCP, there are other protocols that can
use IP, so you have to tell IP which protocol to send the packet to.
Finally, the checksum allows IP at the other end to verify that the
packet wasn't damaged in transit.  Note that TCP and IP have separate
checksums.  This is because IP doesn't know anything about TCP.  As
far as IP is concerned, everything after its header is just a bunch of
bits.  So IP computes a checksum of its own header, and IP at the
other end checks it to make sure that the message didn't get damaged
in transit.  Once IP has tacked on its header, here's what the
message looks like:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      various other junk                       |  
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     junk      |    Protocol   |         Header Checksum       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TCP header, then your data ......

If we represent the IP header by an "I", your file now looks like this:

   IT....   IT....   IT....   IT....   IT....   IT....   IT....   IT....

At this point, it's possible that no more headers are needed.  If your
computer happens to have a direct phone line connecting it to the
destination computer, or to a gateway, it may simply send the packets
out on the line (though likely a synchronous protocol such as HDLC
would be used, and it would add at least a few octets at the beginning
and end).

However most of our networks these days use Ethernet.  So now we have
to describe Ethernet's headers.  Unfortunately, Ethernet has its own
addresses.  The people who designed Ethernet wanted to make sure that
no two machines would end up with the same Ethernet address.
Furthermore, they didn't want the user to have to worry about
assigning addresses.  So each Ethernet controller comes with an
address builtin from the factory.  In order to make sure that they
would never have to reuse addresses, the Ethernet designers allocated
48 bits for the Ethernet address.  People who make Ethernet equipment
have to register with a central authority, to make sure that the
numbers they assign don't overlap any other manufacturer.  Ethernet is
a "broadcast medium".  That is, it is in effect like an old party line
telephone.  When you send a packet out on the Ethernet, every machine
on the network sees the packet.  So something is needed to make sure
that the right machine gets it.  As you might guess, this involves the
Ethernet header.  Every Ethernet packet has a 14-octet header that
includes the source and destination Ethernet address, and a type code.
Each machine is supposed to pay attention only to packets with its own
Ethernet address in the destination field.  (It's perfectly possible
to cheat, which is one reason that Ethernet communications are not
terribly secure.)  Note that there is no connection between the
Ethernet address and the Internet address.  Each machine has to have a
table of what Ethernet address corresponds to what Internet address.
(We will describe how this table is constructed a bit later.)  In
addition to the addresses, the header contains a type code.  The type
code is to allow for several different protocol families to be used on
the same network.  So you can use TCP/IP, DECnet, Xerox NS, etc. at
the same time.  Each of them will put a different value in the type
field.  Finally, there is a checksum.  The Ethernet controller
computes a checksum of the entire packet.  When the other end receives
the packet, it recomputes the checksum, and throws the packet away if
the answer disagrees with the original.  The checksum is put on the
end of the packet, not in the header.  The final result is that your
message looks like this:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Ethernet destination address (first 32 bits)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ethernet dest (last 16 bits)  |Ethernet source (first 16 bits)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Ethernet source address (last 32 bits)                  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type code              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IP header, then TCP header, then your data                   |
   |                                                               |
 ...
   |                                                               |
   |   end of your data                                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Ethernet Checksum                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If we represent the Ethernet header with "E", and the Ethernet
checksum with "C", your file now looks like this:

   EIT....C   EIT....C   EIT....C   EIT....C   EIT....C   EIT....C 

When these packets are received by the other end, of course all the
headers are removed.  The Ethernet interface removes the Ethernet
header and the checksum.  It looks at the type code.  Since the type
code is the one assigned to IP, the Ethernet device driver passes the
packet up to IP.  IP removes the IP header.  It looks at the IP
protocol field.  Since the protocol type is TCP, it passes the packet
up to TCP.  TCP now looks at the packet sequence number.  It uses the
sequence numbers and other information to combine all the packets into
the original file.

The ends our initial summary of TCP/IP.  There are still some crucial
concepts we haven't gotten to, so we'll now go back and add details in
several areas.  (For detailed descriptions of the items discussed here
see, rfc793.txt for TCP, rfc791.txt for IP, and rfc894.txt and
rfc826.txt for sending IP over Ethernet.)


Well-known sockets and the applications layer
=============================================

So far, we have described how a stream of data is broken up into
packets, sent to another computer, and put back together.  However
something more is needed in order to accomplish anything useful.
There has to be a way for you to open a connection to a specified
computer, log into it, tell it what file you want, and control the
transmission of the file.  (If you have a different application in
mind, e.g. computer mail, some analogous protocol is needed.)  This is
done by "application protocols".  The application protocols run "on
top" of TCP/IP.  That is, when they want to send a message, they give
the message to TCP.  TCP makes sure it gets delivered to the other
end.  Because TCP and IP take care of all the networking details, the
applications protocols can treat a network connection as if it were a
simple byte stream, like a terminal or phone line.

Before going into more details about applications programs, we have to
describe how you find an application.  Suppose you want to send a file
to a computer whose Internet address is 128.6.4.7.  To start the
process, you need more than just the Internet address.  You have to
connect to the file transfer server at the other end.  In general,
network programs are specialized for a specific set of tasks.  Most
systems have separate programs to handle file transfers, remote
terminal logins, mail, etc.  When you connect to 128.6.4.7, you have
to specify that you want to talk to the file transfer program.  This
is done by having "well-known sockets" for each program.  Recall that
TCP uses port numbers to keep track of individual conversations.  User
programs normally use more or less random port numbers.  However
specific port numbers are assigned to the programs that sit waiting
for requests.  For example, if you want to send a file, you will start
a program called "ftp".  It will open a connection using some random
number, say 1234, for the port number on its end.  However it will
specify port number 21 for the other end.  This is the official port
number for the ftp server.  Note that there are two different programs
involved.  You run ftp on your side.  This is a program designed to
accept commands from your terminal and pass them on to the other end.
The program that you talk to on the other machine is the ftp server.
It is designed to accept commands from the network connection, rather
than an interactive terminal.  There is no need for your program to
use a well-known socket number for itself.  Nobody is trying to find
it.  However the servers have to have well-known numbers, so that
people can open connections to them and start sending them commands.
The official port numbers for each program are given in "Assigned
Numbers".

Note that a connection is actually described by a set of 4 numbers:
the Internet address at each end, and the TCP port number at each end.
Every packet has all four of those numbers in it.  (The Internet
addresses are in the IP header, and the TCP port numbers are in the
TCP header.)  In order to keep things straight, no two connections can
have the same set of numbers.  However it is enough for any one number
to be different.  For example, it is perfectly possible for two
different users on a machine to be sending files to the same other
machine.  This could result in connections with the following
parameters:

               Internet addresses         TCP ports
connection 1  128.6.4.194, 128.6.4.7      1234, 21
connection 2  128.6.4.194, 128.6.4.7      1235, 21

Since the same machines are involved, the Internet addresses are the
same.  Since they are both doing file transfers, one end of the
connection involves the well-known port number for file transfer.  The
only thing that differs is the port number for the program that the
users are running.  That's enough of a difference.  Generally, at
least one end of the connection asks the network software to assign it
a port number that is guaranteed to be unique.  Normally, it's the
user's end, since the server has to use a well-known number.

Now that we know how to open connections, let's get back to the
applications programs.  As mentioned above, once TCP has opened a
connection, we have something that might as well be a simple wire.
All the hard parts are handled by TCP and IP.  However we still need
some agreement as to what we send over this connection.  In effect
this is simply an agreement on what set of commands the application
will understand, and the format in which they are to be sent.
Generally, what is sent is a combination of commands and data.  They
use context to differentiate.  For example, the mail protocol works
like this: Your mail program opens a connection to the mail server at
the other end.  Your program gives it your machine's name, the sender
of the message, and the recipients you want it sent to.  It then sends
a command saying that it is starting the message.  At that point, the
other end stops treating what it sees as commands, and starts
accepting the message.  Your end then starts sending the text of the
message.  At the end of the message, a special mark is sent (a dot in
the first column).  After that, both ends understand that your program
is again sending commands.  This is the simplest way to do things, and
the one that most applications use.

File transfer is somewhat more complex.  The file transfer protocol
involves two different connections.  It starts out just like mail.
The user's program sends commands like "log me in as this user", "here
is my password", "send me the file with this name".  However once the
command to send data is sent, a second connection is opened for the
data itself.  It would certainly be possible to send the data on the
same connection, as mail does.  However file transfers often take a
long time.  The designers of the file transfer protocol wanted to
allow the user to continue issuing commands while the transfer is
going on.  For example, the user might make an inquiry, or he might
abort the transfer.  Thus the designers felt it was best to use a
separate connection for the data and leave the original command
connection for commands.  (It is also possible to open command
connections to two different computers, and tell them to send a file
from one to the other.  In that case, the data couldn't go over the
command connection.)

Remote terminal connections use another mechanism still.  For remote
logins, there is just one connection.  It normally sends data.  When
it is necessary to send a command (e.g. to set the terminal type or to
change some mode), a special character is used to indicate that the
next character is a command.  If the user happens to type that special
character as data, two of them are sent.

We are not going to describe the application protocols in detail in
this document.  It's better to read the RFC's yourself.  However there
are a couple of common conventions used by applications that will be
described here.  First, the common network representation: TCP/IP is
intended to be usable on any computer.  Unfortunately, not all
computers agree on how data is represented.  There are differences in
character codes (ASCII vs. EBCDIC), in end of line conventions
(carriage return, line feed, or a representation using counts), and in
whether terminals expect characters to be sent individually or a line
at a time.  In order to allow computers of different kinds to
communicate, each applications protocol defines a standard
representation.  Note that TCP and IP do not care about the
representation.  TCP simply sends octets.  However the programs at
both ends have to agree on how the octets are to be interpreted.  The
RFC for each application specifies the standard representation for
that application.  Normally it is "net ASCII".  This uses ASCII
characters, with end of line denoted by a carriage return followed by
a line feed.  For remote login, there is also a definition of a
"standard terminal", which turns out to be a half-duplex terminal with
echoing happening on the local machine.  Most applications also make
provisions for the two computers to agree on other representations
that they may find more convenient.  For example, PDP-10's have 36-bit
words.  There is a way that two PDP-10's can agree to send a 36-bit
binary file.  Similarly, two systems that prefer full-duplex terminal
conversations can agree on that.  However each application has a
standard representation, which every machine must support.

(For more details about the protocols mentioned in this section, see
rfc821.txt and rfc822.txt for mail, rfc959.txt for file transfer, and
rfc854.txt and rfc855.txt for remote logins.  For the well-known port
numbers, see the current edition of Assigned Numbers, and possible
rfc814.txt.)


Protocols other than TCP: UDP and ICMP
======================================

So far, we have described only connections that use TCP.  Recall that
TCP is responsible for breaking up messages into packets, and
reassembling them properly.  However in many applications, we have
messages that will always fit in a single packet.  An example is name
lookup.  When a user attempts to make a connection to another system,
he will generally specify the system by name, rather than Internet
address.  His system has to translate that name to an address before
it can do anything.  Generally, only a few systems have the database
used to translate names to addresses.  So the user's system will want
to send a query to one of the systems that has the database.  This
query is going to be very short.  It will certainly fit in one packet.
So will the answer.  Thus it seems silly to use TCP.  Of course TCP
does more than just break things up into packets.  It also makes sure
that the data arrives, resending packets where necessary.  But for a
question that fits in a single packet, we don't need all the
complexity of TCP to do this.  If we don't get an answer after a few
seconds, we can just ask again.  For applications like this, there are
alternatives to TCP.

The most common alternative is UDP ("user datagram protocol").  UDP is
designed for applications where you don't need to put sequences of
packets together.  It fits into the system much like TCP.  There is a
UDP header.  The network software puts the UDP header on the front of
your data, just as it would put a TCP header on the front of your
data.  Then UDP sends the data to IP, which adds the IP header,
putting UDP's protocol number in the protocol field instead of TCP's
protocol number.  However UDP doesn't do as much as TCP does.  It
doesn't split data into multiple packets.  It doesn't keep track of
what it has sent so it can resend if necessary.  About all that UDP
provides is port numbers, so that several programs can use UDP at
once.  UDP port numbers are used just like TCP port numbers.  There
are well-known port numbers for servers that use UDP.  Note that the
UDP header is shorter than a TCP header.  It still has source and
destination port numbers, and a checksum, but that's about it.  No
sequence number, since it is not needed.  UDP is used by the protocols
that handle name lookups (see ien-116.txt, rfc882.txt, and
rfc883.txt), and a number of similar protocols.

Another alternative protocol is ICMP ("Internet control message
protocol").  ICMP is used for error messages, and other messages
intended for the TCP/IP software itself, rather than any particular
user program.  For example, if you attempt to connect to a host, your
system may get back an ICMP message saying "host unreachable".  ICMP
can also be used to find out some information about the network.  See
rfc792.txt for details of ICMP.  ICMP is similar to UDP, in that it
handles messages that fit in one packet.  However it is even simpler
than UDP.  It doesn't even have port numbers in its header.  Since all
ICMP messages are interpreted by the network software itself, no port
numbers are needed to say where a ICMP message is supposed to go.


Routing
=======

The description above indicated that the IP implementation is
responsible for getting packets to the destination indicated by the
destination address, but little was said about how this would be done.
The task of finding how to get a packet to its destination is referred
to as "routing".  In fact many of the details depend upon the
particular implementation.  However some general things can be said.

First, it is necessary to understand the model on which IP is based.
IP assumes that a system is attached to some local network.  We assume
that the system can send packets to any other system on its own
network.  (In the case of Ethernet, it simply finds the Ethernet
address of the destination system, and puts the packet out on the
Ethernet.)  The problem comes when a system is asked to send a packet
to a system on a different network.  This problem is handled by
gateways.  A gateway is a system that connects a network with one or
more other networks.  Gateways are often normal computers that happen
to have more than one network interface.  For example, we have a Unix
machine that has two different Ethernet interfaces.  Thus it is
connected to networks 128.6.4 and 128.6.3.  This machine can act as a
gateway between those two networks.  The software on that machine must
be set up so that it will forward packets from one network to the
other.  That is, if a machine on network 128.6.4 sends a packet to the
gateway, and the packet is addressed to a machine on network 128.6.3,
the gateway will forward the packet to the destination.  Major
communications centers often have gateways that connect a number of
different networks.

Routing in IP is based entirely upon the network number of the
destination address.  Each computer has a table of network numbers.
For each network number, a gateway is listed.  This is the gateway to
be used to get to that network.  Note that the gateway doesn't have to
connect directly to the network.  It just has to be the best place to
go to get there.  For example at Rutgers, our interface to NSFnet
is at the John von Neuman Supercomputer Center (JvNC). Our connection
to JvNC is via a high-speed serial line connected to a gateway whose
address is 128.6.3.12.  Systems on net 128.6.3 will list 128.6.3.12 as
the gateway for many off-campus networks.  However systems on net
128.6.4 will list 128.6.4.1 as the gateway to those same off-campus
networks.  128.6.4.1 is the gateway between networks 128.6.4 and
128.6.3, so it is the first step in getting to JvNC.

When a computer wants to send a packet, it first checks to see if the
destination address is on the system's own local network.  If so, the
packet can be sent directly.  Otherwise, the system expects to find an
entry for the network that the destination address is on.  The packet
is sent to the gateway listed in that entry.  This table can get quite
big.  For example, the Internet now includes several hundred
individual networks.  Thus various strategies have been developed to
reduce the size of the routing table.  One strategy is to depend upon
"default routes".  Often, there is only one gateway out of a network.
This gateway might connect a local Ethernet to a campus-wide backbone
network.  In that case, we don't need to have a separate entry for
every network in the world.  We simply define that gateway as a
"default".  When no specific route is found for a packet, the packet
is sent to the default gateway.  A default gateway can even be used
when there are several gateways on a network.  There are provisions
for gateways to send a message saying "I'm not the best gateway -- use
this one instead."  (The message is sent via ICMP.  See rfc792.txt)
Most network software is designed to use these messages to add entries
to their routing tables.  Suppose network 128.6.4 has two gateways,
128.6.4.59 and 128.6.4.1.  128.6.4.59 leads to several other internal
Rutgers networks.  128.6.4.1 leads indirectly to the NSFnet.  Suppose
we set 128.6.4.59 as a default gateway, and have no other routing
table entries.  Now what happens when we need to send a packet to MIT?
MIT is network 18.  Since we have no entry for network 18, the packet
will be sent to the default, 128.6.4.59.  As it happens, this gateway
is the wrong one.  So it will forward the packet to 128.6.4.1.  But it
will also send back an error saying in effect: "to get to network 18,
use 128.6.4.1".  Our software will then add an entry to the routing
table.  Any future packets to MIT will then go directly to 128.6.4.1.

Most IP experts recommend that individual computers should not try to
keep track of the entire network.  Instead, they should start with
default gateways, and let the gateways tell them the routes, as just
described.  However this doesn't say how the gateways should find out
about the routes.  The gateways can't depend upon this strategy.  They
have to have fairly complete routing tables.  (It is possible to do
hierarchical routing, where all of the gateways on a campus know about
the campus network, but direct all off-campus traffic to a single
gateway with connections off-campus.)  For this, some sort of routing
protocol is needed.  A routing protocol is simply a technique for the
gateways to find each other, and keep up to date about the best way to
get to every network.  rfc1009.txt contains a review of gateway design
and routing.  However rip.doc is probably a better introduction to the
subject.  It contains some tutorial material, and a detailed
description of the most commonly-used routing protocol.


Details about Internet addresses: subnets and broadcasting
==========================================================

As indicated above, Internet addresses are 32-bit numbers, normally
written as 4 octets (in decimal), e.g. 128.6.4.7.  There are actually
3 different types of address.  The problem is that the address has to
indicate both the network and the host within the network.  It was
felt that eventually there would be lots of networks.  Many of them
would be small, but probably 24 bits would be needed to represent all
the IP networks.  It was also felt that some very big networks might
need 24 bits to represent all of their hosts.  This would seem to lead
to 48 bit addresses.  But the designers really wanted to use 32 bit
addresses.  So they adopted a kludge.  The assumption is that most of
the networks will be small.  So they set up three different ranges of
address.  Addresses beginning with 1 to 126 use only the first octet
for the network number.  The other three octets are available for the
host number.  Thus 24 bits are available for hosts.  These numbers are
used for large networks.  But there can only be 126 of these very big
networks.  The Arpanet is one, and there are a few large commercial
networks.  But few normal organizations get one of these "class A"
addresses.  For normal large organizations, "class B" addresses are
used.  Class B addresses use the first two octets for the network
number.  Thus network numbers are 128.1 through 191.254.  (We avoid 0
and 255, for reasons that we see below.  We also avoid addresses
beginning with 127, because that is used by some systems for special
purposes.)  The last two octets are available for host addesses,
giving 16 bits of host address.  This allows for 64516 computers,
which should be enough for most organizations.  (It is possible to get
more than one class B address, if you run out.)  Finally, class C
addresses use three octets, in the range 192.1.1 to 223.254.254.
These allow only 254 hosts on each network, but there can be lots of
these networks.  Addresses above 223 are reserved for future use, as
class D and E (which are currently not defined).

Many large organizations find it convenient to divide their network
number into "subnet".  For example, Rutgers has been assigned a class
B address, 128.6.  We find it convenient to use the third octet of the
address to indicate which Ethernet a host is on.  This division has no
significance outside of Rutgers.  A computer at another institution
would send any packet whose destination address began with 128.6 on
the best route to Rutgers.  They would not have different routes for
128.6.4 or 128.6.5.  But inside Rutgers, we treat 128.6.4 and 128.6.5
as separate networks.  In effect, gateways inside Rutgers have
separate entries for each Rutgers subnet, whereas gateways outside
Rutgers just have one entry for 128.6. Note that we could do exactly
the same thing by using a separate class C address for each Ethernet.
As far as Rutgers is concerned, it would be just as convenient for us
to have a number of class C addresses.  However using class C
addresses would make things inconvenient for the rest of the world.
Every institution that wanted to talk to us would have to have a
separate entry for each one of our networks.  If every institution did
this, there would be far too many networks for any reasonable gateway
to keep track of.  By subdividing a class B network, we hide our
internal structure from everyone else, and save them trouble.  This
subnet strategy requires special provisions in the network software.
It is described in rfc950.txt.

0 and 255 have special meanings.  0 is reserved for machines that
don't know their address.  In certain circumstances it is possible for
a machine not to know the number of the network it is on, or even its
own host address.  So 0.0.0.23 would be a machine that knew it was
host number 23, but didn't know on what network.  

255 is used for "broadcast".  A broadcast is a message that you want
every system on the network to see.  Broadcasts are used in some
situations where you don't know	who to talk to.  For example, suppose
you need to look up a host name and get its Internet address.
Sometimes you don't know the address of the system that has the host
name data base.  In that case, you might send the request as a
broadcast.  There are also cases where a number of systems are
interested in information.  It is then less expensive to send a single
broadcast than to send packets individually to each host that is
interested in the information.  In order to send a broadcast, you use
an address that is made by using your network address, with all ones
in the part of the address where the host number goes.  For example,
if you are on network 128.6.4, you would use 128.6.4.255 for
broadcasts.  How this is actually implemented depends upon the medium.
It is not possible to send broadcasts on the Arpanet, or on point to
point lines.  However it is possible on an Ethernet.  If you use an
Ethernet address with all its bits on (all ones), every machine on the
Ethernet is supposed to look at that packet.

Although the official broadcast address for network 128.6.4 is now
128.6.4.255, there are some other addresses that may be treated as
broadcasts by certain implementations.  For convenience, the standard
also allows 255.255.255.255 to be used.  This refers to all hosts on
the local network.  It is often simpler to use 255.255.255.255 instead
of finding out the network number for the local network and forming a
broadcast address such as 128.6.4.255.  In addition, certain older
implementations may use 0 instead of 255 to form the broadcast
address, e.g. 128.6.4.0.  Finally, certain older implementations may
not understand about subnets.  Thus they consider the network number
to be 128.6.  In that case, they will assume a broadcast address of
128.6.255.255 or 128.6.0.0.  Until support for broadcasts is
implemented properly, it can be a somewhat dangerous feature to use.

Because 0 and 255 are used for unknown and broadcast addresses, normal
hosts should never be given addresses containing 0 or 255.  Addresses
should never begin with 0, 127, or any number above 223.  Addresses
violating these rules are sometimes referred to as "Martians", because
of rumors that the Central University of Mars is using network 225.


Packet splitting and reassembly
===============================

TCP/IP is designed for use with many different kinds of network.
Unfortunately, network designers do not agree about how big packets
can be.  Ethernet packets can be 1500 octets long.  Arpanet packets
have a maximum of around 1000 octets.  Some very fast networks have
much larger packet sizes.  At first, you might think that IP should
simply settle on the smallest possible size.  Unfortunately, this
would cause serious performance problems.  When transferring large
files, big packets are far more efficient than small ones.  So we want
to be able to use the largest packet size possible.  But we also want
to be able to handle networks with small limits.  There are two
provisions for this.  First, TCP has the ability to "negotiate" about
packet size.  When a TCP connection first opens, both ends can send
the maximum packet size they can handle.  The smaller of these numbers
is used for the rest of the connection.  This allows two
implementations that can handle big packets to use them, but also lets
them talk to implementations that can't handle them.  However this
doesn't completely solve the problem.  The most serious problem is
that the two ends don't necessarily know about all of the steps in
between.  For example, when sending data between Rutgers and Berkeley,
it is likely that both computers will be on Ethernets.  Thus they will
both be prepared to handle 1500-octet packets.  However the connection
will at some point end up going over the Arpanet.  It can't handle
packets of that size.  For this reason, there are provisions to split
packets up into pieces.  The IP header contains fields indicating the
a packet has been split, and enough information to let the pieces be
put back together.  If a gateway connects an Ethernet to the Arpanet,
it must be prepared to take 1500-octet Ethernet packets and split them
into pieces that will fit on the Arpanet.  Furthermore, every
implementation of TCP/IP must be prepared to accept pieces and put
them back together.  This is referred to as "reassembly".

TCP/IP implementations differ in the approach they take to deciding on
packet size.  It is fairly common for implementations to use 576-byte
packets whenever they can't verify that the entire path is able to
handle larger packets.  The problem is that many implementations have
bugs in the code to reassemble pieces.  So many implementors try to
avoid ever having splits occur.  Different implementors take different
approaches to deciding when it is safe to use large packets.  Some use
them only for the local network.  Others will use them for any network
on the same campus.  576 bytes is a "safe" size, which every
implementation must support.


Ethernet encapsulation: ARP
===========================

There was a brief discussion above about what IP packets looked like
on an Ethernet.  The discussion showed the Ethernet header and
checksum.  However it left one hole: It didn't say how to figure out
what Ethernet address to use when you want to talk to a given Internet
address.  In fact, there is a separate protocol for this, called ARP
("address resolution protocol").  Note by the way that ARP is not an
IP protocol.  That is, the ARP packets do not have IP headers.
Suppose you are on system 128.6.4.194 and you want to connect to
system 128.6.4.7.  Your system will first verify that 128.6.4.7 is on
the same network, so it can talk directly via Ethernet.  Then it will
look up 128.6.4.7 in its ARP table, to see if it already knows the
Ethernet address.  If so, it will stick on an Ethernet header, and
send the packet.  But suppose this system is not in the ARP table.
There is no way to send the packet, because you need the Ethernet
address.  So it uses the ARP protocol to send an ARP request.
Essentially an ARP request says "I need the Ethernet address for
128.6.4.7".  Every system listens to ARP requests.  When a system sees
an ARP request for itself, it is required to respond.  So 128.6.4.7
will see the request, and will respond with an ARP reply saying in
effect "128.6.4.7 is 8:0:20:1:56:34".  (Recall that Ethernet addresses
are 48 bits.  This is 6 octets.  Ethernet addresses are conventionally
shown in hex, using the punctuation shown.)  Your system will save
this information in its ARP table, so future packets will go directly.
Most systems treat the ARP table as a cache, and clear entries in it
if they have not been used in a certain period of time.

Note by the way that ARP requests must be sent as "broadcasts".  There
is no way that an ARP request can be sent to the right system.  After
all, the whole reason for sending an ARP request is that you don't
know the Ethernet address.  So an Ethernet address of all ones is
used, i.e. ff:ff:ff:ff:ff:ff.  By convention, every machine on the
Ethernet is required to pay attention to packets with this as an
address.  So every system sees every ARP requests.  They all look to
see whether the request is for their own address.  If so, they
respond.  If not, they could just ignore it.  (Some hosts will use ARP
requests to update their knowledge about other hosts on the network,
even if the request isn't for them.)  Note that packets whose IP
address indicates broadcast (e.g. 255.255.255.255 or 128.6.4.255) are
also sent with an Ethernet address that is all ones.


Getting more information
========================

This directory contains documents describing the major protocols.
There are literally hundreds of documents, so we have chosen the ones
that seem most important.  Internet standards are called RFC's.  RFC
stands for Request for Comment.  A proposed standard is initially
issued as a proposal, and given an RFC number.  When it is finally
accepted, it is added to Official Internet Protocols, but it is still
referred to by the RFC number.  We have also included two IEN's.
(IEN's are an older form of RFC.)  The convention is that whenever an
RFC is revised, the revised version gets a new number.  This is fine
for most purposes, but it causes problems with two documents: Assigned
Numbers and Official Internet Protocols.  These documents are being
revised all the time, so the RFC number keeps changing.  You will have
to look in rfc-index.txt to find the number of the latest edition.
Anyone who is seriously interested in TCP/IP should read the RFC
describing IP (791).  RFC 1009 is also useful.  It is a specification
for gateways to be used by NSFnet.  As such, it contains an overview
of a lot of the TCP/IP technology.  You should probably also read the
description of at least one of the application protocols, just to get
a feel for the way things work.  Mail is probably a good one
(821/822).  TCP (793) is of course a very basic specification.
However the spec is fairly complex, so you should only read this when
you have the time and patience to think about it carefully.
Fortunately, the author of the major RFC's (Jon Postel) is a very good
writer.  The TCP RFC is far easier to read than you would expect,
given the complexity of what it is describing.  You can look at the
other RFC's as you become curious about their subject matter.

Here is a list of the documents you are more likely to want:

   rfc-index - list of all RFC's
   rfc1012  -  somewhat fuller list of all RFC's
   rfc1011  -  Official Protocols.  It's useful to scan this to
	see what tasks protocols have been built for.  This defines
	which RFC's are actual standards, as opposed to requests
	for comments.
   rfc1010  -  Assigned Numbers.  If you are working with TCP/IP,
	you will probably want a hardcopy of this as a reference.
	It's not very exciting to read.  It lists all the offically
	defined well-known ports and lots of other things.
   rfc1009  -  NSFnet gateway specifications.  A good overview of
	IP routing and gateway technology.
   rfc973   -  update on domains
   rfc959   -  FTP (file transfer)
   rfc950   -  subnets
   rfc894   -  how IP is to be put on Ethernet, see also rfc825
   rfc882/3 -  domains (the database used to go from host names to
	Internet address and back -- also used to handle UUCP
	these days).  See also rfc973
   rfc854/5 -  telnet - protocol for remote logins
   rfc826   -  ARP - protocol for finding out Ethernet addresses
   rfc821/2 -  mail
   rfc814   -  names and ports - general concepts behind well-known ports
   rfc793   -  TCP
   rfc792   -  ICMP
   rfc791   -  IP
   rfc768   -  UDP
   rip.doc  -  details of the most commonly-used routing protocol
   ien-116  -  old name server (still needed by several kinds of system)
   ien-48   -  the Catenet model, general description of the philosophy
	behind TCP/IP
  
The following documents are somewhat more specialized.

   rfc813   -  window and acknowledgement strategies in TCP
   rfc815   -  packet reassembly techniques
   rfc816   -  fault isolation and resolution techniques
   rfc817   -  modularity and efficiency in implementation
   rfc879   -  the maximum segment size option in TCP
   rfc896   -  congestion control
   rfc827,888,904,975,985  - EGP

To those of you who may be reading this document remotely instead of
at Rutgers: The most important RFC's have been collected into a
three-volume set, the DDN Protocol Handbook.  It is available from the
DDN Network Information Center, SRI International, 333 Ravenswood
Avenue, Menlo Park, California 94025 (telephone: 800-235-3155).
You should be able to get them via anonymous FTP from sri-nic.arpa.
File names are:
  RFC's:
    rfc:rfc-index.txt
    rfc:rfcxxx.txt
  IEN's:
    ien:ien-index.txt
    ien:ien-xxx.txt
rip.doc is available by anonymous FTP from topaz.rutgers.edu, as
/pub/tcp-ip-docs/rip.doc.

Sites with access to UUCP but not FTP may be able to retreive them
via UUCP from UUCP host rutgers.  The file names would be 
  RFC's:
    /topaz/pub/pub/tcp-ip-docs/rfc-index.txt
    /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt
  IEN's:
    /topaz/pub/pub/tcp-ip-docs/ien-index.txt
    /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt
  /topaz/pub/pub/tcp-ip-docs/rip.doc
Note that SRI-NIC has the entire set of RFC's and IEN's, but rutgers
and topaz have only those specifically mentioned above.

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 87 12:14:34 GMT
From:      well!nortond@lll-lcc.arpa  (Daniel A. Norton)
To:        tcp-ip@sri-nic.arpa
Subject:   Request TCP/IP for CTOS
My employer is in need of an implementation of TCP/IP:

	1) Which operates over 802.3 media
	2) Which operates in Convergent Technologies CTOS

They will consider porting another version.

The questions are:
	Does anyone offer such a version?
	If not, does anyone sell (or would consider selling) source code
	for another implementation that could be ported to CTOS?

Thank you for your replies.  If others are interested, please e-mail me.
If there are sufficient requests, I will summarize to the net.

[I decline to mention my employer's name since I am sponsoring my own
 access to the net.   I feel that such mention would provide unearned
 promotion.  I am more than happy to reveal to each who asks.]
--
Daniel A. Norton			...{lll-lcc,ptsfa,hplabs}!well!nortond
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28-Jun-87 19:41:57 EDT
From:      timk%newton@UXC.CSO.UIUC.EDU (Tim Krauskopf, NCSA)
To:        comp.protocols.tcp-ip
Subject:   Telnet for micros available

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

The National Center for Supercomputing Applications (NCSA) at the
University of Illinois has prepared and is distributing a telnet package
for IBM compatibles and Macintoshes.  It has many features that we haven't
found in anyone else's software.  If you have trouble getting it to run,
make sure I get a full description of your hardware setup including DOS
version.  I hope you like it.

Tim Krauskopf
Project leader, NCSA Telnet



release info:

National Center for Supercomputing Applications presents:

NCSA Telnet for the PC, version 1.1
NCSA Telnet for the Macintosh, version 1.1

These programs are copyrighted, but distributed in binary form with 
no license fee.  Source code is not available.  We are exploring the
possibility of distributing linkable libraries which support TCP/IP.


Features included in version 1.1 of NCSA Telnet:
-----------------------------------------------
DARPA standard telnet 
Built-in standard FTP server for file transfer
VT102 emulation in multiple, simultaneous sessions
Class A,B and C addressing with standard subnetting
Each session in a different window (Macintosh)
Tektronix 4010 graphics emulation (Macintosh)
Supports Croft gateway, i.e. KIP (Macintosh)
Capture text to a file (PC)
Full color support (PC)

How to obtain:
-------------
Anonymous FTP from   uxc.cso.uiuc.edu   in the NCSA subdirectory.

The PC version is a tar file which contain binary files.  After the
files are extracted from the tar file, some binary transfer (e.g.
kermit) should be used to download the files to the PC.  The
Macintosh version is several files encoded with BinHex 4.0.  Download
them with a similar transfer method (kermit) and use BinHex 4.0 to
extract the files.  Printable documentation is included with each
version; the Mac documentation is in MacWrite format.  After
downloading, you may copy the files as often as you wish, unmodified,
in binary form, with the copyright notices intact.

The PC version is also on this dial-up BBS:
The University of Illinois Excel project BBS:
(217)333-8301                    file name: NCSATEL.ARC
300-1200-2400 baud               size: 85K
Kermit/Xmodem

On-disk copies, with a printed manual are available for $20 each,
which covers handling and postage.  Orders can only be accepted if
accompanied by a check made out to the University of Illinois.  Send
to:

NCSA Telnet orders (specify PC or Macintosh version)
152 Computing Applications Building
605 E. Springfield Ave.
Champaign, IL 61820

Hardware required:
-----------------
PC: IBM PC, AT or 100% compatible. 3COM 3C501 Etherlink board.
	Support for other boards planned, which would you require?

Mac: Macintosh 512K, Plus, SE or Macintosh II.  
	Kinetics, Inc. FastPath, EtherSC or Etherport SE board.
	Kinetics gateway software or Stanford KIP (Croft) gateway software.

The best source of information about Kinetics is directly from the company.
Kinetics Inc.                     FastPath approx. $2500
Suite 110                         EtherSC approx. $1250
2500 Camino Diablo                educational and volume discounts
Walnut Creek, CA  94596
(415) 947-0998

Other questions:
---------------
mail to telbug%newton@uxc.cso.uiuc.edu

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 05:04:00 EDT
From:      WANCHO@SIMTEL20.ARPA.UUCP
To:        comp.protocols.tcp-ip
Subject:   SLIP mode on a TAC?

Any chance we'll see a SLIP mode on a TAC port?  Possible?  Soon?  Ever?

--Frank

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 09:36:39 EDT
From:      epg@cwi.nl (Ed Gronke)
To:        comp.protocols.tcp-ip
Subject:   FIN_WAIT_2, LAST_ACK, and PRU_DISCONNECT

I have been having a problem with rsh that I thought that I should refer to the
net. The problem has to do with outstanding send data 
(the socket send queue is non-zero) and in the CLOSE_WAIT state
that receives a PRU_DISCONNECT (through a the final close of stdout of the
child process of the rshd when it exits) when the other side of the socket
(the originator) has already entered the FIN_WAIT_2 state.

In a diagram:

Originator                Reciever      Recieve user

FIN_WAIT_2                CLOSE_WAIT     PRU_DISCONNECT
(no further sends)       /              /
                        /              /
                 (DATA)/              /
                      /   LAST_ACK
                     /    (treated like a close but
                    /      doesn't generate a fin
                           FIN and also marks socket
(send ack of data)         for no further reads or writes)
                   \
                    \

What happens after this seems to be this. There is one more input processed (the
ACK of the previous data which also updates the send window to 800 (it was 0))
process and one more output is processed. The trpt output is as follows:


371 CLOSE_WAIT:output [ecd0603..ecd0a03)@16b69885(win=1000)<ACK> -> CLOSE_WAIT
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0203 snd_nxt ecd0a03 snd_max ecd0a03
	snd_wl1 16b69885 snd_wl2 ecd0203 snd_wnd c00
372 CLOSE_WAIT:output [ecd0a03..ecd0e03)@16b69885(win=1000)<ACK,PUSH> -> CLOSE_WAIT
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0203 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0203 snd_wnd c00
372 CLOSE_WAIT:user SEND -> CLOSE_WAIT
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0203 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0203 snd_wnd c00
377 CLOSE_WAIT:input 16b69885@ecd0e03<ACK> -> CLOSE_WAIT
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0e03 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 0
377 CLOSE_WAIT:user SEND -> CLOSE_WAIT
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0e03 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 0
379 CLOSE_WAIT:user SEND -> CLOSE_WAIT
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0e03 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 0
			/* Here is the disconnect. the child of the rsh has died and
			 * done the close (in exit) */
389 CLOSE_WAIT:user DISCONNECT -> LAST_ACK
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0e03 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 0
	/* The last ack processed, snd_wnd: 0 -> 800 */
532 LAST_ACK:input 16b69885@ecd0e03(win=800)<ACK> -> LAST_ACK
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0e03 snd_nxt ecd0e03 snd_max ecd0e03
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 800
532 LAST_ACK:output [ecd0e03..ecd1203)@16b69885(win=1000)<ACK> -> LAST_ACK
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd0e03 snd_nxt ecd1203 snd_max ecd1203
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 800

	/* The only difference with this case and above is that the snd_wnd is
	 * not = 0, as far as I can tell */
	 
534 LAST_ACK:drop 16b69885@ecd1203(win=c00)<ACK> -> LAST_ACK
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd1203 snd_nxt ecd1203 snd_max ecd1203
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 400
015 LAST_ACK:user SLOWTIMO<KEEP> -> LAST_ACK
	rcv_nxt 16b69885 rcv_wnd 1000 snd_una ecd1203 snd_nxt ecd1203 snd_max ecd1203
	snd_wl1 16b69885 snd_wl2 ecd0e03 snd_wnd 400


So, my question is this:

What should be the response to a user DISCONNECT request? (Should it be
the same as CLOSE? )

(For those interested, the relevant pieces of code are in tcp_input.c: tcp_input
 in the section related to responding to an ack and in tcp_usrreq.c:tcp_disconnect()
and tcp_usrreq.c:tcp_usrclosed()).

If anyone knows of a fix or can explain to me why 4.3 tcp goes from CLOSE_WAIT
to LAST_ACK without generating a FIN and also why tcp_input is dropping the input
and/or whether this is related to no output being generated. (Should there be
a timeout to flush the mbuf's on a connection in the LAST_ACK state?)

-- Ed Gronke (epg@cwi.nl or mcvax!epg)

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 09:57:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP
To:        comp.protocols.tcp-ip
Subject:   question about berkeley TCP/IP


    Date: Fri, 26 Jun 87 19:06 PDT
    From: Kevin Carosso <@YMIR.BITNET:KVC@ENGVAX.SCG.HAC.COM>

    When a SYN is sent to a Berkeley UNIX TCP/IP implementation (4.3 or 4.2)
    it appears that UNIX can send the SYN-ACK without having to ARP for the
    host it's ACKing.  Does it indeed add an entry to the ARP table when an
    ethernet IP packet comes in?  I'll buy that anything to cut down
    on ethernet broadcasts is a good thing...

    This may seem like a dumb question, but the code is a little opaque and
    I'm not a UNIX kernel hack.  I have a hypothesis which explains some behaviour
    I'm seeing with the TCP I maintain (CMU/Tek for VAX/VMS) and UNIX must be
    doing this if my theory's any good.

That can't really work in the face of gateways, since on input the
source IP address does not correspond to the hardware source address of
the gateway, and on output routing is taking place so that the packet is
sent to the gateway's IP address, which the sender doesn't necessarily
have a translation for and may not have it handy.

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 10:24:33 EDT
From:      zwang@CS.UCL.AC.UK.UUCP
To:        comp.protocols.tcp-ip
Subject:   IP options implementation

Hi,

Does anyone know of the implementation of IP options( source route, timestamp
and so on) under UNIX?  In our dept, there is only one line: m_free(opt); for
the IP options. 

Thanks in advance!

zwang@uk.ac.ucl.cs (UK)
zwang@cs.ucl.ac.uk (US)

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 14:15:04 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: question about berkeley TCP/IP

Of course a Berkeley host can send a SYN-ACK in response to an incoming SYN
without doing an ARP request!  If you got the SYN to it, you must have
sent an ARP request at some time (all of this assuming the hosts are
on the same Ethernet).  When the ARP request was received and processed,
the hardware address for your machine was added to the ARP cache.

		Mike

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 14:15:51 EDT
From:      karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options implementation

4.3BSD implements most of the IP options (except security); 4.2 BSD did not.

		Mike

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 15:20:51 EDT
From:      dave@moogvax.UUCP
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Serial Line IP and ULTRIX-32 2.0

Does anybody know if Ultrix 2.0 supports SLIP? If not, is it possible to install
it if you are binary site. 

Thanks.
-- 
Dave Szczepanski
Moog Inc.
UUCP:{decvax,rocksanne,rocksvax}!sunybcs!moogvax!dave

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 15:31:09 EDT
From:      louie@trantor.UMD.EDU (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: question about berkeley TCP/IP

What probably happens is that who every sent the original packet with
a SYN segment first had to ARP for your address.  The 4.x BSD ARP
module caches the address of the host requesting your address; thus
when you want to reply, the ARP mapping is already present.

Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 17:14:00 EDT
From:      DCP@QUABBIN.SCRC.SYMBOLICS.COM (David C. Plummer)
To:        comp.protocols.tcp-ip
Subject:   Ack: question about berkeley TCP/IP

What is this crap, why are you sending it to me, and why should I give a
damn about the internal state of your mailer?  Are other people getting
this stuff?

    Date:         Mon, 29 Jun 1987 14:48 EDT
    From:         Revised List Processor (1.5j) <LISTSERV%MARIST.BITNET@wiscvm.wisc.edu>

    Statistics for TCPIP-L mailing (ARPA TCP-IP Discussion Redistribution):
     Total number of (non-local) outbound files: 7
     Total number of outbound  80-chars records: 203
     Total resulting network load (link.kbytes): 65.70

    Date:         Mon, 29 Jun 1987 14:48 EDT
    From:         Revised List Processor (1.5j) <LISTSERV%MARIST.BITNET@wiscvm.wisc.edu>

    Processing your mail (2099) for TCPIP-L...

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29-Jun-87 17:16:02 EDT
From:      rroot@edm.UUCP (uucp)
To:        comp.protocols.tcp-ip
Subject:   Re: NSC HyperchannelB - Ethernet TCP/IP gateway

In article <8706141434.aa06229@SEM.BRL.ARPA>, dpk@BRL.ARPA (Doug Kingston) writes:
> I know of no gateway that one can plug in and run between
> a TCP/IP network and a Hyperchannel.  If you can obtain
> TCP/IP for the IBM and/or the Sperry (they do exist), then
> you could make one minicomputer a gateway by giving it an
> interface on both the Hyperchannel and the other TCP/IP ....

There is currently some work at the University of Alberta computing
services trying to build a hyperbus/TCP gateway box. I didn't see the
original posting, so if somebody could mail me (a summary of) the original
query, I could perhaps comment on how well the UofA work might answer 
the problem.
-------------
 Stephen Samuel 			Disclaimer: You betcha!
  {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve

-- 
-------------
 Stephen Samuel 
  {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!ad!uad

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 87 14:57:02 GMT-0:00
From:      Zheng Wang <zwang@Cs.Ucl.AC.UK>
To:        tcp-ip@sri-nic.arpa
Cc:        zwang@Cs.Ucl.AC.UK
Subject:   IP options implementation
Hi,

Does anyone know of the implementation of IP options( source route, timestamp
and so on) under UNIX?  In our dept, there is only one line: m_free(opt); for
the IP options. 

Thanks in advance!

zwang@uk.ac.ucl.cs (UK)
zwang@cs.ucl.ac.uk (US)
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 02:22:54 EDT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Chrenobyl revisited

Folks,

Alerted by an increasing incidence of timewarps (unexpectedly large excursions
in measured time discrepancies between Internet time servers) I found that the
core gateway system seems to have lost its marbles. Faithful old fuzzsoldier
macom1 (10.0.0.111) squawks EGP with purdue, bbn2 and isi gateways, so
presumably those gateways should have a reasonably consistent and stable
routing data base. Following is a sample of the routing tables in these three
gateways:

purdue	UP:	macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP)
 upenn       128.91	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
 Washington  192.5.8	1 hop (ext) via macom1 10.0.0.111 (Arpanet)
 cpw-psc     192.5.146	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
bbn2	UP:	macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP)
 upenn       128.91	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
 cpw-psc     192.5.146	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
isi	UP:	macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP)
 Washington  192.5.8	1 hop (ext) via macom1 10.0.0.111 (Arpanet)
 cpw-psc     192.5.146	4 hops (ext) via macom1 10.0.0.111 (Arpanet)

Network Washington (since retired, now macomnet) is directly connected to
macom1, so should indicate 1 hop, while networks upenn and cpw-psc are
indirectly connected via NSFNET and should indicate 4 hops. All three of these
networks should be reachable by macom1; however, the above data indicate some
of the gateways are reachable only by other gateways. Clearly the core
gateways do not have consistent routing tables. This would not be so bad if
the tables were stable and did not oscillate with time. Unfortunately, the
tables are bobbing like corks, as shown by the following sample made a few
minutes after the previous:

purdue	UP:	macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP)
 upenn       128.91	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
 cpw-psc     192.5.146	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
bbn2	UP:	macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP)
 upenn       128.91	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
 Washington  192.5.8	1 hop (ext) via macom1 10.0.0.111 (Arpanet)
 cpw-psc     192.5.146	4 hops (ext) via macom1 10.0.0.111 (Arpanet)
isi	UP:	macom1 10.0.0.111 (Arpanet) (EGP or indirect via EGP)
 cpw-psc     192.5.146	4 hops (ext) via macom1 10.0.0.111 (Arpanet)

Gateway macom1 happens to be the primary entry point for macomnet (192.5.8),
so one might ask how the core system thinks it might be reached. Alas, the
three gateways have curious, inconsistent ways of reaching it, some quite
bizarre:

purdue	192.5.8	1 hop (ext) via macom1 10.0.0.111 (Arpanet)
bbn2	192.5.8	4 hops (ext) via psc.psc.edu 10.4.0.14 (Arpanet)
isi	192.5.8	1 hop (ext) via macom1 10.0.0.111 (Arpanet)

Well, even that might not break the bank, except for the fact the tables are
oscillating like crazy. Here is a sample recorded a few minutes after the
above:

purdue	192.5.8	2 hops (ext) via ISI 10.3.0.27 (Arpanet)
bbn2	192.5.8	1 hop (ext) via macom1 10.0.0.111 (Arpanet)
isi	192.5.8	2 hops (ext) via BBN2 10.7.0.63 (Arpanet)

The last time I saw this behavior bugs were found in the core gateway code and
subsequently fixed. The present behavior is at least as bad as I have ever
seen and suggests very serious instabilities have recurred. In fact, the
logs on macom1 and other fuzzballs I can reach out and touch indicate
intermittent loss of connectivity and general flakiness consistent with the
above observations.

To add to the fun above, I discovered that gateway ngp.utexas.edu (10.0.0.62)
is mercilessly beating on macom1 as the gateway to host brl-aos (192.5.22.82),
probably the domain nameserver there. Poor macom1 has been returning several
thousand ICMP Redirect messages to what it thinks is a broken host (how would
it know differently?). Gateway ngp.utexas.edu presumably discards redirects as
messages from the Devil.

The routing data base of all three core EGP speakers, not to mention the poor
fuzzballs, clearly states network 192.5.22 is reachable only by the
ARPANET/MILNET gateways, not macom1. I can't raise the ngp keepers on hf, vhf
or space relay to correct this nonsense. Can somebody drop something heavy on
their heads?

Finally, it would be fun to find out why so much traffic is sloshing by macom1
for the NSFNET swamps, in spite of the fact that very little traffic is
destined for the nets it advertises. I suspect some j-random ARPANET hosts
have a very sticky gateway table that locks on to a gateway that happens to
volunteer reachability when times are bad and doesn't have sense enough to
backtrack to the good guys when times are good. This isn't necessarily a fault
on the part of the hosts; however, an EGP gateway may not know that, although
it can reach a network, other EGP gateways are a better choice. More thought
needed on that.

Comments from the gateway crew at BBN would be highly prized.

Dave

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 07:03:34 EDT
From:      avolio@decuac.dec.com (Fred Avolio)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Serial Line IP and ULTRIX-32 2.0

In article <662@moogvax.UUCP>, dave@moogvax.UUCP (Dave Szczepanski) writes:
> Does anybody know if Ultrix 2.0 supports SLIP? If not, is it possible to install
> it if you are binary site. 

It does not come with SLIP support.  I agree, it is needed.  I see no
easy way to install it with a binary kit since you need to modify
init_main, but perhaps someone running SLIP under ULTRIX could send
you the binaries on a tape for you to install (if you sent them
electronic mail with your USMail address).

We are running SLIP under ULTRIX 2.0.

Fred

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 09:10:02 EDT
From:      tucker%mycroft@gswd-vms.Gould.COM (Tim Tucker)
To:        comp.protocols.tcp-ip
Subject:   Re: IP options implementation

Why didn't Berkeley implement the security option?  Those of us selling systems
to the DOD need to add it anyway and it would probably be nice if a common
implementation across all users of 4.3BSD TCP existed.  Why do I care?  The
security option requires some user space changes to programs like FTP and
TELNET besides just kernel changes.

Tim Tucker
Gould Computer Systems Division
tucker@gswd-vms.Gould.COM

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 09:10:04 EDT
From:      hmm@laura.irb.informatik (Martin Mosner)
To:        comp.protocols.tcp-ip
Subject:   status of POP

Does anyone know which version of POP (the Post Office Protocol) is
the most recent ?  I've got a protocol description dating from
February 1985 (rfc837) which describes POP version 2, and says that
it replaces rfc918.  On the other hand, I've got a server from the
MH mail system which has a date of Sun Oct 28 16:23:26 1984 attached
to it and implements a slightly different protocol.  Now it seems
that this server is obsolete, but there's an accompanying document
from October 1985 which describes exactly this protocol and states
that it is a revised version of rfc918.  And all these 3 items have
been written by Marshall T. Rose...  Now I don't know whether I
should take the server as given and implement my client accordingly,
or should rewrite the server to speak POP2, or whatelse.
Can anyone enlighten me ?

	Hans-Martin
	hmm@unido.uucp
D

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 10:36:12 EDT
From:      ron@TOPAZ.RUTGERS.EDU (Ron Natalie)
To:        comp.protocols.tcp-ip
Subject:   question about berkeley TCP/IP

I can't say if BSD is picking up on Ethernet hardware addresses
from the incoming connection request, but there is no reason why
this can't happen.  The internet address of remote end would be
entered into the arp cache with the gateway's hardware address.
This will work.  This is how gateways on Ethernet subnets trick hosts
that don't know about subnets into working properly.  The gateway
sends arp answers for IP addresses off the local subnet that it will
route for.

Nearly every device I've come across (including BSD UNIX systems
and other things for which we don't have source) will allow manyone
mappings of IP to Ethernet address.

=Ron

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 12:37:44 EDT
From:      louie@TRANTOR.UMD.EDU (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: Ack: question about berkeley TCP/IP

I also got a bunch of these bogus messages directed to me.  I suggest that it
should be made to stop, as I have too many messages a day to read as it is.

Fix it, or take 'em off the list.  

louie

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30-Jun-87 18:12:08 EDT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Re: Reassembly queues in TCP

About a month ago I posted some commentary on a Berkeley UNIX panic caused
by an uncontrolled stream of 1 byte TCP packets emanating from some VMS
hosts.  I had also posted a fix to UNIX-wizards.  Unfortunately, that
was not the complete story.  We continued to crash occasionally due to
a clobbered message buffer pool.  The reason for this has been found.

4.3 BSD has a cluster buffer concept which is used in socket creation
among other things.  A cluster buffer is relatively large block of
storage (CLBYTES bytes) pointed to in mysterious ways by the normal
small message buffers.
The routine to get a cluster buffer (MCLGET) did not set up an error
condition if it failed to reserve a cluster buffer.  Consequently, 
at some point after running out of message buffers, the system would
run across one of the clobbered cluster buffers and panic.

The fix to MCLGET is to set the 'm_len' field in the small message buffer
to 0 or anything other than CLBYTES before returning to the caller.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Wed, 1-Jul-87 01:43:22 EDT
From:      peter%gr@CS.UTAH.EDU (Peter S. Ford)
To:        comp.protocols.tcp-ip
Subject:   Re: Chrenobyl revisited


This may or may not be related, but on 24 June 1800 MDT we started to
see packets routed through utah-arpa-gw.arpa (CISCO -- 10.3.0.4) with

src IP addr: 128.103.1.54 (husc4.harvard.edu)
dst IP addr: 128.84.252.18 (cornelld.tn.cornell.edu)

To our knowledge the CISCO only advertises reachablity to nets 128.110, and
192.12.56.

This traffic eventually died off.  Must be some swamp out there.

Peter Ford   U of Utah CS department.
peter@cs.utah.edu

END OF DOCUMENT